Sprawna organizacja procesu testowania jest tak samo ważna jak jakość wykonywanych testów.

Tak jak Wenus podobno wyłoniła się z morskiej piany, tak z chaotycznej bieganiny, nerwowych zebrań, nadgodzin programistów, rozpaczliwej krzątaniny testerów, zszarganych nerwów kierownika projektu oraz gróźb zniecierpliwionego klienta ma się wyłonić Ona. Bezbłędna. Idealna. Aplikacja-marzenie. Zanim znajdzie się na wybiegu, owa piękność wymaga jednak oględzin. To test powinien ostrzec: "Panowie, mieliśmy budować Wenus, a na razie widzimy tutaj pięciogłowego wielbłąda!". Test przypomni, że bogini piękności powinna mieć dwie, nie zaś trzy nogi. Policzy palce u rąk i zawoła, że cztery palce uchodzą w komiksach, ale nie w rzeczywistości.

O ile nietrudno odróżnić Wenus od pięciogłowego wielbłąda, o tyle błędy oprogramowania nie zawsze są oczywiste i rzucające się w oczy. Zdemaskowanie błędów wymaga wysiłku wielu osób, którymi - by nie poszły na marne - ktoś musi zarządzać i kierować.

Porządek musi być

Zgłoszenie błędu to dokładny opis objawów i okoliczności awarii, sporządzony przez testera sporym nakładem pracy po to, by ułatwić programiście znalezienie i zlikwidowanie przyczyny awarii. Rozmowa testera z programistą zwykle przebiega następująco. Programista, niezmiennie, bardzo się dziwi, a następnie mówi: "Przecież ten błąd został usunięty już dwa tygodnie wcześniej" albo "Pewnie użyłeś złej wersji". Tester się upiera: "Ależ skąd, główne okno dialogowe wyświetliło numer najnowszej wersji, numer Z15". "Tak, ale to wersja programu głównego. Ten moduł mógł mieć inną wersję!" - triumfuje programista. Sprawdzają obaj. Okazuje się, że adres 0xA1F0 zawiera wartość 0xE, a więc wersja numer czternaście feralnego modułu. Tester poci się i łączy program ponownie, tym razem z najnowszą wersją modułu. Awaria nie pojawia się, a więc wszystko jest dobrze. Niestety, po dwóch tygodniach ten sam błąd powraca. Po całodniowym dochodzeniu udaje się ustalić, że nowo zatrudniony programista przez pomyłkę, łącząc program, znowu posłużył się starą wersją feralnego modułu...

Opisana sytuacja to klasyczne symptomy niedostatków w zarządzaniu konfiguracją. Jakie to ma znaczenie? O ile zarządzanie konfiguracją nie ma aż tak dużego znaczenia przy budowie nawet całkiem sporego systemu, o tyle testowanie bez zarządzania konfiguracją jest praktycznie pozbawione sensu. Znalezienie przyczyny awarii w chaosie splątanych wersji poszczególnych modułów systemu wymaga pracy niemal detektywistycznej. Traci się cenny czas, a wysiłek wielu ludzi idzie na marne. W efekcie testowanie tylko w ograniczonym zakresie dostarcza tego, czego się po nim spodziewamy: informacji pozwalających na znajdowanie i usuwanie błędów.

Z tego powodu to zespół testujący, a nie główny projektant, jest gorącym zwolennikiem wprowadzenia ładu w zarządzaniu konfiguracją. Organizowanie prac nad projektem przez zespół testujący nie jest dobrym rozwiązaniem, ale w praktyce o wiele lepszym niż dobrowolne oddanie się w ręce chaosu, marnotrawstwa i bałaganu. Czy tego chce, czy nie, niejednemu zespołowi testującemu przyjdzie się jeszcze zmierzyć z tym wyzwaniem. Trzeba więc zawczasu być na to gotowym i opanować przynajmniej podstawy zarządzania projektami.

Po służbowej ścieżce

Kiedy tester natknie się na awarię, będącą symptomem tkwiącego w programie błędu, fakt ten niesie dwa rodzaje informacji. Po pierwsze, liczba znajdujących się w programie błędów jest podstawową miarą jego jakości. Liczba błędów i tempo odkrywania nowych - rosnące lub malejące - to kluczowe czynniki przy podejmowaniu decyzji o wdrożeniu, wprowadzeniu do produkcji czy dostarczeniu nowej wersji. Po drugie, zaobserwowana awaria pozwala zwykle na zidentyfikowanie będącego jej przyczyną błędu, usunięcie go i w ten sposób podniesienie jakości programu.

Aby była użyteczna, wiedza o błędach nie może pozostać w głowie testera. Trzeba ją przekazać programiście, aby ten rozpoczął poszukiwania przyczyny awarii, a także kierownikowi projektu, by mógł sporządzić statystyki błędów i oszacować bieżącą jakość konstruowanego systemu. Nawet jeżeli projekt jest prowadzony jednoosobowo, sporządzanie notatek na temat znajdowanych i usuwanych błędów pozwala na uniknięcie ich powtarzania.

Aby informacja o błędach była jednoznaczna i pełna, testerzy posługują się tzw. raportami albo zgłoszeniami błędów. Niektóre źródła traktujące o testowaniu wiele miejsca poświęcają udzielaniu rad, jak powinien postępować tester, aby dopilnować, że znaleziony błąd rzeczywiście zostanie potraktowany poważnie i naprawiony. Takie podejście wydaje się jednak przeczyć zdrowemu rozsądkowi i logice prowadzenia projektów. Rolą testera nie jest nadzorowanie programistów, lecz wyszukiwanie błędów. Postawienie testera w roli ekonoma nieuchronnie doprowadzi do konfliktów w zespole. Przy tej okazji warto zauważyć, że tester nie musi mieć - i zwykle nie ma - pełnej wiedzy, potrzebnej do prawidłowej oceny wagi znalezionego błędu. Wiedzę na temat architektury systemu i priorytetów klienta mają zwykle projektanci i kierownicy projektów.

Znalezienie błędu nie jest jeszcze sygnałem do natychmiastowego rzucenia wszystkich dostępnych środków w celu usunięcia. Zanim zostaną podjęte konkretne kroki, trzeba ocenić ryzyko wynikające z jego pozostawienia, a także ryzyko związane z jego usunięciem. Ryzyko to nie tylko ewentualne konsekwencje techniczne - to również czas i koszty. Do tak rozumianego oszacowania ryzyka nie wystarczy zwykle jedna osoba: konieczna jest współpraca wielu uczestników projektu, a podstawą do ich rozważań są właśnie raporty błędów. Prawidłowe zorganizowanie procedur zgłaszania i śledzenia błędów jest jednym z podstawowych zadań kierownika testów.