Środowiska testowe, scenariusze testowania i raportowanie błędów

Napisanie testów to jedno, ale zorganizowanie CAŁEGO procesu testowania w prawdziwym projekcie to osobna umiejętność: gdzie testujemy (nie na koncie produkcyjnym!), jak systematycznie sprawdzamy funkcjonalności (żeby niczego nie pominąć) i jak zgłaszamy znalezione błędy, żeby programista mógł je szybko zrozumieć i naprawić. To wymaganie INF.04.8.3 i codzienna praktyka każdego zespołu programistycznego.

Trzy typowe środowiska w cyklu życia aplikacji:

• Środowisko deweloperskie (development/dev) — komputer programisty, gdzie pisze i na bieżąco sprawdza kod. Najbardziej "niestabilne", zmienia się z każdą linijką kodu.
• Środowisko testowe (test/staging) — osobna kopia aplikacji, jak najbardziej zbliżona do produkcyjnej, ale z DANYMI TESTOWYMI (nie prawdziwych klientów) — tu testerzy sprawdzają nowe funkcje PRZED wypuszczeniem ich do prawdziwych użytkowników.
• Środowisko produkcyjne (production/prod) — WERSJA, z której korzystają prawdziwi użytkownicy. Nigdy nie testuje się nowych, niesprawdzonych funkcji bezpośrednio tutaj — błąd na produkcji od razu wpływa na prawdziwych klientów.

Dlaczego rozdzielenie środowisk jest kluczowe — testowanie nowej funkcji na środowisku produkcyjnym to jak testowanie nowych hamulców w aucie, wioząc jednocześnie pasażerów: nawet drobny błąd (np. w skrypcie migracji bazy danych) może nieodwracalnie skasować lub uszkodzić PRAWDZIWE dane klientów.

Scenariusz testowania — spisany, KROK PO KROKU opis czynności testera oraz oczekiwanego rezultatu, np.: "1) Otwórz stronę logowania. 2) Wpisz poprawny login i hasło. 3) Kliknij Zaloguj. OCZEKIWANY WYNIK: użytkownik trafia na stronę główną, widoczne jego imię w prawym górnym rogu." Dobre scenariusze pokrywają zarówno "szczęśliwą ścieżkę" (wszystko poprawne), jak i przypadki błędne (złe hasło, puste pole, zbyt długi tekst).

Cykl życia zgłoszenia błędu w narzędziach typu JIRA/BugZilla (rozwinięcie z lekcji 1): zgłoszenie błędu (ang. bug report) powinno zawierać: tytuł (krótki opis problemu), KROKI DO ODTWORZENIA błędu (żeby programista mógł go zobaczyć u siebie), oczekiwany rezultat, faktyczny (błędny) rezultat, środowisko (przeglądarka, system, wersja aplikacji), priorytet/istotność (np. krytyczny — aplikacja się wywala, kontra kosmetyczny — literówka w tekście).

Priorytet a istotność błędu — to dwie RÓŻNE skale: ISTOTNOŚĆ (severity) mówi, jak POWAŻNY jest błąd technicznie (np. "krytyczny" — utrata danych), a PRIORYTET mówi, JAK SZYBKO trzeba go naprawić z punktu widzenia biznesu (np. drobny błąd wizualny na stronie głównej może mieć wysoki priorytet, bo widzi go każdy klient). Oba wymiary razem decydują, w jakiej kolejności programiści zajmują się zgłoszeniami.

Narzędzia BugZilla i JIRA — systemy do śledzenia zgłoszeń (ang. issue/bug tracking), w których każdy błąd ma swój numer, historię zmian statusu, przypisaną osobę odpowiedzialną i komentarze — dzięki temu cały zespół widzi AKTUALNY stan każdego zgłoszenia, zamiast zgadywać na podstawie luźnej korespondencji mailowej.