Redakcja
Najważniejsze źródła wiedzy w testowaniu, jak ISO 29119, IEEE 829 czy ISTQB nie mają definicji, szeroko używanego w polskich projektach, scenariusza testowego. Ich głównym obiektem jest specyfikacja procedury testowej rozumianej jako zbiór akcji do wykonania testów. Z jednej strony to niewiele mówi, a z drugiej zupełnie inaczej postrzegam to w swoich projektach.
Jak wygląda to w innych projektach, opisałem już na przykładzie z kilku publikacji.
Pominę tutaj formalną strukturę samego scenariusza, a skoncentruję się na jego zawartości.
A. Zbiór testów
Dla mnie scenariusz to zbiór logicznie powiązanych testów, które tworzą scenariusz, jak np. ten znany z filmów. Kolejne akcje (sceny) mają być ze sobą nierozerwalnie związanie i prowadzić nas do finału, który jest konsekwencją wszystkich działań jakie wykonał tester (aktor). Zanim przejdziemy dalej warto jeszcze określić czym jest test. Test może być popularnym przypadkiem testowym albo innym weryfikatorem, który powinien składać się z akcji i wykonania i opcjonalnie opisem co powinno się po akcji wydarzyć. Oczekiwany rezultat (OR) jest opcjonalny, ponieważ można go pominąć. Po pierwsze jest oczywisty dla testera, który wykonuje go samodzielnie, po drugie może być zbędny w wykonaniu automatycznym ponieważ zabiera dodatkowe cenne sekundy. Sam scenariusz powinien mieć tytuł abyśmy wiedzieli co weryfikuje.
Przetestujmy system, który pozwala nam pobierać wybrane dokumenty. Scenariusz „Pobieranie dokumentów” mógłby wyglądać następująco:
a. AKCJA Uruchom stronę internetową do pobierania dokumentów
OR Strona do pobierania dokumentów załadowała się.
b. AKCJA Zaloguj się w systemie.
OR Użytkownik zalogował się w systemie.
c. AKCJA Wyszukaj dokument.
OR Wyświetlona jest lista dokumentów.
d. AKCJA Wybierz pierwszy z listy dokument.
OR Wyświetlony jest podgląd dokumentu.
e. AKCJA Naciśnij „POBIERZ”.
OR Dokument został pobrany.
f. AKCJA Wyloguj użytkownika
OR Użytkownik zostaje wylogowany.
Gdyby scenariusz ten składał się z kilku szczegółowo opisanych przypadków testowych, można by scenariusz sprowadzić do prostego PTa > PTb > PTc > PTd > PTe > PTf, gdzie poszczególne oznaczenia to identyfikatory przypadków testowych z referencją do miejsca, gdzie się one znajdują (referencja może być prostym linkiem).
Dlaczego możemy pominąć oczekiwany rezultat w środku scenariusza. Dlatego, że przykładowa niemożność wykonania testu „c” wynika z niepowodzenia testu „b” i już tu możemy w logach napisać, że nastąpił incydent uniemożliwiający dokończenia scenariusza. Oczywiście OR dla testu końcowego musi być określony. Bez niego nie będziemy wiedzieli czy scenariusz zakończył się powodzeniem. W naszym scenariuszu ostatnim testem jest test „e”.
Scenariusz jest więc zestawem testów, w którym poprzedni test ustawia środowisko i parametry do uruchomienia kolejnego testu. Test „a” uruchamia nam środowisko, test „b” daje nam uprawnienia do weryfikacji funkcji dostępnych tylko dla użytkowników z określonymi uprawnieniami. Test „c” sprawdza nam poprawność przeglądania wszystkich dokumentów. Test „d” daje nam możliwość podglądu dokumentu. Test „e” pokazuje możliwość pobrania i jest tak naprawdę końcem części weryfikującej działanie. Test „f” „czyści” nam środowisko i przygotowuje do uruchomienia kolejnego scenariusza.
B. Najprostsza ścieżka przejścia przez oprogramowanie
Jak widzimy na powyższym przykładzie, w scenariuszu nie ma zbędnych kroków, a jedynie najkrótsze możliwe przejście przez aplikację. Pozwala nam on nie tylko przetestować kluczowe funkcje w aplikacji, ale również zrobić to w optymalnie krótkim czasie. Czym bardziej wydłużona ścieżka przejścia przez oprogramowanie tym dłuższy czas wykonania i tym większe prawdopodobieństwo „wykrzaczenia” się scenariusza po drodze. Stworzenie scenariusza, który miałby pobrać plik, a po pobraniu wykonać dalsze akcje niezwiązane z samym pobieraniem mogłyby doprowadzić do tego, że niedziałające pobieranie zablokowałoby weryfikację innych funkcji. Z perspektywy automatyzacji krótsze scenariusze będą miały większą efektywność. Są one lepsze zarówno dla testów przeciwregresywnych i dymnych.
Jedynym kłopotem z takimi krótki scenariuszami jest to, że mogą one nie odzwierciedlać prawdziwego użycia oprogramowania. Będą więc miały mniejszą przydatność w testach wydajności lub niezawodności. Na potrzeby tych testów albo łączy się scenariusze w większe paczki, albo definiuje się specjalne scenariusze dla tego typu testów.
C. Pozytywne dane testowe
Kontynuując temat najprostszej ścieżki, trzeba dodać, że szybkie testy w scenariuszu wymagają danych pozytywnych. Dane negatywne zatrzymają nas w miejscu i nie pozwolą przejść dalej, albo ustawiają status środowiska, tak, że może zostać zaburzony cały scenariusz.
Negatywne scenariusze mogą być używane do sprawdzenia czy dane, które nie powinny być przetworzone rzeczywiście są blokowane, albo do sprawdzenia, czy osoby bez odpowiednich uprawnień nie mogą używać danych funkcji. Stosujemy je więc głównie w testach bezpieczeństwa.
Jeśli już chcemy projektować negatywne testy to powinny one bazować na pozytywnych scenariuszach z odchyłką na ostatnim teście. W automatyzacji zazwyczaj będzie to negatywna dana (lub zbiór danych) w pojedynczym, końcowym teście. Przy uruchomieniu testów przez testera może on skorzystać ze scenariusza aby doprowadzić system do danego stanu i następnie eksplorować jeden punkt. Ciężko tu jednak jednak mówić o scenariuszu. Ani nie jest to normalne zachowanie użytkownika, ani nie ma tu logicznego powiązania pomiędzy końcowymi testami.
W naszym przykładzie mogłoby to wyglądać następująco:
a. AKCJA Uruchom stronę internetową do pobierania dokumentów.
OR Strona do pobierania dokumentów załadowała się.
b. AKCJA Zaloguj się w systemie.
OR Użytkownik zalogował się w systemie.
c1. AKCJA Wyszukaj dokument z za długą nazwą.
OR Wyświetlony jest komunikat błędu.
c2. AKCJA Wyszukaj dokument z za krótką nazwą.
OR Wyświetlony jest komunikat błędu.
c3. AKCJA Wyszukaj dokument pozostawiając pole puste.
OR Wyświetlony jest komunikat błędu.
itd.
Podsumowując, scenariusz testowy jest możliwym i szybkim przepływem przez aplikację do funkcji, którą chcemy zweryfikować. Nadaje się do weryfikacji nie tylko samej funkcji, ale i całej ścieżki, która umożliwia nam funkcję sprawdzić. Przypadek testowy będzie miał warunki początkowe tak zdefiniowane by można było od razu uruchomić funkcję. Scenariusz pokaże nam nie tylko jak weryfikować funkcję, ale również jakie kroki należy przejść by nasz cel osiągnąć.
Autor: Grzegorz Ler
