Testowanie oprogramowania firmowego: jakie próby wykonać, zanim zacznie się go używać codziennie

Testowanie systemu niemal zawsze zawodzi w ten sam sposób: zwołuje się przyszłych użytkowników, mówi się „przetestujcie go”, a ludzie sprawdzają to, co już i tak potrafią robić. Oprogramowanie przechodzi test. Potem, pierwszego dnia prawdziwej pracy, pojawia się zamówienie do anulowania po wysyłce, a tego nikt nie sprawdził.

Testowanie oznacza wcześniejsze zapisanie tego, co ma się wydarzyć, a potem sprawdzenie, czy tak się dzieje. Cała różnica między tymi dwiema rzeczami tkwi w słowie „wcześniej”.

Scenariusz testowy to nie to samo, co „przetestować program”

Scenariusz składa się z czterech części, a jeśli brakuje jednej z nich, test nie jest ani powtarzalny, ani możliwy do przedyskutowania.

• Dane wyjściowe: który klient, które zamówienie, który magazyn, z jakimi wartościami.
• Rola: kto wykonuje test i z jakimi uprawnieniami.
• Kroki: co się robi, w kolejności, w jakiej się to robi.
• Oczekiwany wynik: co musi być prawdą na koniec, zapisane przed wykonaniem testu.

Oczekiwany wynik to część, którą się pomija, a jest jedyną, która się liczy. Bez niej test kończy się stwierdzeniem „wydaje mi się, że działa”, co nie jest rezultatem, lecz wrażeniem, którego nie można ani zakwestionować, ani potwierdzić.

Plan testów: zlecenie

Przykład poglądowy dotyczący modułu obsługującego zlecenia. Testy zostały dobrane tak, aby objąć trzy zawsze potrzebne typy: przypadek normalny, wyjątek oraz to, co powinno zostać zablokowane.

Ostatnie trzy wiersze to te, o których zawsze się zapomina. System ocenia się także po tym, co odrzuca, a odrzucenie musi być zrozumiałe: operacja zablokowana bez wyjaśnienia powoduje takie same telefony jak błąd.

Testy, o których nikt nie myśli

• Operacje nieautoryzowane, naprawdę sprawdzone na koncie użytkownika o ograniczonych uprawnieniach, a nie tylko odczytane z tabeli uprawnień. Trzeba sprawdzić także wydruki i eksporty, z których dane poufne wyciekają częściej niż z ekranów.
• Dane nieczyste: nazwiska z apostrofami, bardzo długie adresy, kwoty równe zeru, ciężkie załączniki, zduplikowane wiersze.
• Przerwania: połączenie, które zrywa się w połowie zapisu, dwie osoby modyfikujące ten sam rekord, ta sama operacja wysłana dwukrotnie.
• Integracje w sytuacji, gdy drugi system nie odpowiada: co widzi użytkownik, co pozostaje w zawieszeniu, co się dzieje, gdy drugi system znów staje się dostępny.
• Momenty zamknięcia okresu, jeśli oprogramowanie traktuje je w szczególny sposób.

Klasyfikować usterki zamiast je tylko wypisywać

Lista sześćdziesięciu zgłoszeń bez klasyfikacji blokuje projekt: nikt nie wie, od czego zacząć, a każde spotkanie zamienia się w negocjacje. Wystarczą cztery kategorie, uzgodnione przed rozpoczęciem.

• Blokująca: uniemożliwia pracę i nie ma alternatywnego rozwiązania. Musi zostać poprawiona przed uruchomieniem.
• Poważna: praca jest możliwa, ale okrężną drogą lub z ryzykiem błędu. Powinna zostać poprawiona przed uruchomieniem lub zaraz po nim, z ustalonym terminem.
• Drobna: niedogodność, forma, niejasny tekst. Zbiera się je i poprawia grupowo.
• Nowy wniosek: to nie usterka, lecz funkcja, która nie była przewidziana. Należy ją tak rozpoznać i ocenić osobno.

To właśnie rozróżnienie między ostatnią kategorią a pozostałymi ratuje projekt. Pomylenie brakującej funkcji z usterką przenosi koszt na wykonawcę, a termin na wszystkich, i zamienia testowanie w niekończącą się budowę.

Weryfikować poprawki, nie psując reszty

Każdą poprawkę powinna zweryfikować osoba, która zgłosiła usterkę, a nie ta, która ją rozwiązała, powtarzając pierwotny test, a nie podobny do niego. Równolegle należy powtórzyć wąską grupę testów na głównych ścieżkach: poprawki pociągają za sobą skutki uboczne i jest to zjawisko normalne.

Warto ustalić ograniczoną liczbę dostaw w trakcie testowania — na przykład jedną na tydzień — zamiast nieustannie wprowadzać poprawki. Testowanie systemu, który zmienia się pod rękami, sprawia, że każdy wynik staje się niewiarygodny, a każde zgłoszenie dyskusyjne.

Uruchomienie, wsparcie i droga powrotu

1. Należy zdecydować, jak nastąpi start: wszyscy naraz, dział po dziale, czy równolegle z poprzednim systemem przez określony czas. Praca równoległa jest bezpieczna, ale podwaja obciążenie, dlatego trzeba nadać jej spisany termin zakończenia.
2. Trzeba ustalić, kto odpowiada w pierwszych dniach, gdzie zgłaszać pytania i w jakim czasie następuje odpowiedź. Pierwsze dwa tygodnie generują więcej pytań niż cała reszta roku.
3. Trzeba określić drogę powrotu: pod jakimi warunkami następuje wycofanie się, kto o tym decyduje i co się stanie z danymi wprowadzonymi w międzyczasie. Jeśli takiej odpowiedzi nie ma, uruchomienie jest hazardem.

Czego ten przewodnik nie obejmuje

Tutaj mowa jest o odbiorze procesów o przewidywalnym wyniku: dla danego wejścia system musi zrobić jedną, precyzyjnie określoną rzecz, zawsze tę samą. Weryfikacja systemów odpowiadających w sposób probabilistyczny — asystentów i automatycznych respondentów, w przypadku których to samo pytanie może otrzymać różne odpowiedzi, a poprawność jest kwestią stopnia — wymaga innej metody, omówionej gdzie indziej. Również wybór tego, co znajdzie się w pierwszej wersji systemu do zarządzania firmą, ma swój własny przewodnik.