Dzisiaj będzie o, moim zdaniem, największej wirtuozerii testowania, technice noszącej znamiona niemalże sztuki, dającej czystą przyjemność z wykonywanej pracy: testowaniu eksploracyjnym. Przyznam szczerze, że bardzo lubię tę technikę, taka testerska improwizacja daje mi niesamowitą przyjemność płynącą głównie z odkrywania aplikacji. I to bez konieczności studiowania wymagań. Nie wymaga w zasadzie większego skupienia, bo można po prostu dać się ponieść i… klikać co popadnie.

Zacznijmy od przypomnienia czym są testy eksploracyjne:

testowanie eksploracyjne (ang. exploratory testing) – 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 1

A kiedy warto korzystać z tej techniki?

Kiedy czas nam nie sprzyja

W książce, z której przytoczyłam definicję, testowanie eksploracyjne jako remedium na brak czasu na testy jest wymienione jako pierwsze. I nie sposób się nie zgodzić z autorem. Jeśli mamy spore doświadczenie w testowaniu, a przy tym dobrze znamy wszystkie zakamarki naszej aplikacji, to intuicyjnie i bardzo szybko znajdujemy miejsca, w których coś jest nie tak. Zauważyłam, że testując eksploracyjnie poważne błędy znajduję już w pierwszych kilku chwilach testowania. A te ciekawsze, ale niekrytyczne, nieco później. Testując według wymagań na kluczowe problemy trafiam niejednokrotnie dopiero pod koniec testowania, tym samym daję znać programiści relatywnie późno – a przecież czas, w którym testowałam mógł już spokojnie poświęcić na naprawę.

A po co komu dokumentacja?

Ten rodzaj testów często wymuszony jest przez brak wymagań czy dokumentacji w ogóle. I w rzeczy samej jest ona zupełnie niepotrzebna. Wczuwamy się w rolę użytkownika – co samo w sobie stanowi atut – a ten, jak wiemy, raczej nie dysponuje żadną instrukcją. Tym samym głównymi filarami oceny stają się nasze doświadczenie oraz (a niejednokrotnie tylko) zdrowy rozsądek. Przy okazji umożliwia nam to znalezienie tych błędów, na które w naturalnym procesie odkrywania programu natrafi nasz użytkownik, a więc tych, na których możemy stracić najwięcej.

Zwinnie jak w Scrumie

Sama idea testów eksploracyjnych idealnie wpisuje się w sprintową naturę metod zwinnych. Brak sztywnych ram tego rodzaju testów umożliwia elastyczne dostosowanie do tego, co przynosi nam interacja. Często, kiedy nie wszystko idzie po naszej myśli, i na samym końcu pozostaje nam niewiele czasu na testy (patrz punkt pierwszy), testowanie ad hoc może okazać się jedynym ratunkiem dla celu sprintu.

Nauka przez testowanie

Testowanie eksploracyjne jest fenomenalnym sposobem na naukę zarówno dla niedoświadczonych testerów dopiero poznających techniki zawodu, jak i starych wyjadaczy, którzy chcą jak najszybciej poznać własną aplikację. “Przeklikanie” aplikacji celem znalezienia rzeczy, które są zdaniem testującego zrobione źle, to zdanie, które lubię dawać nowym kolegom. I z reguły już po jednej takiej sesji nieźle orientują się w projekcie.

Remedium na wszystko?

To zdecydowanie nie jest tak, że testowanie eksploracyjne może i powinno być jedynym. Jeżeli nasza aplikacja ma niezbyt prostą logikę biznesową, to prawdopodobieństwo że przetestujemy wszystkie przypadki jest stosunkowo niskie, zwłaszcza, jeśli brak nam znajomości projektu i wiedzy domenowej. Z resztą największy zysk z testów eksploracyjnych osiągniemy właśnie wtedy, kiedy posiadamy te dwa atuty: to dzięki nim testy ad hoc mogą być szybkie i wydajne, i możemy obyć się bez dokumentacji. Testy eksploracyjne raczej nie będą dobrą techniką, kiedy konieczne jest wykonanie testów regresji, zwłaszcza rozbudowanej aplikacji. Nie dadzą nam również informacji o pokryciu testami, a to z kolei nie pozwoli nam wykazać w wymierny sposób korzyści płynących z testów.

Oczywiście to tylko niektóre, a w dodatku subiektywnie wybrane, zalety i wady testów ad hoc A Wy? Lubicie testowanie eksploracyjne?


[1] Adam Roman, “Testowanie i jakość oprogramowania. Modele, techniki, narzędzia”, Wydawnictwo Naukowe PWN.

Podobał Ci się wpis? Podziel się ze znajomymi:


Najnowsze wpisy

Teoria vs. Praktyka

Kto z Was nigdy nie zastanawiał się nad tym, czy teoria jest do czegoś potrzebna, niech pierwszy rzuci we mnie „Testowaniem oprogramowania”.

CzytanQA: Trzy książki, bez których nie mogę się obejść

Książka Adama Romana pt. „Testowanie i jakość oprogramowania” jest jedną z trzech, których od długiego czasu nie odkładam nawet na półkę i do których zaglądam niemal codziennie.

Narzędzia, które ułatwiają mi (testerski) żywot

Stawiam, że każdy z Nas zna kilka takich aplikacji, które choć do testów czy programowania nie są zbyt potrzebne, to ułatwiają nam życie i które są jednymi z pierwszych instalowanych na świeżym systemie.