Przy testach eksploracyjnych tester musi wykorzystywać swą wiedzę wyniesioną z poprzednich, podobnych projektów. Toteż cały czas musi on ją wzbogacać, zbierając informacje o przydatnych narzędziach i źródłach danych testowych. Należy też mieć dużo przyjaciół (zwłaszcza w działach merytorycznych), którzy pomogą w dostarczeniu niezbędnych informacji - być może nawet kanałami pozasłużbowymi.

Przy testach eksploracyjnych nie można też mówić o tradycyjnym planowaniu prac zespołu testerów. Gdy mamy przygotowane scenariusze testowe, można z góry przewidzieć czas potrzebny do ich wykonania, rozsądnie go planując i szacując niezbędne zasoby. Przy testach eksploracyjnych obowiązuje zasada samozarządzania: tester musi potrafić wybrać podstawowe kierunki testowania - w ramach czasu, jaki ma do dyspozycji - i stwierdzić, czy już widać koniec (pozytywny lub negatywny).

Co więcej, w każdej chwili należy umieć odpowiedzieć na pytania dotyczące tego, co przetestowano, jakimi metodami, jakich danych użyto do testowania, jaki jest aktualny status testów oraz ich przewidywany wynik. Odpowiedź na ostatnie pytanie jest najistotniejsza i dobry tester eksploracyjny powinien jej udzielić już po połowie czasu przewidzianego na testy. Nie jest ona wtedy na ogół dostatecznie uargumentowana, nie jest też ostateczna i może się zmienić podczas dalszego procesu testowego.

Swego rodzaju podsumowaniem obu opisanych wyżej podejść do problemu testowania przy braku czasu lub dokumentacji (umożliwiającej tworzenie i wykonywanie scenariuszy testowych) jest metoda Agile, zaproponowana przez autorów tzw. manifestu Agile (http://agilemanifesto.org ). Proponują oni inne spojrzenie na jakość oprogramowania, wprowadzając nowy paradygmat jakości oprogramowania, który nazywają good enough quality (jakość wystarczająca). Sama idea jest starsza niż manifest Agile, pochodzi od Briana McWilliamsa, który w swoim artykule z 1996 r. "Utilitarians at the Gate" stwierdził, że oprogramowanie nie może być bezbłędne. Pomysł rozwinął i nazwę zaproponował James Bach w "Good Enough Quality: Beyond the Buzzword" z 1997 r.

Test elastyczny

Autorzy manifestu Agile proponują, by podstawowym kryterium jakości oprogramowania nie był brak błędów, lecz zadowolenie klienta. Dyskusja na ten temat przekracza ramy niniejszego artykułu, jedno jednak należy podkreślić, że już w testowaniu opartym na ryzyku jest to jedno z podstawowych kryteriów jakości oprogramowania.

Drugim, nieco kontrowersyjnym pomysłem zaproponowanym w Agile testing, jest testowanie parami. Zasady są proste i bardzo podobne do idei pair programming w metodyce eXtreme programming XP:

- 2 testerów i - na ogół - jeden komputer

- jeden "pracuje na komputerze", drugi podpowiada co testować i jak, sporządza notatki, zadaje "głupie" pytania itp.

- co 60-90 min następuje przerwa i zmiana ról.

Takie podejście do testowania ma istotne zalety. Przede wszystkim rośnie efektywność pracy dobrze dobranej pary testerów (przy źle dobranej parze może być gorsza niż gdy pracują pojedynczo - należy więc poświęcić trochę czasu na stworzenie zgranych par). Ponadto większa jest kreatywność przy tworzeniu testów eksploracyjnych, a także rośnie jakość raportowania.

Kolejny postulat w Agile testing to automatyzacja testowania, przy czym należy nie tylko używać robotów testowych, ale także programów do automatycznego generowania danych. Należy też wspomagać proces zarządzania testowania, obiegu dokumentów itp. Dopiero suma tych działań powinna przyspieszyć i zminimalizować koszty.

Wielu praktyków stwierdzi, że zastosowanie powyższych zaleceń nie tylko nie zmniejszy kosztów, ale je zwiększy. Czy tak być musi? Oczywiście, nie. Testy w pośpiechu, bez uprzednio dobrze zorganizowanego zespołu testowego, na pewno będą droższe - zawsze taka jest cena prowizorki. Jeżeli jednak nastawimy się na tego typu podejście, może się okazać, że jesteśmy w stanie zrobić to samo nie tylko szybciej, ale i taniej.

Głównym problemem przy prowadzeniu testów jest powszechna opinia, że "testować może każdy", innymi słowy, że testerzy są tanimi pracownikami. W rzeczywistości przy testach eksploracyjnych muszą pracować doświadczeni (czyli drożsi) testerzy, ale za to ich praca jest zdecydowanie bardziej efektywna niż osób niedoświadczonych.

Często większe efekty osiągnie się przy niedużym, zgranym zespole doświadczonych testerów niż przy dużo większym zespole "z łapanki". Na ogół okazuje się zresztą, że wyniki takiego "drogiego" zespołu z nawiązką zwracają ponoszone koszty.

Kolejnym problemem są automaty testowe. Oprogramowanie to jest stosunkowo drogie i czas jego amortyzacji jest dość długi. Można oczywiście korzystać z rozwiązań shareware - nie są one radykalnie gorsze od proponowanych przez firmy komercyjne. Jeżeli zespół testerów używał już tego typu oprogramowania, większość testów (zwłaszcza testy regresji) można zdecydowanie przyspieszyć. Metoda pracy parami może wtedy wyglądać w ten sposób, że jedna osoba z pary programuje automat testowy, podczas gdy druga projektuje od razu różne wariacje tego testu.

Należy zdawać sobie sprawę, że automaty testowe wymagają odpowiedniej wiedzy. Nie należy się łudzić, że od razu po ich wprowadzeniu zmniejszy się czas testów, a tym samym zmniejszą się koszty. To przychodzi dopiero po jakimś czasie i jest zgodne z poprzednim twierdzeniem, że przy testach o skróconym czasie wykonania należy zatrudnić zgrany zespół doświadczonych testerów.

Należy podkreślić, że "testy na wariata" nie zastąpią - a przynajmniej nie powinno tak być - testów z góry zaplanowanych. Poprawne zachowanie oprogramowania powinno być jednoznacznie szczegółowo zdefiniowane i powinny zostać przygotowane scenariusze testowe. Należy również przestrzegać planu ich wykonania. Unika się wtedy wielu niepotrzebnych i kosztownych poprawek czy modyfikacji. Jednak nie oznacza to, że stoimy na straconej pozycji, gdy nie udaje się dotrzymać wszystkich warunków zapewniających właściwy przebieg procesu testowego.

Jeżeli dysponujemy zgranym zespołem doświadczonych testerów i mamy do dyspozycji dobre narzędzia do automatycznego wspomagania ich pracy, to możemy zapewnić osiągnięcie porównywalnej jakości testowanego oprogramowania.

Lucjan Stapp jest pracownikiem naukowym na Wydziale Matematyki i Nauk Informacyjnych Politechniki Warszawskiej.