Każdy poziom testowania pełni określoną rolę w tworzeniu oprogramowania i odpowiada na inne pytanie:
Testy jednostkowe - „Czy zmieniła się funkcja, która miała pozostać bez zmian?" Testują najmniejsze, izolowane fragmenty kodu (pojedyncze funkcje lub metody) niezależnie od reszty systemu. (Szczegółowa analiza testów jednostkowych znajduje się w osobnym wpisie na blogu.)
Testy integracyjne - „Czy komponenty nadal poprawnie ze sobą współpracują po zmianie?" Testują rzeczywiste połączenia między modułami (np. baza danych + warstwa serwisowa + API), a nie tylko izolowane funkcje. Wykrywają scenariusze, w których poszczególne części działają osobno, ale zawodzą po połączeniu.
Testy E2E (End-to-End) - „Czy system działa tak, jak doświadczyłby go prawdziwy użytkownik?" Symulują kompletne przepływy użytkownika (logowanie → akcja → wynik) przez prawdziwy interfejs lub API. Wychwytują regresje, których nie wykryją ani testy jednostkowe, ani integracyjne, ponieważ takie problemy ujawniają się dopiero w prawdziwym przepływie.
(Istnieją oczywiście inne rodzaje testowania - takie jak *Smoke tests**, testy obciążeniowe czy testy bezpieczeństwa - które wykraczają poza zakres tego artykułu.)*
Wszystkie poziomy testów automatycznych mają wspólny cel: zweryfikować, czy funkcjonalność nie zepsuła się poza zakresem zadania, nad którym aktualnie pracujemy. Zadanie może zostać wykonane perfekcyjnie zgodnie ze specyfikacją, a mimo to zepsuć coś innego jako niezamierzony efekt uboczny. Bez warstwy testów wykraczającej poza konkretną zmianę nikt by tego nie zauważył, dopóki użytkownik nie zgłosi problemu na produkcji.
Niezastąpiona rola testów manualnych
Mimo zaawansowanej automatyzacji i integracji z AI testowanie manualne zachowuje swoją niezastąpioną, podstawową rolę. Ludzki tester wnosi prawdziwą ocenę, intuicję i zdolność wykrywania subtelnych niuansów lub nieoczekiwanych zachowań interfejsu, które automatyczne skrypty łatwo pomijają. Weryfikacja manualna była, jest i zawsze będzie tym, co daje zespołowi deweloperskiemu 100% pewności, że aplikacja jest gotowa dla prawdziwych użytkowników.
Rozwój wspomagany AI i kompensowanie „ślepoty"
W erze rozwoju wspomaganego AI warstwa testów automatycznych jest jeszcze ważniejsza. Agent AI nie widzi całego systemu naraz, przez co efekty uboczne są bardziej prawdopodobne niż u ludzkiego programisty, który nosi w głowie pełny kontekst i historię dawnych decyzji. Testy służą jako mechanizm systematycznej kompensacji tej ślepoty systemowej, zanim kod trafi do ostatecznej akceptacji przez człowieka.
Wpływ praktyczny: wyzwania testów E2E z AI
Tworzenie testów E2E jest dla AI szczególnie złożone. Chodzi nie tylko o napisanie samego skryptu testowego, ale przede wszystkim o przygotowanie odpowiednich danych testowych, aby oprogramowanie mogło z nich korzystać (często tylko w niewielkiej części testu). Przygotowanie tych danych jest bardzo wymagające.
Weźmy pozornie prostą czynność: kliknięcie listy rozwijanej i wybranie parametru (np. typ dokumentu Faktura). Jeśli test się nie powiedzie lub nie zakończy, kluczowe jest ustalenie dokładnej przyczyny. Mogły zajść różne sytuacje:
- AI zgubiło drogę i nie mogło znaleźć elementu listy rozwijanej w interfejsie (choć jest obecny).
- Test napotkał wcześniejszy błąd na drodze i nie mógł się po nim pozbierać.
- Lista rozwijana istnieje, ale nie zawiera oczekiwanych danych do wyboru.
- AI uciekło się do JavaScriptu (niewidocznego obejścia), z powodzeniem ustawiając wartość programowo, ale pozostawiając ją niewidoczną dla prawdziwego użytkownika.
Wokół jednej listy rozwijanej może pojawić się mnóstwo problemów. Kluczowe jest, czy AI (lub system oceniający) potrafi odróżnić prawdziwy błąd od kaskadowej awarii spowodowanej czymś innym. Samo pomyślne zapisanie danych nie gwarantuje, że wszystko działa prawidłowo.
Podejście behawioralne i pokrycie testami
Z tego powodu testy powinny zawsze skupiać się na aspekcie behawioralnym systemu, testując to, czego faktycznie oczekujemy:
Happy Path (~90% przypadków): Główny nacisk kładzie się na to, co użytkownicy będą robić w zdecydowanej większości przypadków.
Krytyczne przypadki brzegowe: Warunki graniczne, które nie zdarzają się często, ale są kluczowe dla integralności systemu.
Inne, mniej prawdopodobne kombinacje nie są testowane z góry. Jeśli wystąpią na produkcji, są naprawiane na bieżąco lub zapobiega się im ograniczeniami i walidacjami w oprogramowaniu (np. wyłączenie nawigacji, dopóki dane wejściowe nie są poprawne).
Testy E2E w AITM
W AITM testy E2E stanowią wyraźną i obowiązkową fazę pipeline dla zadań wpływających na UI (określaną typem/intencją zadania). To nie jest opcjonalny dodatek, który można pominąć, gdy zbliżają się terminy - pipeline nie może zostać oznaczony jako zakończony bez niej.
Jeśli brakuje testu E2E lub środowisko jest niedostępne, build domyślnie kończy się niepowodzeniem (z rzadkimi wyjątkami, w których nieudany E2E może przejść dalej). Dodatkowo każde wykonanie E2E rejestruje zrzuty ekranu, widoczne w wynikach zadania.
Jak E2E działa obecnie:
- Przed uruchomieniem testów build jest gwarantowanie udany i wykonuje się we własnym, izolowanym worktree.
- Stan bazy danych jest przygotowywany z konkretnymi danymi testowymi obok domyślnych rekordów.
- Testowanie skupia się wyłącznie na Happy Path (nie obejmuje wszystkich możliwych scenariuszy).
Przyszła mapa drogowa E2E:
- Flow Maps - System buduje mapę ścieżek do wskazanych elementów, powiązaną bezpośrednio z logiką biznesową (już zintegrowane w AITM).
- Autonomiczna nawigacja - Testy czytają aktualną mapę ścieżek, wiedząc dokładnie, gdzie kliknąć, wpisać i zweryfikować (obecnie w fazie testów).
- Porównywanie stanów (Visual Diffing) - Każdy krok jest rejestrowany zrzutami ekranu wykonanymi przed i po zmianach w kodzie, aby potwierdzić, że oczekiwane elementy i dane zgadzają się z oczekiwaniami względem bazy danych lub UI.
- Weryfikacja logiki biznesowej - Automatyczne sprawdzanie oczekiwanych danych wyjściowych (np. zweryfikowane sumy faktur - obecnie w trakcie rozwoju).
- Nocne uruchomienia integracyjne - Testy integracyjne end-to-end będą generowane automatycznie ze stanów kroków i wymagań oprogramowania i uruchamiane w nocy. Wszelkie niepowodzenia wygenerują zadania lub poproszą o weryfikację przez człowieka (ponieważ AI może się mylić i potrzebuje akceptacji człowieka).
- Zaawansowane scenariusze - Przyszłe wydania będą obejmować wstrzykiwanie nieprawidłowych parametrów, testowanie współbieżności wielu instancji i symulacje przypadków brzegowych.
Podsumowanie podstawowych zasad E2E
Istota skutecznego testowania E2E opiera się na zarządzaniu mapami i relacjami między encjami danych. W przypadku 90% oprogramowania sprowadza się to do standardowego cyklu życia:
#AITM #Data Input Validation #E2E #Integration test #AI TESTING