Testowanie ekstremalne

Testowanie ekstremalne (ang. extreme testing, XT) – metodologia testów dla aplikacji przygotowywanych według metodologii programowania ekstremalnego (ang. extreme programming, XP). Testowanie ekstremalne jest jedną z podstawowych zasad programowania ekstremalnego, które w praktyce przejawia się w postaci ciągłego testowania tworzonego kodu. Realizowane jest w dwóch formach: testowania jednostek oraz testowania akceptacyjnego.

Kod realizujący testowanie modułów tworzony jest przed kodem źródłowym. Żaden z tworzonych modułów nie może być uznany za kompletny, dopóki nie przejdzie przez fazę testowania jednostek. Sam program nie jest kompletny dopóki wszystkie jego moduły nie przejdą fazy testowania jednostek i testowania akceptacyjnego. Testowanie jednostek dokonywane jest po każdej, nawet najmniejszej modyfikacji w kodzie źródłowym. Testowanie akceptacyjne dokonywane jest przez użytkownika, który tym samym weryfikuje zgodność tworzonego kodu ze swoimi oczekiwaniami po każdorazowej znaczącej zmianie dokonywanej w danym kodzie. Istotą testowania ekstremalnego jest konieczność stworzenia – na podstawie specyfikacji – środowiska testowego dla aplikacji, jeszcze przed rozpoczęciem tworzenia jej kodu zasadniczego. Dzięki temu kodowanie aplikacji podporządkowane jest pewnym wymogom określonym podczas tworzenia środowiska testowego (wynikającym ze specyfikacji) co zmniejsza prawdopodobieństwo rozminięcia się tworzonej aplikacji ze specyfikacją.

Ekstremalne testowanie jednostek

Testowanie jednostek, jako główna koncepcja testowania ekstremalnego rządzi się dwiema regułami – dla tworzonego modułu konieczne jest stworzenie środowiska testowego jeszcze przed rozpoczęciem tworzenia kodu tego modułu, po drugie, zanim stworzony moduł dodany zostanie do kodu bazowego, musi zaliczyć wszystkie przewidziane dla niego testy. Danie pierwszeństwa testowaniu nad kodowaniem jest samo z siebie pomysłem nowatorskim.

Istotne zalety wynikające z prymatu testowania:

• zyskanie i utrzymanie zaufania do tworzonego kodu pod względem jego zgodności ze specyfikacją
• wyartykułowanie rezultatu wykonania kodu jeszcze przed rozpoczęciem jego tworzenia
• lepsze zrozumienie specyfikacji i potrzeb użytkownika
• stopniowe doskonalenie i usprawnianie kodu, począwszy od prostego projektu poprzez kolejne etapy refaktoryzacji bez obawy o utratę zgodności aplikacji z jej specyfikacją

Testowanie akceptacyjne

Celem testowania akceptacyjnego jest ostateczne zapewnienie, że aplikacja całkowicie spełnia wymóg zgodności ze specyfikacją, także w aspekcie użyteczności, łatwości obsługi i funkcjonalności. Niektóre z istotnych dla użytkownika cech aplikacji, jak kolorystyka ekranu, układ pól wejściowych, czytelność wpisywanej informacji, zwięzłość komunikatów itp., z oczywistych względów nie są zwykle przedmiotem testowania jednostek. W przeciwieństwie do testowania jednostek testowanie akceptacyjne przeprowadzane jest przez użytkownika, bez udziału zespołu programistów. Podstawą testów akceptacyjnych są historie użytkownika – każda z historii, zależnie od stopnia komplikacji, może stanowić źródło dla jednego lub kilku testów akceptacyjnych. Gdy użytkownik stwierdzi, że jego oczekiwania pod adresem aplikacji nie zostały całkowicie spełnione, sporządza związany z tym raport o błędach (bo z perspektywy XT każde odstępstwo do wymagań użytkownika traktowane jest jako błąd) i przekazuje go programistom. W przypadku większej liczby błędów musi on ponadto określić, które z nich są dla niego najbardziej dotkliwe i muszą być poprawione w pierwszej kolejności. Programiści po poprawieniu wszystkich błędów (lub ich podzbioru wskazanego przez użytkownika) ponownie przekazują aplikacje użytkownikowi, który wykonuje kolejne testy akceptacyjne. W ten oto sposób testowanie akceptacyjne przybiera formę testowania regresywnego.

Podstawowe zasady testowania ekstremalnego

1. najpierw należy stworzyć (zaprojektować) testy

• należy zacząć jak najwcześniej (najpóźniej równolegle z deweloperami), lepiej, gdy można to zrobić podczas odbioru prac analitycznych
• dążymy do maksymalnego zrozumienia testów – nie należy zakładać wzajemnego zrozumienia się, w przypadku jakichkolwiek niejasności należy uszczegółowić problem

2. testy mają równy priorytet z tworzeniem kodu

• w większości przypadków testy są „spychane” na sam koniec procesu produkcji oprogramowania, wielu project menadżerów zgadza się na skrócenie czasu poświęconego na testy. W XT ta zasada ma nie mieć zastosowania, bez pozytywnego przejścia wskazanych testów nie ma odbioru aplikacji (jej kolejnej iteracji)

3. dążenie do 100% pokrycia przypadkami testowymi (TC) wszystkich warstw systemu

4. jasno określony cel testowania

• pożądana jakość produktu – ponieważ nie można przetestować wszystkich możliwych przebiegów aplikacji, należy z góry określić te przebiegi które muszą bezwzględnie zachowywać się poprawnie; co więcej dopuszczamy nieprawidłowe zachowanie się aplikacji w pewnych sytuacjach.
• satysfakcja odbiorcy
• minimalizacja zmian – w przeciwieństwie do XP nie należy codziennie testować przygotowywanej aplikacji, tu należy dążyć do otrzymywania z produkcji wersji pełnej (oczywiście ze względu na wskazaną funkcjonalność).
• akceptacja na podstawie z góry ustalonych funkcjonalnych testów akceptacyjnych – w przypadku stwierdzenia innych błędów iteracja jest akceptowana, poprawianie to kolejna iteracja

5. testowanie parami

• „co dwie pary oczu to nie jedna”
• zwiększenie bezpieczeństwa testów
• mamy tu możliwość tworzenia różnych par testerów np. doświadczony – niedoświadczony, znający problem biznesowy – nowicjusz itp.
• należy zapewnić rotację testerów w parach, będzie to skutkowało zmniejszeniem zarządzania ryzykiem – odejście „dobrego” testera nie skutkuje „dużymi” stratami w projekcie

6. dążenie do maksymalnego uproszczenia dokumentacji testowej Podstawowymi metodami komunikacji i to zarówno w zespole testowym, jak i między zespołem testowym a programistami ma być komunikacja werbalna i poglądowa. By to osiągnąć, należy wzmocnić współpracę testerów i deweloperów. Osiągnąć to można poprzez:

• integracja zespołu poprzez częste spotkania (np. 2 razy w tygodniu lub krótka 5–10 minut odprawa raz dziennie)
• wzajemne przeglądy testów (testerzy sprawdzają testy deweloperów, deweloperzy uczestniczą w przygotowywaniu testów akceptacyjnych)

7. automatyzacja testów

• należy dążyć do maksymalnej automatyzacji testów. Ułatwia to i zdecydowanie przyspiesza testy regresji, które należy wykonać przy odbiorze kolejnej iteracji powstającej aplikacji. Należy jednak pamiętać o tym, by myśleć już o tworzeniu skryptów testowych już na etapie projektowania testów, jak najwcześniej należy też przystąpić do tworzenia tych skryptów. Ponieważ testy rozpoczynają się równocześnie z tworzeniem, więc początkowy okres – nim zostaną wyprodukowane pierwsze fragmenty nadające się do testowania – poświęcić na projektowanie i tworzenie skryptów testowych.

8. codzienne raportowanie stanu testów

• Zalecane jest stworzenie – codziennie odświeżanej i dostępnej dla wszystkich – prezentacji bieżącego stanu testów, najlepiej w postaci graficznej.

Prócz powyższych zasad obowiązują standardowe zasady tworzenia testów wydajnościowych. Należy tworzyć i uruchamiać je w najwcześniejszych możliwych fazach testowania. Należy także pamiętać o ciągłym refaktoringu skryptów testowych i dodawaniu nowych przypadków testowych (TC) – zwłaszcza związanych z sytuacjami, gdy wykryto błąd spoza zakresu testów akceptacyjnych aktualnej iteracji.

Bibliografia

• Glenford J. Myers, Corey Sandler, Tom Badgett, Todd M. Thomas: „Sztuka testowania oprogramowania”, 2005/06