Testerze, eksploruj

To było wiele lat temu. Moja pierwsza praca, pierwszy system. Dokumentacji brak, wymagania spisane na kartkach przy kawie z kierownikiem działu. System wspomagał inwestycje, tworzony był dla konkretnego odbiorcy przez jednego developera, który był dodatkowo jednocześnie analitykiem, wykonawcą i testerem. Gdy przyszłam pierwszego dnia do pracy, usłyszałam „Siadaj i testuj’. Myślę, że to były moje pierwsze testy – i do tego były to testy eksploracyjne (sic!). Minęło wiele czasu, testy eksploracyjne zyskały na ważności, zostały sformalizowane, opisane w fachowej literaturze.

Kiedy warto pomyśleć o eksploracji?

Według słownika International Software Testing Qualifications Board, a konkretnie Jamesa Bacha, testy eksploracyjne to: „Nieformalna technika projektowania testów, w której tester projektuje testy podczas ich wykonywania oraz wykorzystuje informacje zdobyte podczas testowania do projektowania nowych i lepszych testów”. Polemizując z ISTQB, dla mnie ważniejszym czynnikiem jest poznawanie aplikacji – szczególnie w przypadku, gdy nie dysponujemy dokumentacją. Testy eksploracyjne oraz rozmowy z developerami i uczestnikami projektu dają bowiem możliwość dość szybkiego poznania każdego systemu. Z definicji nie potrzebujemy do testów eksploracyjnych żadnej dokumentacji. Potrzebny jest z kolei cel i określone ramy czasowe. Kiedy zatem warto pomyśleć o eksploracji?

Pierwsze spotkanie testera z aplikacją

Zaczynamy pracę przy nowym projekcie zupełnie zieloni, mając nadzieję na pracę z  dokumentacją i możliwość szybkiego zdobycia wiedzy. Jednak często zdarza się, że dokumentacji nie ma. Są za to jakieś często szczątkowe informacje w formie tekstu, najczęściej już nieaktualnego, a reszta zamknięta jest w głowach developerów. Z taką właśnie sytuacją przyszło mi się zmierzyć w pierwszym moim projekcie – był to projekt na kasy fiskalne, na których oprócz sprzedaży miało być możliwe ładowanie telefonów komórkowych, przyjmowanie paczek itp. Dodam, że firma, dla której przygotowywany był projekt, to jedna ze spółek wielkiej organizacji. W jej skład wchodziły dwa giganty, jeśli chodzi o kasy fiskalne na polskim rynku.

Projekt był właśnie wznawiany po raz kolejny. Dotychczasowa praca nad nim wyglądała w ten sposób, że dorabiano funkcjonalności i porzucano dalsze prace. To, co już powstało, to panel klienta, produkty na kasy fiskalne miały właśnie być tworzone. Zatrudniono project managera, analityka, dodatkowych developerów i test managera. Mój pierwszy dzień, a pamiętam go doskonale, we wszystkim przypominał pierwszy dzień w mojej starej firmie wiele lat temu. I tak historia zatoczyła koło. Zastałam aplikację dla klienta bez dokumentacji, założeń, wymagań, a miałam tworzyć plan testów, strategie testowania, przypadki testowe itd. Pozostało usiąść do eksploracji. Dałam sobie dwa pełne dni. Cel – zapoznanie z aplikacją. Raport z testów zawierał kilkadziesiąt błędów i usterek wraz ze zrzutami ekranów. Na jego podstawie powstały zadania w JIRA dotyczące błędów, a później zaprojektowane zostały przypadki testowe. Sporym problemem był tu brak jakichkolwiek wymagań, wszystko było robione intuicyjnie przez developerów. Testy eksploracyjne w tej sytuacji nie tylko pomogły mi jako testerowi, ale też przysłużyły się rozwojowi aplikacji. Zaczęliśmy dyskutować o tym, czy aplikacja jest „user friendly”, i rozmawiać o ergonomii w systemie. Tak testy eksploracji spełniły swoje zadanie.

Przeczytaj także:

• Dlaczego testy oprogramowania są ważne
• Minimalistyczny przypadek testowy

Gdy kończy się czas…

Testy eksploracyjne mogą być wykorzystane również pod koniec projektu, gdy błędów do naprawy jest całe mnóstwo. Naprędce dokładane są nowe funkcjonalności, a co za tym idzie – nowe wersje wychodzą prawie codziennie i pojawia się konieczność bieżącego testowania wraz z regresją. Który tester tego nie zna? To moment, kiedy wielu kierownikom czy project managerom przychodzi do głowy ograniczanie testów. Nigdy na to nie pozwalajmy. To prosta droga do zakończenia projektu niepowodzeniem. Być może warto zaproponować wtedy właśnie testy eksploracji. W literaturze fachowej zdania są podzielone: spotkacie się albo z absolutnym „nie”, jeśli chodzi o eksplorację w momencie, gdy prowadzone są testy regresji, albo wręcz przeciwnie. Zwolennikiem zastosowania testów eksploracji w czasie regresji jest Simon Schrijver. Zgadzam się z tym podejściem, gdyż testy eksploracyjne wykonane pod koniec projektu to liczne plusy, między innymi:

• Zyskujemy na czasie. Jeśli go brakuje, zamiast ograniczać testy, pozwólmy testerom pracować w oparciu o wiedzę i doświadczenie eksploracyjnie (czyli pracę bez formalności).
• Testy eksploracyjne pozwalają zidentyfikować błędy w przyjętej strategii testowania.
• Po sesji może okazać się, że konieczna jest weryfikacja naszych priorytetów i powinniśmy zająć się w pierwszej kolejności innymi obszarami.
• Dzięki spisywaniu wszystkiego i dzieleniu się wiedzą z innymi członkami zespołu wzrasta ogólna wiedza o aplikacji, co jest bardzo cenne w sytuacjach krytycznych.

Przeczytaj także: Czy warto stosować BDD?

Gdy brakuje testera…

Jeszcze jeden przykład wykorzystania testów eksploracyjnych opisuje wspomniany już Simon Schrijver. Pisze o sytuacji, gdy tester projektowy idzie na urlop, nie kończąc swojej pracy. Mając do dyspozycji innego testera (niemającego jednak wiedzy projektowej), kierownik poprosił go o pomoc, jednocześnie proponując pracę z analitykiem biznesowym w parze. Takie „testowanie w parze”. Analityk biznesowy miał wiedzę dotyczącą projektu i instruował testera. Tester z kolei, jako osoba wykonująca testy na bazie swojego doświadczenia, mógł odpowiednio zarządzać swoimi testami dzięki analitykowi. Moim zdaniem to bardzo ciekawy pomysł.

Testy eksploracyjne a kompetencje

Na koniec chciałabym jeszcze zwrócić uwagę na jeden ważny aspekt. Tego typu testy powinny być wykonywane przez doświadczonych testerów. Nie dajmy się zwieść temu, że niektórzy nazywają testy eksploracyjne „testami na wariata” (czyli testami, które wszyscy, bez względu na doświadczenie, mogą wykonać). Można się też spotkać z przekonaniem, że „testować każdy może”. Nigdy nie zgadzałam się z tym powiedzeniem i będę z nim polemizować. Z mojego doświadczenia wynika, że tylko tester doświadczony, który zdobył doświadczenie w wielu projektach i zmierzył się z wieloma sytuacjami krytycznymi, wygrał lub przegrał wiele bitew (zarówno z kierownictwem, jak i developerami) jest w stanie, drążąc do upadłego, trafić w sedno. W naszej testerskiej naturze jest to, że dążymy do destrukcji. Właśnie taki tester nastawiony na destrukcję, z bagażem wyżej opisanych sytuacji, będzie mógł znaleźć szybko luki, których naprawa być może będzie kluczowa dla uratowania projektu.

Wielką wartością byłoby umożliwienie uczenia się w czasie sesji testów eksploracyjnych praktykantowi, stażyście czy juniorowi. Oni właśnie nabierają doświadczenia i jeśli mamy możliwość, aby kształtować kolejne pokolenia dobrych testerów – róbmy to.

Przeczytaj także: Czy testy BD są naprawdę potrzebne?

Podsumowanie

Mam nadzieję, że udało mi się pokazać, jak wiele zalet mają testy eksploracyjne. Opisałam co prawda jedynie wybrane zastosowania technik eksploracyjnych, ale możliwości i korzyści jest znacznie więcej. Osobiście chętnie wykorzystywałam i wykorzystuję testy eksploracyjne w mojej pracy. Jeśli mają doprowadzić do powstania jeszcze lepszego produktu, to zachęcam: korzystajmy z nich! Zatem, drogi testerze – eksploruj, bo warto.

Źródła:

1. Adam Roman, „Testowanie i jakość oprogramowania, Modele, techniki, narzędzia”. Wydawnictwo Naukowe PWN SA, Warszawa 2015