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

Po co się tego uczymy?

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.

Teoria

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.

Schemat

ŚRODOWISKA (przepływ zmiany):

  DEV (komputer programisty)
        │  commit + testy jednostkowe przechodzą
        ▼
  TEST/STAGING (dane testowe, testerzy sprawdzają scenariusze)
        │  wszystkie scenariusze OK, błędy zamknięte
        ▼
  PRODUKCJA (prawdziwi użytkownicy)


ZGŁOSZENIE BŁĘDU - wymagane elementy:
┌──────────────────────────────────────┐
│ Tytuł: krótki opis                    │
│ Kroki do odtworzenia: 1) 2) 3)...      │
│ Oczekiwany rezultat                   │
│ Faktyczny (błędny) rezultat           │
│ Środowisko: przeglądarka/system/wersja│
│ Istotność: krytyczny/poważny/kosmetyczny│
│ Priorytet: wysoki/średni/niski        │
└──────────────────────────────────────┘

Przykład z życia

Zanim nowy model samolotu trafi do prawdziwych pasażerów, przechodzi setki lotów testowych z załogą testową i danymi z czujników — nikt nie testuje nowego silnika na pierwszym komercyjnym locie z pasażerami na pokładzie. Dokładnie tak samo działają środowiska w informatyce: zmiany "lądują" najpierw na środowisku testowym, i dopiero po potwierdzeniu, że wszystko działa, trafiają "do pasażerów" — czyli na produkcję.

Ćwiczenie samodzielne

Napisz pełny scenariusz testowy (krok po kroku + oczekiwany rezultat) dla funkcji "dodawanie ogłoszenia" z projektu Serwis ogłoszeniowy (dział Aplikacje webowe, lekcja 25) — uwzględnij zarówno przypadek poprawny, jak i próbę dodania ogłoszenia bez wypełnienia wymaganych pól.

Zadania do pracy własnej

Napisz przykładowe zgłoszenie błędu (w formacie z tej lekcji: tytuł, kroki do odtworzenia, oczekiwany/faktyczny rezultat, środowisko, istotność, priorytet) dla wymyślonego błędu: "przycisk Zaloguj nie reaguje na kliknięcie w przeglądarce Firefox".
Zaproponuj po jednym przykładzie błędu o: (a) wysokiej istotności i wysokim priorytecie, (b) niskiej istotności, ale wysokim priorytecie, (c) wysokiej istotności, ale niskim priorytecie. Uzasadnij każdy przykład.
Zaprojektuj listę 8 scenariuszy testowych (krok po kroku + oczekiwany rezultat) pokrywających GŁÓWNE funkcjonalności projektu "System głosowania i ankiet" (dział Aplikacje webowe, lekcja 26) — uwzględnij zarówno przypadki poprawne, jak i próby oszukania systemu (np. podwójne głosowanie).

Typowe błędy

Testowanie nowych, niesprawdzonych funkcji bezpośrednio na środowisku produkcyjnym — nawet "drobna" zmiana może nieodwracalnie wpłynąć na prawdziwe dane użytkowników; ZAWSZE najpierw środowisko testowe.

Zgłaszanie błędu bez kroków do odtworzenia (np. samo "coś nie działa na stronie logowania") — programista nie jest w stanie zobaczyć problemu u siebie i naprawić go bez dokładnego opisu, co dokładnie zrobił zgłaszający i co poszło nie tak.

Mylenie istotności z priorytetem — traktowanie ich jako tego samego prowadzi do złych decyzji: poważny technicznie błąd, którego prawie nikt nie napotyka, może czekać dłużej niż drobny błąd wizualny widoczny dla każdego klienta na stronie głównej.

Nawiązanie do egzaminu zawodowego

To pokrycie organizacyjnej strony INF.04.8.3 (metodyki testowania, scenariusze, raportowanie błędów, BugZilla/JIRA) — uzupełnia wcześniejsze lekcje techniczne (testy jednostkowe, niefunkcjonalne) o kontekst PROCESU pracy zespołowej. W kolejnej lekcji zajmiemy się drugim filarem INF.04.8 — dokumentowaniem aplikacji.