Testerska improwizacja, czyli o testowaniu ad hoc

27 stycznia 2018 | Słowotok, czyli felietony, Trochę teorii, Zwinny tester

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.

Najnowsze wpisy

CzytanQA: Steve Jobs

„Steve Job” autorstwa Waltera Isaacsona to dla mnie książka wyjątkowo z dwóch powodów. Po pierwsze, dostałam ją od bliskiej mi osoby. A po drugie dlatego, że to od niej zaczęło się moje zamiłowanie do biografii, reportaży i innych książek non-fiction.

CzytanQA: Labirynty Scruma

Scrumie książek napisano sporo. Dzisiejsza książka – Labirytnty Scruma – jest nieco inna, autor podchodzi do tematu od strony bardziej… problematycznej.

#3 Antywzorce w testowaniu oprogramowania: Korzystanie z niewłaściwego rodzaju testów

Wszyscy wiemy, jak z grubsza wygląda piramida testów: na dole jednostkowe, potem integracyjne, a szczytu akceptacyjne. Oznacza to po prostu tyle, że im wyżej w piramidzie, tym testów powinno być mniej… Ale mniej, to znaczy ile?

Pin It on Pinterest

Podoba Ci się wpis?

Podziel się ze znajomymi!