Przypadek testowy jako wynik testowania eksploracyjnego?

Zgodnie z ankietą State of Testing 84% ludzi używa jako głównej metody testowania właśnie testów eksploracyjnych. Czytając jednak pewne publikacje można dojść do wniosku, że część osób nie rozumie, czym jest TE. Może to wynikać z:

• używania „przeterminowanej” definicji, promowanej przez ISTQB - testowanie eksploracyjne to nieformalna technika projektowania testów, w której tester projektuje testy w czasie, gdy są one wykonywane i wykorzystuje informacje zdobyte podczas testowania do projektowania nowych i lepszych testów; Bach już wielokrotnie się tej definicji wyparł i popchnął TE do przodu [http://testerzy.pl/baza-wiedzy/testowanie-eksploracyjne-3-0]. Rozprawiamy się z nią w jednym z artykułów [http://testerzy.pl/baza-wiedzy/testowanie-eksploracyjne-kontra-istqb]
• złej interpretacji definicji i tłumaczenia, że „lepsze testy” oznaczają przypadki testowe
• utożsamiania testowania eksploracyjnego z adhocowym klikaniem
• postawienia znaku równości między TE a każdym innym testowaniem bez dokumentacji.

Należy na początku uświadomić sobie, że testowanie eksploracyjne jest dużo silniejszą strategią od testowania w oparciu o przypadki testowe. Przede wszystkim wymaga większych, zarówno twardych, jak i miękkich umiejętności testerskich. Również w warstwie zarządczej jest to metoda, która zmusza do przeorientowania swojego poglądu na kontrolę testowania. W wymiarze projektowym to jak przełączenie się z myślenia kaskadowego na zwinne. 

Jak wygląda formalny proces tworzenia przypadków testowych w oparciu o specyfikację (w dowolnej formie)? Na początku zapoznajemy się ze specyfikacją testową i określamy, co chcemy zweryfikować (w ISTQB tak powstały dokument nazywa się warunkiem testowym), a następnie, używając technik projektowania, wytwarzamy przypadki testowe. Te przypadki mogą być przed uruchomieniem poddane przeglądowi, ale ich przegląd może być również częścią uruchomienia. Tak powstaje formalny dokument przypadku testowego. Jego celem jest:

• przygotowanie instrukcji wykonania testu dla innego testera – przypadek testowy staje się nośnikiem wiedzy testerskiej
• udokumentowanie wykonania testu opisane wynikiem – wynik jest nośnikiem informacji o jakości oprogramowania. 

W testowaniu eksploracyjnym, nazywanym przez laików nieformalnym, nasze testowanie zaczyna się od celu testów wpisywanego w test charter (spolszczenie - statut testów). Następnie eksplorujemy oprogramowanie (uruchamiamy je) bazując na celu oraz próbujemy ten cel zrealizować. Podsumowaniem testowania będzie raport, który jest nośnikiem informacji o stopniu realizacji celu, jakości oprogramowania oraz wiedzą o oprogramowaniu. 

Dlaczego ktokolwiek miałby więc po uruchomieniu testów eksploracyjnych tworzyć przypadki testowe? Uzasadnieniem mogłoby być przeformatowanie istniejącego test chartera w formalny przypadek testowy, aby uzyskać inny nośnik wiedzy, a raportu eksploracji w raport uruchomienia przypadków testowych. Na pierwszy rzut oka wygląda to na irracjonalne marnotrawstwo czasu, a w dalszej analizie możemy to tylko potwierdzić. Dlaczego od razu przy eksploracji oprogramowania nie tworzyć przypadków testowych i na ich podstawie raportować wykonanie? Prawdopodobną odpowiedzią jest to, że ci, którzy mówią o używaniu „testowania eksploracyjnego” do tworzenia przypadków nie znają i nie stosują notacji TE. Najpewniej swoje adhocowe klikanie w aplikacji opisują niepoprawną nazwą. Jeśli twierdzimy, że używamy testowania eksploracyjnego, używajmy również notacji do tego stworzonej. 

Jeszcze bardziej nieuzasadnionym tłumaczeniem dla wdrożenia eksploracji jest uruchomienie aplikacji celem jej opisania dokumentem przypadków testowych. Jest to odwrócenie logiki testowania formalnego, w którym na początku powstaje specyfikacja, a dopiero potem przypadek testowy. Dużo bardziej logicznym rozwiązaniem wydawałoby się stworzenie specyfikacji w oparciu o działające oprogramowanie, a następnie przetworzenie jej w przypadki. Powstała tak dokumentacja mogłaby więc służyć testerom, ale nie tylko. Mogłaby stać się podstawą dla innych ról projektowych jak analitycy czy wdrożeniowcy.

Możemy sobie śmiało powiedzieć, że użycie testowania eksploracyjnego do tworzenia przypadków testowych jest nielogiczne. To jak na kursie prawa jazdy uczyć się jeździć na manualnej skrzyni biegów, aby później do końca życia prowadzić już tylko auta w automacie. Robimy tak nie dlatego, że to ma sens, ale dlatego, że takie są zasady. Testowanie eksploracyjne jest łamaniem zasad, szczególnie tych, które generują pracę przynoszącą niewielkie korzyści. 

Radek Smilgin

Dodatkowe źródła

• http://testerzy.pl/baza-wiedzy/raportowanie-testowania-eksploracyjnego-w-sesjach
• http://testerzy.pl/wiesci-ze-swiata-testerow/state-of-testing-survey-2017-wyniki-ankiety