Tworzenie scenariuszy testowych to jedno z podstawowych zadań testera oprogramowania. Tester, który dysponuje scenariuszem testowym, może przetestować całą funkcjonalność danego oprogramowania. Jak należy go przygotować? I czy scenariusze testowe są jednocześnie przypadkami testowymi?
Czym jest scenariusz testowy?
Zagadnienie “scenariusz testowy” pojawia się w pracy testera oprogramowania bardzo często, bo to od niego zależy przebieg procesu testowania. Jest to dokument składający się z przypadków testowych, tworzących logiczny ciąg zdarzeń, skupiający się od A do Z na niezbędnych krokach i wynikach testowania.
SJSI (Stowarzyszenie Jakości Systemów Informatycznych) reprezentujące w Polsce organizację ISTQB uznaje “scenariusz testowy” za synonim “specyfikacji procedury testowej” – to oznacza, że te określenia można stosować zamiennie.
Elementy i założenia scenariuszy testowych
Scenariusz testowy, podobnie jak scenariusz filmowy, ma stałe elementy składowe. W scenariuszu testowym należy przygotować trzy części – organizacyjną (zawiera m.in. logo i nazwę firmy, osobę wykonująca test, nazwę testu, wersję testu, testowane elementy), opisującą (cel testu, warunki wstępne, etapy testowania, rezultaty) oraz końcową, która uwzględnia datę przygotowania, dane osoby sporządzającej oraz zatwierdzającej scenariusz.
Idea scenariuszy testowych zakłada, że przeprowadzony test będzie wnikliwy i w pełni pokryje się z możliwościami korzystania z danej aplikacji. Z tego powodu specyfikacja procedury testowej dobrze uzupełnia dokumentację oprogramowania. Warto je tworzyć w celu przetestowania skomplikowanych systemów lub takich, w których nawet najmniejsze błędy mogą spowodować ogromne straty (np. w branży medycznej czy energetycznej, gdzie utrata pieniędzy może być najmniejszym problemem). Sens tworzenia scenariusza w celu testowania produktu, który jest prosty lub doskonale znany zespołowi, pozostaje kwestią dyskusyjną.
Scenariusz testowy a przypadek testowy – różnice
Przypadki testowe i scenariusze testowe są ze sobą ściśle powiązane, jednak zdecydowanie nie można postawić pomiędzy nimi znaku równości. Ich zależność polega na tym, że przypadki testowe są podzbiorem scenariusza. Jeden scenariusz testowy może zawierać w sobie kilka przypadków testowych, w zależności od ilości funkcji do przetestowania. Przypadki testowe nie zawsze tworzą ciąg logicznie powiązanych kroków – dzieje się tak tylko wtedy, gdy warunki końcowe jednego przypadku są jednocześnie warunkami wstępnymi drugiego przypadku.
Od czego zacząć przygotowywanie?
Stworzenie efektywnego i rzetelnego procesu testowania wymaga określenia wszystkich funkcjonalności danej aplikacji. Najczęściej są one zawarte w specyfikacji wymagań systemowych lub biznesowych.
Pierwszym elementem części opisującej scenariusza testowego jest cel testów, będący jednocześnie jego nazwą. Cel musi być tak sprecyzowany, aby po teście można było określić, czy zakończył się on sukcesem, czy porażką. W dalszej kolejności określa się warunki wstępne oraz czynności przygotowawcze, które wskazują, co należy zrobić, aby testy były możliwe do zrealizowania. Etapy testowania powinny być rozpisane możliwie szczegółowo – tak, aby każdy mógł przeprowadzić test zgodnie z założeniami scenariusza.
Elementem każdej specyfikacji procedury testowej są przypadki testowe, które zostaną sprawdzone w praktyce. Zbiór przypadków testowych powinien obejmować wszystkie możliwości, które mogłyby zostać wykonane “na produkcji”, czyli przez użytkownika. Łatwym sposobem ich przedstawienia są “historie”, które opowiadają o tym, w jaki sposób użytkownik mógłby korzystać z aplikacji. W zależności od rodzaju danych wejściowych wyróżniamy dwa rodzaje przypadków testowych – niskiego poziomu i wysokiego poziomu.
Przypadek testowy niskiego poziomu (konkretny, low level test case), w przeciwieństwie do przypadku wysokiego poziomu (logicznego, high level test case), na poziomie implementacji uwzględnia w sobie wartości wejściowe i oczekiwane wyniki. Z tego powodu przypadki testowe wysokiego poziomu określa się także mianem abstrakcyjnych. Dzięki temu każdy element oprogramowania może zostać przetestowany – także w przypadku, gdy nie przewidziano danych wejściowych i prawdopodobnych wyników.
Korzyścią uzyskiwaną dzięki tworzeniu i realizacji scenariuszy testowych jest ograniczenie ryzyka związanego z niedopracowanymi funkcjonalnościami oprogramowania. Ich tworzenie może mieć miejsce na etapie analitycznym, czyli jeszcze przed napisaniem pierwszej linijki kodu. Nie jest to jednak reguła – nie ma przeciwwskazań, aby scenariusz testowy powstał w końcowej fazie wdrożenia.
