Testowanie wyszukiwarki – przykładowy projekt.

Testowanie wyszukiwarki – przykładowy projekt.
W ramach warsztatów poświęconych testowaniu powstał wartościowy materiał z przykładami, który może posłużyć jako przykład użycia metody testów eksploracyjnych w prawdziwym projekcie informatycznym.

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”,
3. Naciśnij przycisk „Szukaj”

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”,
3. Naciśnij przycisk „Szukaj”

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ą.

 

 

To powinno Cię zainteresować