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

Czy testowanie jest dla każdego?

Do tego wpisu zainspirowała mnie dyskusja, jaka rozgorzała wokół gościnnego wpisu Marcina, który jakiś czas temu opublikowałam. Pytanie o to, czy testowanie oprogramowania jest dla każdego, pojawia się często w kończących się gorącymi wymianami zdań wątkach na grupie facebookowej Testowanie Oprogramowania.

KISS, czyli nie komplikuj, głuptasku

Łapka w górę, kto słyszał o regule KISS. Oczywiście nie mogę Was widzieć, ale wyobrażam sobie, że zgłosiłby się każdy, kto już dłuższy czas pracuje przy wytwarzaniu oprogramowania, a ten, kto pisze automaty i programuje już na sto procent.

“Mindset” to nie wszystko

Sporo czasu zabierałam się do tego, by napisać dzisiejszy wpis. I nie, wcale nie chodzi mi o to, że powinnam była go wrzucić wczoraj, ale o to, że trochę obawiam się wsadzania kija w mrowisko.

Pin It on Pinterest

Podoba Ci się wpis?

Podziel się ze znajomymi!