Radek Smilgin
Test charter na polski tłumaczy się na wiele sposóbów i żaden nie przyjął się tak, jak jego angielska nazwa. Mamy więc „statut testów”, „karta opisu testów” i uproszczoną wersję „karta testów”. Osobiście stosuję pojęcia „idei testowej”, ale nie jest ona powszechnie używana. To jakie nazewnictwo w swojej firmie przyjmiecie nie ma większego znaczenia, najważniejsze jest co kryje się za tym dokumentem. A z perspektywy testowania eksploracyjnego, jest to kluczowy i najważniejszy opis dokumentujący to, co w testach planujecie zrobić.
Należy też podkreślić, że od czasu kiedy zdefiniowano test charter, nie wyewoluował on do znacząco zmienionej formy. Jego najpopularniejszą wersją była ta opublikowana w artykule „Session-Based Test Management” Jonathana Bacha z 2000 roku. To jaką częścią raportu z testów eksploracyjnych jest charter opisaliśmy w artykule „Raportowanie testowania eksploracyjnego w sesjach”.
Sugerowane przez braci Bach chartery miały dość wysokopoziomową formułę, która mogła wykraczać poza sesję standardowej długości.
Przykłady:
- "Przetestuj wszystkie pola umożliwiające wprowadzenie danych (funkcja, przeciążenie, limity)".
- Sprawdź UI pod kątem zgodności ze standardem Windows".
- "Przetestuj integrację z zewnętrznymi aplikacjami, szczególnie z Wordem".
Karta testów jest więc celem, jaki chcemy osiągnąć w naszym testowaniu lub bardzo (bardzo) skróconym planem sesji testowej. Osoby odpowiedzialne za testy, przed rozpoczęciem sesji definiują czartery. Pamiętajmy jednak, że nie są one stałe i można je modyfikować, uzupełniać lub dokładać inne w trakcie trwania sesji, jeśli tylko nie zaburza to predefiniowanej strategii testowania. Często czartery są tworzone na podstawie specyfikacji (jeśli istnieje), kryteriów akceptacji lub poprzez analizę wyników z poprzednich sesji. Próbując mapować charter na sformalizowane testowania, często porównuje się je z przypadkami testowymi. Jest w tym ziarnko prawdy, ale pamiętajmy, że jest to dużo mniej formalna notacja.
We współczesnym świecie chartery stają się bardziej konkretne i celują w konkretne problemy oprogramowania, zadania do wykonania lub funkcje.
- Karta jako tytuł defektu.
Sesja eksploracyjna może być poświęcona analizie konkretnego defektu jakiego spodziewamy się w aplikacji. Sesja może więc koncentrować się na znalezieniu typowych nieprawidłowości. W mojej opinii nie jest to dobra forma ponieważ zakłada już na wstępie zły scenariusz testów. Może być to postrzegane jak „szukanie dziury w całym” zamiast koncentrowaniu się na jakości.
Przykłady:
„Niepoprawna walidacji w formularzach” – sugeruje to, że prowadzić będziemy testy negatywne, w oparciu o dane, które nie powinny być akceptowane przez pola formularza.
„Utrata danych przy wyjątkach” – weryfikacja zapisu danych i ich uszkodzenie lub skasowanie przy obsłudze zdarzeń niepożądanych.
„Problemy podczas logowania” – nieprawidłowości przy użyciu funkcji logowania. - Karta testów jako polecenie do wykonania.
Popularniejszą formą jest opisywanie, co chcielibyśmy, aby osoba wykonująca testy eksploracyjne osiągnęła. W relacjach lider – tester jest to coś, co można by nazwać poleceniem służbowym.
Przykłady:
„Sprawdzenie poprawności działania walidacji w formularzach” – jest to gotowe i dość czytelne przekazanie zadania dla testera.
„Weryfikacja obsługi wyjątków podczas operacji na danych w aplikacji” – jw.
„Przeanalizuje logowanie do aplikacji” – jw. - Karta jako wskazanie funkcji.
W projektach, w których wszyscy mają dużą wiedzę o produkcie czasami redukuje się notację test charterów i pomija się słowa „przetestuj”, „sprawdź”, „analizuj”. Zostawia się jedynie nazwę funkcji jaką należy sprawdzić.
Przykłady:
„Walidacja” – szybko i na temat, ale zakładamy, że osoba która testuje wie co ma zrobić.
„Wyjątki” – w tym przypadku potrzebna jest spora wiedza w jakich okolicznościach wyjątki mogą się pojawić.
„Logowanie” – nie powinno być żadnego problemy ze zrozumieniem co należy zrobić. - Karta testów jako kryterium akceptacji.
W projektach agileowych, gdzie specyfikacja ma formę historyjek użytkownika, często pojawiają się kryteria akceptacji. Są to warunki jakie muszą być spełnione aby właściciel produktu uznał, że dana część funkcjonalności została dostarczona.
Kryteria często przyjmują dość szczegółową formę, ale można je (przy małych modyfikacjach) traktować jako kartę testów.
Przykłady:
„Użytkownik może ukończyć uzupełnianie formularza przestrzegając reguł walidacji” – jest to forma, która zbiera kilka możliwych kryteriów.
„Pomimo wyjątków w systemie, dane użytkownika zostają zapisane” – zapis, który wymusza na testerzy sprawdzenie zachowania aplikacji przy wyjątkach.
„Posiadając założone konto w systemie użytkownik jest w stanie się do niego zalogować” – tutaj należy uważać z zredukowaniem testu do jednego przypadku.
Wszystkie z powyższych przykładów są stosowane w projektach, ale najpopularniejszą formą pozostaje karta testów, która jest czytelnym poleceniem (wersja 2). Warto podkreślić, że test charter nie pokazuje JAK mamy testować, tylko CO jest do testowania. Zakładamy więc, że tester jest wystarczająco doświadczony, aby mógł samodzielnie zdefiniować techniki testerskie i dane testowe.
