Nierzadko okazuje się, że chociaż mamy przygotowane wcześniej porządne scenariusze testowe, to pod koniec projektu brakuje czasu i zasobów na ich solidne wykonanie. Co robić w takich sytuacjach?

Każdemu kierownikowi projektu, każdemu szefowi zespołu ds. zapewnienia jakości zdarzyło się uczestniczyć w projekcie, w którym zaplanowano wystarczający czas i zasoby, pozwalające w sposób pełny i bezpieczny sprawdzić wszystkie fragmenty nowo tworzonej aplikacji. Gdy jednak przyszło do realizacji, okazało się, że fazy analizy i wykonania przesunęły się w czasie, zasoby ludzkie zostały zredukowane, a jedyne co się nie zmieniło to ostateczny termin zakończenia projektu.

Jeżeli oprogramowanie, o którym mówimy, jest krytyczne pod względem bezpieczeństwa (safety critical software), to pozostaje tylko jedna droga: należy bezzwłocznie zawiadomić kierownictwo o zaistniałej sytuacji i zdecydowanie odmówić skrócenia czasu testów.

Jednak z programami krytycznymi pod względem bezpieczeństwa nie mamy do czynienia na co dzień - większość aplikacji nie jest pod tym względem aż tak restrykcyjna. Dlatego też bardzo często musimy wykonać pracę, mimo braku wystarczających zasobów (głównie czasu). Jak sobie radzić? Zawsze należy informować kierownictwo o zaistniałej sytuacji. Być może kierownictwu uda się przesunąć termin ostatecznego odbioru, może zgodzi się na przydzielenie dodatkowych testerów? Czasami i takie cuda się zdarzają.

Jeżeli mamy przygotowane scenariusze testowe, zapewniające dostateczne pokrycie testowanej aplikacji, to i tak nie jest jeszcze zupełnie źle. Zdarza się, że z braku środków nie mamy nawet i tego. Rozwiązaniem jest wtedy to, co po polsku można nazywać "testami na wariata".

Wybrać niezbędne

W literaturze dotyczącej tego problemu nazwa ta zmieniała się kilkakrotnie w ciągu ostatnich kilku lat. Najpierw nazywano je testami opartymi na ryzyku (risk-based testing - nazwa używana zresztą przez niektórych do dziś), następnie zaproponowano nazwę testy eksploracyjne (exploratory testing, ewentualnie testy ad hoc), obecnie najczęściej spotykaną nazwą jest testowanie metodą Agile (Agile testing). Są to kolejne etapy i rozwinięcia podobnych pomysłów, także autorzy są ci sami (m.in. James Bach, Brian Marick, Bret Pettichord).

Zacznijmy od najstarszego pomysłu, jakim jest testowanie oparte na ryzyku. Podstawą tego rodzaju testów jest określenie niezbędnego poziomu jakości akceptowanego przez odbiorcę. Najważniejsze w tej metodzie to wskazanie błędów, które musimy usunąć przed wydaniem produktu - tych najistotniejszych dla działania aplikacji. Typowe metody, takie jak testowanie według klasy równoważności, analiza wartości brzegowych czy też tworzenie grafów przyczynowo-skutkowych, umożliwiają wygenerowanie wielu przypadków testowych, lecz wówczas nie wiadomo, które z nich są rzeczywiście ważne. Musimy najpierw określić, jakie obszary systemu należy testować w pierwszej kolejności. Zwykle w następującym porządku:

1. Najistotniejsze biznesowo obszary aplikacji - tutaj nie powinno być żadnych wątpliwości.

2. Obszary krytyczne (ze względu na konsekwencje i koszty); tutaj trzeba zwrócić szczególną uwagę na awarie:

   - powodujące zniszczenia

   - zatrzymujące pracę

   - utrudniające pracę.

3. Najczęściej używane obszary aplikacji; ponieważ - zgodnie z badaniami statystycznymi - ok. 60% typowej aplikacji w praktyce pozostaje niewykorzystywane (lub jest używane bardzo rzadko), należy się skupić na tych podstawowych 40%.

4. Obszary, gdzie użytkownik spodziewa się wystąpienia błędów; ten obszar jest stosunkowo trudny do wyodrębnienia, uzależniony od znajomości klienta i jego przyzwyczajeń oraz dotychczasowych jego kłopotów z podobnymi programami.

Co więcej, są błędy, które użytkownik łatwiej zaakceptuje, czyli błędy, które nie wpływają na poziom akceptacji oddawanej aplikacji. Przykłady takich błędów każdy z nas zna, zależą one na ogół od przyzwyczajeń użytkownika. Części z nich można zapobiegać, opisując je w instrukcji obsługi, część da się być może ominąć dzięki obraniu innej ścieżki wykonania. Są to jednak błędy nienależące do żadnego z wymienionych wyżej obszarów działania testowanego produktu.

Dobrym przykładem jest tu błąd obecny w prostej grze Pasjans - Pająk, która jest dołączona do systemu Windows XP. W grze może dojść do sytuacji, w której nie można rozłożyć kart ze stosu w prawym dolnym rogu, gdyż zgodnie z regułami gry, by móc rozłożyć karty ze stosu, trzeba mieć coś na każdym stosie kart rozłożonym na stole. W przypadku zwinięcia 5 kolorów na stole pozostaje 6 kart, 20 jest do rozwinięcia (daje to razem 2 pełne talie).

Ponieważ błąd ten występuje rzadko (na wyższych poziomach gry prawdopodobieństwo jego wystąpienia jest poniżej 10-6), nie jest szkodliwy, nie zmienia poziomu satysfakcji gracza (gdy są odkryte wszystkie karty ze stosów leżących na stole, gracz musi wygrać), możemy go uznać za dopuszczalny.

Umiejętność testera

Z innym problemem mają często do czynienia szefowie działów IT. Zdarza się, że nadchodzi termin testów akceptacyjnych, a pracownicy merytoryczni ("biznes") zamawiający aplikację nie mają czasu na ich przygotowanie, zrzucając cały problem na nie zawsze dostatecznie merytorycznie przygotowanych pracowników działów IT. Oczywiście, istnieje specyfikacja wymagań, lepiej lub gorzej przygotowany projekt aplikacji, ale...

Dobrym rozwiązaniem jest tu zastosowanie testów eksploracyjnych. To rozwinięcie pomysłów z testowania opartego na ryzyku. Idea testów eksploracyjnych sprowadza się do równoczesnego uczenia się aplikacji, projektowania testów i ich wykonywania. Innymi słowy tester tworzy test, wykonuje go i uzyskane informacje wykorzystuje do tworzenia nowych i lepszych testów.

Takie działanie wymaga nieco innego podejścia testera do pracy. Dla testera pracującego według scenariuszy i skryptów wystarczy, by obserwował, co się dzieje, gdy wykonywany jest skrypt testowy. Natomiast przy testach eksploracyjnych tester zwraca uwagę na wszystko co widzi, na to co nietypowe, dziwne i niezgodne z "duchem" aplikacji.

Ponieważ cały czas projektuje się testy, potrzebna jest biegłość w "stwarzaniu problemów". Tester musi myśleć krytycznie, cały czas szukać dziur we własnym myśleniu i nawykach. Klasycznym przykładem jest ładowanie pliku w edytorze tekstów (Plik -> Otwórz). Otworzyła nam się pierwsza strona. Czy możemy już powiedzieć, że operacja wykonała się poprawnie? Większość odpowie, że tak, dla testera eksploracyjnego odpowiedzią jest "być może" - należy bowiem sprawdzić resztę dokumentu (wiemy bowiem tylko, że poprawnie ładuje się pierwszy ekran dokumentu, nie można natomiast nic powiedzieć o jego reszcie).