SygnITy Expert
Od incydentu do poprawki: praca testera po wykryciu błędu na produkcji
Praca testera zaczyna się już na samym początku tworzenia oprogramowania – od analizy biznesowej, przez projektowanie architektury, gdzie tester uczestniczy w przeglądach i wspiera zespół w wychwytywaniu niejasności i ryzyk, aż po końcowe etapy, takie jak testy akceptacyjne, end-to-end czy beta testy.
Ale czy to oznacza koniec naszej pracy? Oczywiście, że nie!
To właśnie po wdrożeniu zaczyna się prawdziwe życie oprogramowania – na środowisku produkcyjnym. Tam system po raz pierwszy mierzy się z realnymi użytkownikami, zmiennymi warunkami i nieprzewidywalnymi scenariuszami. Wtedy też mogą pojawić się błędy lub awarie, które z różnych powodów nie zostały wcześniej zauważone czy uwzględnione.
W tym artykule chcę przedstawić cykl życia błędów wykrywanych na produkcji – z perspektywy testera, który obserwuje cały proces od momentu zgłoszenia aż po wdrożenie poprawki.
Etap 1: Zgłoszenie błędu
To właśnie tutaj zaczyna się cykl życia błędu. Użytkownik oprogramowania zgłasza problem poprzez odpowiedni ticket w systemie.
Zgodnie z przyjętymi wytycznymi ustawia właściwy status błędu, określa priorytet (który wpływa na czas reakcji – SLA) oraz opisuje, czego dotyczy zgłoszenie. Jeśli sytuacja wystąpiła podczas pracy na konkretnym przypadku, warto dodać jego identyfikator w tickecie.
Gdy błąd dotyczy specyficznego scenariusza użycia systemu, dobrze, by taki opis również się tam znalazł. Dodatkowo użytkownik może dołączyć zrzuty ekranu, logi lub inne dane, które pomogą w późniejszym debugowaniu.
Na tym etapie zgłoszenie trafia do analityka, który przekierowuje je do odpowiedniego zespołu. Najczęściej w proces zaangażowani są: analityk, deweloper oraz tester, którzy wspólnie monitorują postęp prac nad błędem.
Etap 2: Analiza przyczyny
Gdy zgłoszenie zostaje przydzielone do odpowiedniego zespołu, rozpoczyna się próba odtworzenia błędu na środowisku testowym.
Na tym etapie realizowana jest analiza przyczyny błędu. Prowadzony jest debug programistyczny, a także wyszukiwane lub tworzone dodatkowe przypadki testowe, które pokrywają się z sytuacją zgłoszoną w tickecie.
Celem jest sprawdzenie, czy problem klienta jest odosobniony, czy dotyczy konkretnej specyfikacji systemu.
Etap 3: Wdrożenie poprawki i retest
Po wykonaniu analizy przyczyny programista wprowadza poprawkę i wstępnie testuje zgłoszony przypadek.
Po pozytywnym code review poprawka zostaje wdrożona na środowisko testowe. Deweloper opisuje, na czym polegała zmiana, oraz wskazuje obszary, które mogły zostać dodatkowo nią objęte. Te informacje pomagają testerowi w przygotowaniu scenariuszy i przypadków testowych.
Po przypisaniu zgłoszenia do testera rozpoczynają się pełne prace testowe:
- Tester przygotowuje scenariusze i przypadki testowe pokrywające obszary wskazane przez dewelopera.
- W pierwszej kolejności wykonywane są testy sprawdzające wywołanie pierwotnego błędu, którego dotyczyło zgłoszenie.
- Następnie przeprowadzane są testy regresji, które weryfikują, czy poprawka nie wpłynęła na inne obszary systemu.
- Ostatnim etapem jest przygotowanie raportu z testów, zawierającego zrzuty ekranu, nagrania, wyniki, spostrzeżenia i komentarze.
Po pozytywnie zakończonych testach zgłoszenie wraca do analityka, który kontaktuje się z klientem i informuje o rozwiązaniu problemu. W przypadku negatywnych wyników testów ticket wraca do programisty, który sprawdza przyczynę dalszego występowania błędu i, jeśli potrzeba, tworzy nową poprawkę.
Przed wgraniem na produkcję poprawka przechodzi jeszcze ostatnie testy na środowisku preprodukcyjnym, aby upewnić się, że w wersji produkcyjnej problem został skutecznie rozwiązany.
Etap 4: Wnioski i usprawnienia procesu
Po zamknięciu zgłoszenia warto przeanalizować jego unikatowość i sprawdzić, czy podobne błędy pojawiały się wcześniej w tym samym obszarze lub w obszarach, które mogły zostać dotknięte poprawką. Dzięki temu w przyszłości problem można szybciej i skuteczniej naprawić.
Warto również wzbogacić firmową bazę wiedzy o nowe zagadnienia, wnioski lub rozwiązania, które pojawiły się w trakcie realizacji ticketu i mogą wpływać na dotychczasowe procesy.
Na uwagę zasługuje również proces komunikacji w zespole – warto zastanowić się, co można poprawić, a co utrwalić w przyszłych zadaniach.
Rolą testera jest uporządkowanie wiedzy zdobytej podczas realizacji zgłoszenia, takiej jak sposób tworzenia i wyszukiwania przypadków testowych, plan działania podczas testów oraz wiedza biznesowa zdobyta w trakcie pracy nad ticketem.
Podsumowanie
Jako tester należy mieć świadomość, że podczas produkcji oprogramowania nie jesteśmy w stanie przetestować wszystkich możliwych zachowań systemu, z jakimi będzie się mierzył po oddaniu klientowi. Dlatego ważne jest, aby pamiętać, że nasza rola nie kończy się na tworzeniu produktu – przekształca się w utrzymanie i dalszą dbałość o jakość po etapie wdrożenia.
Dzięki temu procesowi zespół szybciej reaguje na problemy, minimalizuje ryzyko powtarzających się błędów i zwiększa zadowolenie klienta.