Koniec przypadków testowych

Kiedy mówimy o tym, że przypadki testowe odchodzą w zapomnienie, to mamy na myśli przypadki w ich najbardziej sformalizowanej formie. Definicję znajdziemy w standardzie IEEE 610, a powielana jest ona przez ISTQB oraz SJSI:

Przypadek testowy – zbiór danych wejściowych, wstępnych warunków wykonania, oczekiwanych rezultatów i końcowych warunków wykonania, opracowany w określonym celu lub dla warunku testowego, jak wykonanie pewnej ścieżki programu lub zweryfikowanie zgodności z konkretnym wymaganiem.

Definicja bezpośrednio nie podaje poziomu formalizmu przy zapisie przypadku jednak przez wymagane składowe można uznać, że jest to bardzo szczegółowa notacja.

Dlaczego odchodzimy od tworzenia przypadków testowych?

Jest wiele powodów, które skutkują coraz mniejszą obecnością przypadków w projekcie.

•  Szybkie metody wytwarzania oprogramowania nie zakładają osobnej roli projektanta testów, ale kładą nacisk na ograniczenie wysiłku przy tworzeniu dokumentacji. Nowe zasady prowadzenia projektów wykluczają więc w dużym stopniu przypadki testowe.
• Stworzenie, uruchomienie i utrzymanie specyfikacji przypadków testowych jest olbrzymim nakładem finansowym i organizacyjnym. Wymaga specjalistów o szerokiej wiedzy produktowej i testerskiej. W czasie odchudzania IT to jeden z tych elementów, który wypada jako pierwszy.
• Przypadki testowe nigdy nie były lubiane w projektach. Często je pomijano i testowano ad hoc-owo. W czasach zwinności otrzymano potwierdzenie, że są one rzeczywiście łatwe do zastąpienia przez inne formy notacji.
•   Przez wiele lat podstawową zaletą przypadków testowych było utrzymywanie wiedzy. Chodziło o to aby kolejni testerzy nie musieli przechodzić rozbudowanych szkoleń produktowych, tylko by od razu zaczynali testować bazując na istniejącej specyfikacji. Dziś ta wiedza przechowywana jest w narzędziach, dzięki którym możemy kontrolować ciągle zmieniające się założenia, pojawianie się nowych i modyfikowanie starych wymagań. Zmiany utrzymywane są np. w backlogu projektowym, a sama specyfikacja stała się jednocześnie nośnikiem weryfikatorów. Dzięki temu nie tłumaczymy już jednego dokumentu na drugi, a wszystko trzymamy w jednym wspólnym repozytorium.
•  Nigdzie, poza testowaniem funkcjonalnym, przypadek testowy nie był stosowany. W testach użyteczności mamy scenariusze użycia, w niezawodności i wydajności mamy profile operacyjne (czyli scenariusze użycia z częstotliwością użycia i czasem uruchomienia).
• Przypadek testowy nigdy nie był optymalnym rozwiązaniem. Przy całej złożoności systemów, nieskończonej liczbie możliwych danych testowych oraz zdarzeń w oprogramowaniu, przypadek uzyskiwał znikome pokrycie funkcjonalności. Jego eliminacja jest więc po prostu formą ewolucji i rozwoju samego testowania przez szukanie bardziej skutecznych narzędzi kontroli jakości.  

Czym zastąpić przypadek testowy?

Istnieje wiele form notacji, które pozwalają nam zrezygnować z przypadku testowego i ograniczyć konieczność tworzenia bardzo rozbudowanych dokumentów. Oto kilka przykładów.

1. Idee testowe - stosowane głównie do testów eksploracyjnych, na które składa się proste polecenie do wykonania. Wiedza i umiejętności testera stosowane są jako kompensacja braku szczegółów specyfikacji testowej.
2. Specyfikacja jako przykład - już sama specyfikacja może dawać przykład jak oprogramowanie ma być stosowane. Dzięki temu analitycy lepiej rozumieją produkt, programiści mogą go lepiej zaimplementować, a testerzy zweryfikować. Mając przykład tester po prostu w wykonywaniu sprawdzeń robi proste wariacje na danych lub na przepływie, sprawdzając więcej niż tylko to co w przykładzie zawarto.
3. Listy kontrolne - czyli zbiór elementów, które należy zweryfikować w oprogramowaniu, ale bez podania informacji w jaki sposób. Tu po raz kolejny przydaje się szersza wiedza z zakresu użytkowania danego produktu.
4. Historyjka użytkownika wraz z kryterium akceptacji - ta forma notacji wymagań jest nie tylko świetna do pracy z właścicielem produktu, ale również pozwala nam koncentrować testy na tym co najważniejsze. Kryteria akceptacji stanowią dla nas gotowe oczekiwane rezultaty zachowania się oprogramowania.
5. Skrypty testowe - skrypt jest przypadkiem testowym napisanym w formie umożliwiającej nam jego automatyczne uruchomienie. Zamiast zbierać je w notatniku, Excelu czy TestLinku to zbieramy je w plikach z kodem źródłowym i w repozytorium.

Docelowo rolę przypadku testowego przejmie algorytm nauczania maszynowego i to oprogramowanie określi co, w jakiej kolejności i przy pomocy jakich danych należy sprawdzić.

Czy gdzieś jeszcze funkcjonują przypadki testowe w swojej formalnej wersji? Oczywiście. Można je znaleźć w wielu projektach, które korzeniami sięgają początków obecnego lub końca ubiegłego wieku. Również organizacje publiczne lub działające na rzecz sektora publicznego pielęgnują swoją specyfikację testową. Większość nowych projektów nie tyle odchodzi od nich, ale nawet nie zakłada ich stosowania. Formalny przypadek testowy staje się więc archaizmem.