Testy oprogramowania w czasach AI: czego wymagać od wykonawcy

Testy oprogramowania w czasach AI wymagają od wykonawcy więcej dowodów, nie mniej. Skoro zespół pisze kod szybciej z pomocą modeli językowych, zamawiający powinien dostać raport z testów przy każdym wydaniu, listę przetestowanych ścieżek krytycznych dla biznesu i jasną odpowiedź, kto sprawdza testy wygenerowane przez AI. Poniżej opisuję, co AI realnie zmienia w testach, czego nie przejmuje, o co pytać wykonawcę i jak zapisać to w umowie oraz przy odbiorze.

Co AI zmienia w testach oprogramowania

AI najbardziej przyspiesza pisanie testów, które da się wyprowadzić wprost ze specyfikacji albo z istniejącego kodu. To dobra wiadomość, bo testy automatyczne przez lata były pierwszą rzeczą, na której wykonawcy oszczędzali, gdy brakowało czasu.

W praktyce narzędzia AI pomagają zespołom w kilku miejscach:

• generowanie szkieletów testów jednostkowych dla nowych funkcji,
• rozpisywanie przypadków testowych z opisu wymagań, także przypadków brzegowych, o których łatwo zapomnieć,
• uzupełnianie testów regresji, czyli sprawdzających, czy zmiana nie zepsuła tego, co działało (definicję i resztę terminologii porządkuje słownik testowania ISTQB),
• przygotowanie danych testowych i opisów błędów,
• wyjaśnianie starego kodu przed napisaniem testów do systemu, który ich nigdy nie miał.

Szerzej o tym, co narzędzia AI zmieniają w pracy wykonawcy i po stronie klienta, pisałem we wpisie o AI w zespole programistów. Tu skupiam się na jednym: jak sprawdzić, że szybciej napisany kod naprawdę działa.

Czego AI w testach nie przejmuje

AI nie przejmuje odpowiedzialności za to, czy test sprawdza właściwą rzecz. Model potrafi napisać test, który przechodzi, ale nie wie, co jest poprawnym zachowaniem w Twojej firmie, jeśli nikt mu tego nie powiedział.

Największe ryzyko widzę w sytuacji, gdy ten sam model pisze kod i test do niego. Weźmy przykład: system B2B ma liczyć rabat od ceny netto, a w specyfikacji zabrakło tego zdania. Model zakłada cenę brutto, pisze kod i test zgodny z tym założeniem. Test jest zielony, raport wygląda dobrze, a błąd wychodzi dopiero na fakturach klientów. Test nie wykrył błędu, tylko go potwierdził.

Dlatego po stronie ludzi zostają trzy rzeczy:

• kryteria akceptacji, czyli opis, kiedy funkcja działa poprawnie z punktu widzenia biznesu,
• przegląd testów przez osobę, która zna proces, a nie tylko kod,
• testy na danych biznesowych: prawdziwe przypadki z Twojej firmy, odpowiednio zanonimizowane, a nie tylko dane wymyślone przez model.

O co pytać wykonawcę

Pytaj o dowody, a nie o deklaracje. Zdanie „mamy testy automatyczne” nic nie mówi, dopóki nie zobaczysz, co sprawdzają i kiedy się uruchamiają.

1. Raport z testów przy każdym wydaniu. Ile testów uruchomiono, które nie przeszły, co z nimi zrobiono. Raport powinien powstawać automatycznie, nie w arkuszu przygotowanym na spotkanie.
2. Lista ścieżek krytycznych. Zamówienie, płatność, faktura, uprawnienia, integracja z ERP. Dla każdej: czy jest test automatyczny, czy ręczny, czy żaden.
3. Kto zatwierdza testy wygenerowane przez AI. Imię roli, nie „zespół”. Test dopisany przez narzędzie powinien przejść ten sam przegląd co kod.
4. Środowisko testowe. Gdzie testujecie, na jakich danych i czy jest ono zbliżone do produkcji pod względem konfiguracji i integracji.
5. Testy regresji przy każdej zmianie. Czy uruchamiają się same przy każdej zmianie w repozytorium, czy tylko przed większym wydaniem.
6. Testy bezpieczeństwa. Jakie wymagania są sprawdzane i według czego. Dobrym punktem odniesienia jest standard OWASP ASVS, bo opisuje wymagania tak, że da się je zweryfikować testem. Więcej o tym w tekście o minimum bezpieczeństwa aplikacji.

Pokrycie testami: dlaczego sam procent nie wystarcza

Wskaźnik pokrycia kodu testami mówi, jaka część kodu została uruchomiona w trakcie testów, a nie czy testy sprawdzają coś sensownego. Z narzędziami AI łatwo go podnieść w jeden dzień, generując setki testów, które wywołują funkcje i nie sprawdzają wyniku.

Zamiast pytać o procent, poproś o mapę: lista procesów biznesowych, przy każdym informacja, które scenariusze są przetestowane i jak. Taka mapa jest zrozumiała dla zarządu i od razu pokazuje luki. Jeśli wykonawca dodatkowo pokazuje pokrycie kodu, traktuj je jako sygnał pomocniczy. Nagły skok tego wskaźnika bez zmian w funkcjach to dobry powód, żeby zapytać, co właściwie dopisano.

Jak zapisać testy w umowie i przy odbiorze

Testy oprogramowania powinny być częścią tego, co kupujesz, a nie usługą dodatkową. W umowie zapisałbym kilka rzeczy:

• definicję ukończenia zadania, która obejmuje testy automatyczne dla nowej funkcji i przegląd kodu,
• przekazanie testów razem z kodem, w tym samym repozytorium, z prawami do nich jak do reszty kodu,
• raport z testów jako element każdego odbioru częściowego,
• zasadę, że błąd wykryty po odbiorze w przetestowanej ścieżce dostaje test, który go odtwarza, zanim zostanie poprawiony,
• informację, jakich narzędzi AI używa wykonawca i kto odpowiada za ich wynik (zawsze wykonawca).

Odbioru nie zastąpi raport wykonawcy. Testy akceptacyjne robią Twoi ludzie, na scenariuszach opisanych językiem procesu, tak jak opisałem w tekście o odbiorze systemu IT i testach akceptacyjnych. Po wdrożeniu ta sama logika przechodzi do umowy SLA na utrzymanie: każda poprawka i aktualizacja powinna przejść testy regresji, zanim trafi na produkcję.

Sygnały ostrzegawcze

Kilka sytuacji, w których warto zatrzymać się i dopytać:

• „AI przetestowało” jako jedyna odpowiedź na pytanie o testy,
• raporty, w których nigdy nic nie pada, nawet po dużych zmianach,
• testy dopisywane tylko po zgłoszonych błędach, nigdy przed wydaniem,
• brak środowiska testowego albo testy wprost na produkcji,
• brak dostępu klienta do repozytorium i historii uruchomień testów.

Żaden z tych sygnałów nie przesądza, że wykonawca jest zły. Każdy oznacza jednak, że nie masz dowodu, że system działa tak, jak zapłaciłeś.

Testy oprogramowania w czasach AI są tańsze do napisania niż kiedykolwiek, więc nie ma powodu, żeby ich brakowało w projekcie. Na najbliższym spotkaniu z wykonawcą poproś o raport z ostatniego wydania i listę ścieżek krytycznych z informacją, które mają testy. Po tej rozmowie będziesz wiedzieć więcej o jakości swojego systemu niż po niejednym statusie projektu.