|
1: Co to jest?
Podejście eksploracyjne polega na wyjściu z predefiniowanych zadań czy szablonów. Możemy niemal od razu usiąść do aplikacji, przetestować ją, stworzyć notatki, komentarze, nagrania, zrzuty ekranu i zebrać dane do kolejnych testów czy analiz. Pomimo nieco większej czasochłonności, metoda ta jest bardzo skuteczna i zalecana, gdy chcemy pokryć większą część aplikacji testami.
2: Czy to to samo co testy ad-hoc?
Nie. Choć w sieci jest wiele materiałów czy nawet kursów, które stosują te nazwy zamiennie. Testowanie ad-hoc jest swobodnym i nieustrukturyzowanym typem testowania.Oznacza to, że nie ma żadnych zasad, celów ani zdefiniowanej strategii, więc efektywność takiego testowania jest całkowicie zależna od poziomu doświadczenia specjalisty. Testowanie ad-hoc jest trudne do przeprowadzenia bez żadnych standardów, a brak dokumentacji często oznacza, że wszelkie wykryte defekty będą również trudne do odtworzenia. Testowanie eksploracyjne łączy w sobie elastyczność testowania ad-hoc, ale z podejściem strukturalnym. Dokumentujemy przypadki testowe z zestawem celów, ale jednocześnie możemy (i musimy) myśleć kreatywnie i krytycznie podczas pracy.
3: Benefity:
- szybka informacja zwrotna już na wczesnym etapie rozwoju oprogramowania,
- idealna do niestabilnych i szybko rozwijających się środowisk,
- obejmuje różne aspekty jakości - scenariusze testowe, dokumentację, testy niefunkcjonalne i inne,
- może pokryć większą część aplikacji,
- można wykonywać takie testy nawet bez dokumentacji,
- idealne uzupełnienie testów automatycznych.
4: Dobre praktyki, czyli warto:
- określić zakres przed przystąpieniem do eksploracji,
- przygotować dane testowe, w tym te dotyczące wartości brzegowych,
- przygotować testy bez skryptów, checklist i innych planów - wszystko to może obniżyć poziom kreatywności specjalisty,
- przygotować dokument/miejsce, gdzie zapisywać będziemy postępy, ze szczególnym uwzględnieniem odnalezionych defektów.
5: Raportowanie znalezionych defektów jest ważne
I jest to jednocześnie (prawdopodobnie) największy problem takich testów. Jak do tego podejść? Na dwa sposoby (lub ich połączenie):
- formalny - klasyczny raport z testów, z metrykami, z tabelami, z analizą ryzyka - nie jest to jednak rozwiązanie dla testów eksploracyjnych (przynajmniej z definicji),
- nieformalny - przygotowanie miejsca, gdzie będziemy mogli zachowywać wszelkie notatki, zapisy, nagrania (tu można wykorzystać np. Bird Eats Bug albo jam.dev), komentarze i inne dowody przeprowadzonych działań. Do tego nie wykorzystamy już Excela czy Google Docs, a i Jira może nie wystarczyć. Możemy posłużyć się Confluencem, SharePointem od Microsoft albo dedykowanym narzędziem (bądź pluginem do Jiry) dla Quality Assurance lub testerów. Z definicji testowanie eksploracyjne wymaga sporo miejsca na różnego rodzaju dane, więc chyba najlepszym rozwiązaniem będzie jakiś dysk firmowy, SharePoint lub intranet. Pamiętaj również o bezpieczeństwie danych!
|
