Redakcja
Jak sama nazwa wskazuje, korzystanie z rajdów w karcie testów (ang. test charter) oznacza, że myślimy w kategoriach różnych podróży, które użytkownicy mogą odbyć za pośrednictwem danej aplikacji. W związku z tym myślimy o rajdzie budując jego założenia w oparciu o konkretny motyw, nawigując po systemie w oparciu o ten motyw i dokumentując wyniki w odniesieniu do niego. Korzystanie z rajdów może również pomóc w szukaniu nowych pomysłów na testy.
Poniżej kilka przykładów wycieczek sugerowanych przez różnych praktyków testowania eksploracyjnego.
Rajdy Jamesa Whittakera:
- Rajd za kasą: przetestuj główne funkcje, które nie zostały jeszcze przetestowane w innych scenariuszach (nazywa się to „kasą”, ponieważ koncentrujemy się na istotnych funkcjach).
- Rajd z przewodnikiem: przetestuj zdolność oprogramowania do dostarczania opisanych w podręczniku użytkownika funkcji.
- Rajd po punktach orientacyjnych: wybierz zestaw „punktów orientacyjnych” (miejsce podjęcia ważnej decyzji przez użytkownika lub punkt działań użytkownika w systemie), zdecyduj o ich kolejności, a następnie eksploruj aplikację, przechodząc od punktu orientacyjnego do punktu orientacyjnego, aż odwiedzisz wszystkie z nich.
- Rajd po komunikatach błędów: w oparciu o konkretny cel (na przykład użycie wszystkich możliwych opcji w menu, ujawnij wszystkie komunikaty o błędach, użyj wszystkich okien dialogowych), odwiedź każdy z nich najkrótszą możliwą ścieżką.
- Rajd przerwań: poznaj różne sposoby przerywania lub anulowania operacji w oprogramowaniu, takich jak uruchamianie i zatrzymywanie zadań, naciśnięcie przycisku „Anuluj”, używanie przycisku „Wstecz” przeglądarki itp.
- Rajd obsesyjno-kompulsywny: wykonuj zadania wiele razy i sprawdzaj różne wyniki.
- Rajd bocznymi drogami: pokrywaj obszary testowe systemu, które mają niewielki zasięg wśród użytkowników lub z którymi użytkownicy pracują tylko okazjonalnie.
- Rajd całonocny: pozostaw aplikację/system otwarty na noc (lub w podobnym długim okresie czasu) i zobacz, co się stanie.
- Rajd kolekcjonera: dokumentuj każdy wynik, który widzisz podczas wykonywania scenariuszy, i sprawdź, czy możesz stworzyć więcej scenariuszy na podstawie zebranych wyników.
Więcej informacji o wycieczkach Jamesa Whittakera można znaleźć w jego książce "Exploratory Software Testing: Tips, Tricks, Tours and Techniques to Guide Design Testing."
Rajdy Jamesa Bacha:
- Rajd po dokumentacji: zajrzyj do pomocy online lub innej dokumentacji, znajdź instrukcje dotyczące wykonywania określonej czynności; wykonaj opisane czynności i sprawdź, czy zachowanie jest zgodne z opisem w dokumentacji.
- Rajd po przykładowych danych: zastosuj wszelkie przykładowe dane, które posiadasz (lub utwórz przykładowe dane) i uruchom testy przy użyciu tych danych.
- Rajd wielowymiarowy: zwiedzaj system z myślą o eksploracji różnych ścieżek logicznych/pętli logicznych, eksplorując jak najwięcej wymiarów.
- Złożony rajd: przeglądaj system w poszukiwaniu obszarów o najwyższym poziomie złożoności, takich jak pobieranie lub manipulowanie dużymi lub wieloaspektowymi zestawami danych.
- Rajd ciągłego użytkowania: podczas testowania nie należy postępować zgodnie z instrukcjami dotyczącymi tego, jak długo system ma być używany; pozostaw otwarte okna i pliki, sprawdź, czy wzrasta użycie dysku i pamięci.
Więcej informacji na temat spostrzeżeń Jamesa Bacha na temat testowania eksploracyjnego można znaleźć na jego blogu "Testowanie oprogramowania dla poważnych ludzi".
Rajdy Michaela Kelly'ego:
Pomysły Michaela Kelly'ego podążają za mnemonikami FCC CUTS VIDS:
- Rajd po funkcji: poruszaj się po systemie i zapoznaj się ze wszystkimi dostępnymi elementami kontrolnymi i funkcjami.
- Rajd po złożoności: znajdź pięć najbardziej złożonych elementów systemu i zbadaj te obszary.
- Rajd po żądaniach: znajdź wszystkie informacje o systemie, które mówią, co robi, w tym takie elementy jak umowy licencyjna użytkownika końcowego; wykonaj testy, aby zbadać te opisy.
- Rajd po konfiguracji: spróbuj znaleźć wszystkie sposoby zmiany ustawień w systemie w taki sposób, aby system zachował te ustawienia.
- Rajd użytkownika: wyobraź sobie pięciu użytkowników produktu i informacje, których chcieliby od produktu lub główne funkcje, którymi byliby zainteresowani.
- Rajd po testowalności: znajdź wszystkie funkcje, które pomagają w testowaniu i/lub znajdź dostępne narzędzia, których możesz użyć, aby wspomóc swoje testowanie.
- Rajd wg scenariusza: wyobraź sobie pięć realistycznych scenariuszy; w jaki sposób użytkownicy zidentyfikowani w instrukcji użytkownika będą korzystać z tego systemu?
- Rajd po zmianach: poszukaj rzeczy, które możesz zmienić w systemie (nawet jeśli nie powinny być zmieniane), a następnie spróbuj je zmienić.
- Rajd interoperacyjności: z czym współdziała system? Testuj na podstawie tych interakcji.
- Rajd po danych: zidentyfikuj główne elementy danych i operacje na danych związane z systemem.
- Rajd po strukturze: znajdź wszystko, co możesz i co składa się na fizyczny produkt (kod, interfejsy, sprzęt, pliki konfiguracyjne itp.) i eksploruj w oparciu o to, co widzisz w tych artefaktach.
Więcej informacji od Michaela Kelly można znaleźć w jego artykule "Taking a Tour Through Test Country: A Guide to Tours to Take on Your Next Test Project."
A Ty? W jaki sposób chcesz eksplorować oprogramowanie Pomyśl o własnym rajdzie!
*Tour – czy da się przetłumaczyć lepiej niż "rajd"? Pewnie dużo zależy od własnych preferencji. Główne tłumaczenie, czyli "wycieczka" jest OK, ale brzmi dla nas zbyt pasywnie. Lepsze wydaje się nam coś bardziej agresywnego, kojarzącego się z eksploracją, ale i podbojami. Stąd "rajd po oprogramowaniu" zamiast "wycieczki po oprogramowaniu". Można również szukać w innych synonimach: droga, ekspedycja, pielgrzymka, podróż, wędrówka, wyprawa, podróż, czy przejście. Teoretycznie może zostać nawet "tour" jako słówko, które w Polsce używane jest do wyścigów kolarskich.
