Przypadek testowy jako wynik testowania eksploracyjnego?

W sieci pojawia się coraz więcej publikacji (również po polsku) o tym, jak testowanie eksploracyjne pomaga nam tworzyć przypadki testowe. Jest to podejście na wskroś błędne.

 

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

 

 

 

Najbliższe terminy szkoleń

 

4-5.09.17 - Kraków

Automatyzacja testowania


6-8.09.17 - Wrocław

ISTQB Poziom Podstawowy (Foundation Level)


11-12.09.17 - Warszawa

ISTQB Tester Zwinny (Agile Tester)

 

Partnerzy

Narzędzia testerskie