Redakcja
Oczekiwany rezultat (OC) i warunek końcowy (WK) pochodzą z popularnego szablonu przypadku testowego oraz z definicji standardu IEEE 610. Bez podważania sensu takiej notacji przeprowadźmy analizę, w jaki sposób przypadek testowy może zyskać dzięki tym elementom i ile może stracić jeśli są one źle określone. Szczególnie, że mogą one dotyczyć zarówno testu wykonywanego ręcznie, jak i automatycznie.
Definicje ISTQB ze słownika SJSI wyglądają następująco:
Oczekiwany rezultat – zachowanie modułu lub systemu w określonych warunkach określone na podstawie specyfikacji lub innego źródła.
Warunek wyjściowy (od redakcji – częściej nazywany warunkiem końcowym) – warunki środowiska lub stanu oprogramowania, które muszą być spełnione po wykonaniu testu lub procedury testowej.
Dla uzupełnienia definicji podamy sobie również czym jest warunek wstępny (WW):
Warunek wstępny – warunki środowiska i stanu oprogramowania, jakie muszą być spełnione zanim moduł lub system będzie mógł być uruchomiony przez określony test lub procedurę testową.
OC jest więc zachowaniem lub reakcją systemu na działania użytkownika. My „prosimy" system o "zrobienie czegoś”, a system zwróci oczekiwany przez nas rezultat. Jeżeli system zachowa się inaczej niż zakładaliśmy pojawia się wstępna informacja o defekcie. Wykonując na kalkulatorze operację mnożenia dwóch wartości oczekujemy, że system zwróci nam poprawny rezultat.
WK z kolei jest pewnym stanem systemu, w jakim system jest pozostawiony po uruchomieniu testu. Inną rzeczą, która pozwala go zrozumieć, to fakt, że warunek końcowy jednego testu może być warunkiem wstępnym (WW) innego testu. Po zakończeniu testu zostajemy z sumą wyświetloną na ekranie.
Wtłaczając definicje i przykład w szablon, przypadek testowy mógłby wyglądać następująco:
ID 1.1
Tytuł: Poprawne zalogowanie się do aplikacji
Warunek wstępny: włączona przeglądarka na stronie http://.............../user/login/; użytkownik nie może być zalogowany
Kroki do wykonania:
- podaj istniejący login: jkowalski,
- podaj istniejące i przypisane do loginu hasło: 2012,
- naciśnij klawisz "Zaloguj".
Oczekiwany rezultat: Zalogowanie się jako użytkownik jkowalski z przekierowaniem na stronę główną.
Warunki końcowe: Użytkownik jest zalogowany.
Pisaliśmy wcześniej, że WK może być WW dla innego testu. W powyższym przypadku, jeśli kolejnym testem byłoby wykonanie jakiegoś działania dostępnego tylko dla zalogowanego użytkownika, to WW byłby właśnie: użytkownik jest zalogowany. Gdybyśmy natomiast chcieli być bardziej precyzyjni to możemy podać więcej szczegółów, jak poziom uprawnień, stronę/ekran z którego startujemy itd.
Częste błędy popełniane przez projektantów i związane z OC i WK to:
- pomijanie OC lub WK w szablonie przypadków, np.*
- powielanie tej samej informacji w OC i WK,
- wpisywanie w OC tego co powinno się pojawić w WK i na odwrót, np.*
*) unikamy linkowania do źródeł błędnych OC i WK ponieważ lepiej je to pozycjonuje, a to z kolei krzewi złą wiedzę.
Dobre rady:
- czasami OC i WK to rzeczywiście to samo więc możemy zrezygnować z WK,
- OC (raczej) nie podaje się w przypadkach testowych wysokiego poziomu,
- w związku z powyższymi, w narzędziach projektowania i przechowywania testów, OC i WK warto zostawić jako pola opcjonalne,
- kiedy projektujemy przypadki z myślą o przyszłych scenariuszach to WW i WK są obowiązkowe; wtedy przypadek N przygotowuje środowisko do uruchomienia przypadku N+1.
