Podczas warsztatu zakładamy, że funkcjonując w kontekście projektowym musimy wybrać optymalną formę testów. Zaczynamy od formułowanych przez Zlecającego oczekiwań powstania oprogramowania względem funkcji.
WYMAGANIA
Punktem wyjścia do rozpoczęcia testów będzie zazwyczaj potrzeba biznesowa sformułowana w postaci mniej lub bardziej dokładnego wymagania. W naszym przypadku punktem wyjścia było to: „Wyszukiwarka znajduje się na stronie głównej […] Użytkownik powinien móc wyszukać wszystkie elementy strony przy pomocy wyszukiwarki.”
FORMA NOTACJI TESTÓW
W ramach analizy określiliśmy jaka forma spisania testów będzie optymalna dla danego typu projektu i jak optymalnie wykorzystać czas. Uwzględnia to wiele okoliczności projektowych i około projektowych jak: czas, pieniądz, zakres testów, dostępność doświadczonych testerów i wsparcie ze strony Zlecającego.
Do zestawienia wybrano notacje zarówno złożone jak i uproszczone
Przypadek testowy wysokiego poziomu |
Przypadek testowy niskiego poziomu |
Statut testu (test charter) |
TYTUŁ: Sprawdzenie wyszukiwania ciągu „prawo jazdy” WARUNKEK POCZĄTKOWY: Strona główna aplikacji uruchomiona DANE TESTOWE: prawo jazdy
KROKI: 1. Zaznacz obszar wyszukiwarki, 2. Wprowadź ciąg „prawo jazdy”, OCZEKIWANY REZULTAT: Na liście wyników wyszukiwania pojawiają się wyświetlone elementy strony z ciągiem „prawo jazdy” WARUNEK KOŃCOWY: Wyświetlona strona z wynikami wyszukiwania INNE: ID, wersja, priorytet, autor, podstawa |
TYTUŁ: Sprawdzenie wyszukiwania ciągu
KROKI: 1. Zaznacz obszar wyszukiwarki, 2. Wprowadź ciąg „prawo jazdy”, INNE: ID, wersja, priorytet, autor, podstawa
|
TYTUŁ: Sprawdzenie wyszukiwania Czas wykonania: 60 minut INNE: ID, wersja, priorytet, autor |
Brak precyzyjnych wymagań odnośnie notacji zachęca do zredukowania czasu potrzebnego na tworzenie szczegółowych przypadków testowych i opisanie ich jako statutów testów znanych z testowania eksploracyjnego.
TESTOWANIE
Optymalne testowanie wymaga analizy zakresu testów i określenia co i jak warto analizować.
W warsztacie w pierwszym kroku określiliśmy zbiór funkcji wart poddania weryfikacji. Przykładowo są to: wyświetlanie wyszukiwarki, aktywizacja pola wyszukiwania, aktywizacja wyszukiwania, podpowiedzi przy wpisywaniu wyświetlanie wyników, stronicowanie, nawigacja po stronach, zliczanie liczby wyników, formatowanie tekstu, obsługa pustego ciągu, komunikaty, adekwatność wyszukiwania, wartość wyników itd.
Na drugim miejscu określono cechy, które powinny – mogły by być zweryfikowane. Można wyróżnić: „funkcjonalność, wydajność, użyteczność, dopasowanie do użytkownika, dostępność, bezpieczeństwo, jakość danych”.
Dla zdefiniowanych funkcji i cech można określić specyfikę środowiska testowego oraz warunków wykonania testów np. wyszukiwanie dla różnych wyszukiwarek / wersji systemu operacyjnego / języka, wyszukiwanie dla wersji mobilnych, rozdzielczości, wyszukanie zalogowanego i niezalogowanego itp.
Po takim przygotowaniu możemy zacząć analizować testy do wykonania:
- wyświetlanie jednego rezultatu
- wyświetlanie braku wyników
- poprawność stronicowania
- wyszukiwanie po słowach kluczowych znajdujących się w treści wyszukiwania
- poprawność sortowania
- nowy (lub zaktualizowany) element powinien być możliwy do wyszukania i poprawnie wyświetlony (indeksowanie)
- brak możliwości wyszukania usuniętych treści
- w wynikach wyszukiwania powinny być treści powiązane z wyszukiwaniem
- najważniejsze wyniki na górze
- otwarcie wyników w tym samym oknie
- powrót do wyszukania
- miejsce kursora w polu wyszukania
- usunięcie podpowiedzi w polu wyszukiwania po wprowadzenie ciągu
- wyszukiwanie „spacji”, wyświetlanie wyników dla jednego znaku
- czas odpowiedzi
- liczba wyników na stronie
- kolorystyka wyników odwiedzonych i nieodwiedzonych
- wyszukiwanie specjalnych znaków
- opcje zaawansowane i ustawienia
- wyszukiwanie długich ciągów znaków
- i wiele innych.
Z tak przeanalizowanym zakresem testów i pracą do wykonania możemy przystąpić do testów. Przygotowana specyfikacja testów jak i określony ich zakres może zostać uruchomiony na praktycznie dowolnej wyszukiwarce, a podczas warsztatów przeanalizowane zostały wyszukiwarki na różnych stronach z domeny gov.pl
RAPORTOWANIE
Samo testowanie jest nastawione oczywiście na znajdywanie defektów, ale również na przygotowanie raportu o poprawnie działającym oprogramowaniu. Przykładowe defekty, które udało się znaleźć podczas testów opisane poniżej. Wynikają one zarówno z testów opisanych powyżej, jak i eksploracji doświadczonych testerów. Są to zarówno problemy użyteczności jak i nie poprawnie działające funkcje.
1. Nieadekwatność wyników wyszukiwania na hasło „minister sportu” https://www.msit.gov.pl/pl/szukaj?search=1332565&sort=2&order=1&ile=20
2. Problem rozdzielczości dla osadzonej wyszukiwarki Google http://www.mf.gov.pl/web/bip/wyniki-wyszukiwania/?q=morawiecki
3.
a. Problem braku wyszukania wartościowych wyników dla „STRATEG”
b. Problem nieczytelności przez element „wyszukiwanie zaawansowane”
c. Problem przeskrolowania ekranu do wyników wyszukiwania
http://stat.gov.pl/wyszukiwarka/szukaj.html
4.
a. Brak obsługi braku wyników wyszukiwania
b. Niedziałające znaki specjalne „ułatwiające” wyszukiwanie
c. Wyszukiwanie maksymalnie 500 wyników
http://msz.gov.pl/pl/szukaj?search=true&searchWord=waszczykowski~&searchInArchive=false&searchEveryWord=false&sortOrder=DESC
5.
a. Stronicowanie po 3 wyniki
Mała czytelność strony wyszukiwania
https://udsc.gov.pl/page/2/?s=uchod%C5%BAcy
6.
a. Bezwartościowe podpowiedzi
b. Niepoprawne wyświetlanie
http://nfosigw.gov.pl/wyszukiwarka/szukaj.html
7.
a. Automatycznie pobierane pliki po wejściu w „Druki sejmowe”
b. Niepoprawne opisy
c. Źle generowany podgląd
http://search.sejm.gov.pl/SejmSearch/ADDL.aspx?StartSite
Ostatnim elementem jest przykładowy raport, który powinien opisywać nie tylko stan jakości oprogramowania w danym momencie, ale odnosić go również do sytuacji z przeszłości i oczekiwanej jakości w przyszłości. Raport taki może być zbudowany zgodnie z regułami znanymi ze scenariusza podsumowania testów eksploracyjnych PROOF (z ang. dowód).
• Past / Przeszłość – co się wydarzyło podczas sesji?
• Results/ Rezultat - co osiągnięto podczas sesji?
• Obstacles / Przeszkody – jakie problemy się pojawiły?
• Outlook / Co na przyszłość – co jeszcze powinno zostać zrobione?
• Feelings / Odczucia – co sądzisz o oprogramowaniu?
Raport w części może przyjąć formę tabelaryczną prezentującą status uruchomienia testów na poszczególnych funkcjach i w poszczególnych wersjach. Fragment tabeli jest uzupełnionym wzorcem jaki można zastosować w takim projekcie.
PODSUMOWANIE
W tym konkretnym projekcie największą efektywność udało się uzyskać dzięki testowaniu eksploracyjnym i powiązaną z nią dokumentacją.