Większość zespołów nie ponosi porażki w testowaniu agentowym dlatego, że technologia nie spełnia oczekiwań. Zawodzą, ponieważ wdrażają ją jak narzędzie, podczas gdy zachowuje się jak nowo zatrudniona osoba. Nie ocenialibyście nowego inżyniera QA pierwszego poranka, nie przekazalibyście mu żadnego kontekstu dotyczącego produktu, a potem po cichu nie wrócilibyście do starego procesu, gdy zada pytanie. A jednak mniej więcej tak przeprowadza się wiele ocen autonomicznego testowania – a następnie się z nich rezygnuje.
Tworzymy QA.tech – agentową platformę QA, na której autonomiczne agenty QA testują aplikacje internetowe, żądania pull i aplikacje mobilne na podstawie celów opisanych językiem naturalnym. Przeprowadziliśmy już setki zespołów przez ten proces wdrożenia. Pisaliśmy o nim również obszernie: nasz przewodnik terenowy Poza wąskim gardłem wyjaśnia, jak zdiagnozować, gdzie QA faktycznie spowalnia organizację, a Wdrażanie testowania agentowego: plan działania prowadzi przez pełne wdrożenie – od weryfikacji koncepcji po produkcję. Ten artykuł jest skróconą wersją obu materiałów: przedstawia sekwencję, która działa, dyscyplinę odróżniającą udane wdrożenia od tych, które utknęły, oraz błędy, które obserwujemy najczęściej.
Etap 0: Zmierz wąskie gardło, zanim cokolwiek kupisz
Pierwszy krok ma miejsce, zanim dotkniesz produktu. Przed wdrożeniem QA.tech zdobądź rzetelne dane na temat tego, gdzie weryfikacja faktycznie generuje dziś koszty. Najważniejsze są trzy pomiary.
Po pierwsze, obciążenie związane z utrzymaniem: ile godzin pracy inżynierów w każdym sprincie przeznacza się na naprawianie istniejących testów zamiast na tworzenie nowych, rozwój funkcji lub dostarczanie produktu? Po drugie, opóźnienie w pokryciu: ile czasu mija od połączenia funkcji do uzyskania przez nią wartościowego pokrycia testami – godziny, dni czy „aż ktoś zajmie się zgłoszeniem”? Po trzecie, tarcia przy wydawaniu: jak często wydanie czeka na QA i jak często testy QA są ograniczane, aby dotrzymać terminu?
Te dane pełnią dwie funkcje. Pokazują, czy w ogóle warto wdrażać testowanie agentowe – zespół o niewielkim obciążeniu związanym z utrzymaniem i swobodnym harmonogramie wydań ma słabsze powody, by dokonywać zmiany. Stają się też punktem odniesienia, ponieważ za dziewięćdziesiąt dni będziesz chciał wykazać zmianę w tych samych jednostkach. Działania wdrożeniowe bez punktu odniesienia kończą się na przeczuciach, a przeczucia nie przetrwają przeglądu budżetowego.
Równie ważne jest ustalenie, z czego zrezygnować. Każda godzina spędzona na łatanie kruchego skryptu podczas wdrożenia to godzina dotowania procesu, który zastępujesz. Wybierz zestawy testów, z których pozwolisz sobie zrezygnować, i określ, kiedy to nastąpi.
Etap 1: Określ zakres weryfikacji koncepcji, która rzeczywiście może coś udowodnić
Dobra weryfikacja koncepcji QA.tech jest niewielka, konkretna i uczciwa. O wyniku decydują głównie trzy decyzje dotyczące zakresu.
Wybierz bolesne przepływy. Pokusa rozpoczęcia od najczystszej ścieżki pozytywnej jest duża. Oprzyj się jej. Uwzględnij co najmniej jeden przepływ, który rzeczywiście sprawia dziś problemy – ten wymagający wielu uprawnień, zależny od danych albo taki, którego testowania regresyjnego zespół po cichu się obawia. Jeśli platforma poradzi sobie z najtrudniejszym przypadkiem, łatwe przypadki będą formalnością. Jeśli sobie nie poradzi, chcesz się o tym dowiedzieć w pierwszym tygodniu, a nie w trzecim miesiącu.
Zaangażuj cały zespół. Odczyt uzyskany przez jednego entuzjastycznego inżyniera prowadzącego weryfikację koncepcji będzie zniekształcony. Różne osoby przekazują agentom QA instrukcje w różny sposób – lider QA, menedżer produktu i inżynier backendu sformułują cele na swój sposób, a musisz wiedzieć, że platforma sprawdza się w codziennym języku całego zespołu, ponieważ wyćwiczone polecenia jednego ambasadora dowodzą bardzo niewiele.
Zapisz kryteria zakończenia przed rozpoczęciem. Rzetelne wyniki dla krytycznych ścieżek, akceptowalny poziom wyników fałszywie pozytywnych, działająca integracja z żądaniami pull oraz potwierdzona użyteczność w całym zespole to solidny zestaw podstawowy. Uzgodnij je z naszym zespołem podczas spotkania rozpoczynającego i wymagaj ich spełnienia od obu stron.
Etap 2: Zbuduj dziesięć solidnych testów, zanim zwiększysz ich liczbę do stu
To najtrafniej przewidująca zasada, którą zaobserwowaliśmy podczas wdrożeń, a zarazem ta, którą zespoły najczęściej pomijają. W przypadku platformy potrafiącej generować testy w kilka minut naturalnym odruchem jest wygenerowanie wszystkiego w pierwszym tygodniu. Nie rób tego. Duża liczba testów bez wcześniejszego zrozumienia prowadzi do stosu powierzchownych testów, chaotycznej strony wyników i zespołu, który traci zaufanie do rezultatów.
Zamiast tego zbuduj około dziesięciu istotnych testów i dopracuj je naprawdę solidnie. Uruchamiaj je wielokrotnie. Gdy agent coś źle zrozumie – a na początku będzie się to zdarzać – wyjaśnij mu, dlaczego się pomylił, zamiast po cichu poprawiać wynik; korekta zostanie uwzględniona we wszystkim, co zrobi później. Dziesięć głęboko niezawodnych testów uczy platformę Twojego produktu, a zespół uczy się platformy. Na tej podstawie zwiększenie liczby testów do stu przebiega szybko, a setka dziedziczy jakość dziesięciu pierwszych.
W ciągu tych tygodni warto obserwować krzywą pytań. Zdrowe wdrożenie przypomina nabieranie wprawy przez nowego współpracownika: wiele pytań w pierwszym tygodniu, sporadyczne w drugim i rzadkie w trzecim, ponieważ wiedza platformy o Twoim produkcie się kumuluje. Jeśli liczba pytań nie maleje, porozmawiaj z naszym zespołem zamiast działać dalej na siłę – zwykle przyczyną jest brakujący kontekst produktu, który można szybko uzupełnić.
Faza 3: Włącz ją do potoku i porzuć stary proces
Gdy testy fundamentu są już niezawodne, wdrożenie staje się ćwiczeniem integracyjnym. Połącz repozytorium, aby QA.tech pobierało każdy pull request. Zbierz zestawy testów regresji i dymnych w plany testów uruchamiane zgodnie z harmonogramem odpowiadającym cyklowi wydań. Kieruj wyniki tam, gdzie Twój zespół już pracuje – do samego PR-a, Slacka lub systemu śledzenia zgłoszeń.
Następnie przychodzi część wymagająca prawdziwego przywództwa: wycofanie równoległego procesu. Zespoły, które na czas nieokreślony utrzymują stary zestaw skryptów „na wszelki wypadek”, płacą za dwa systemy i nie ufają żadnemu z nich. Wyznacz datę, opierając się na kryteriach wyjścia, kiedy warstwa agentowa stanie się systemem referencyjnym dla obsługiwanych przez nią przepływów – i trzymaj się jej. Pełny przebieg 90 dni, w tym sposób ustalenia kolejności przekazywania poszczególnych zestawów, został szczegółowo opisany w Blueprint.
Faza 4: Celowo zdefiniuj na nowo rolę QA
Testowanie agentowe zmienia charakter pracy QA, a udawanie, że jest inaczej, tworzy cichy opór, który od środka niweczy wdrożenia. Zajmij się tym bezpośrednio.
Znika tworzenie i utrzymywanie skryptów – praca, którą większość specjalistów QA uzna za najmniej przyjemną. Zastępuje ją wyznaczanie kierunku: decydowanie, co zasługuje na pokrycie testami, przekazywanie agentom kontekstu produktu, którego nie posiada nikt inny, przeglądanie raportów oceny oraz rozszerzanie testów na obszary, które wcześniej nigdy nie były objęte, bo zawsze brakowało na to czasu. Lider QA, który w czwartki naprawiał selektory, staje się osobą pytającą platformę: „które wartościowe przepływy nie mają obecnie pokrycia?” – i działającą na podstawie odpowiedzi jeszcze tego samego dnia.
Wyraźnie określ tę zmianę w pierwszym tygodniu wdrożenia, zanim lęk zdąży się pogłębić. Zespoły, w których osoby zajmujące się QA stają się zaawansowanymi użytkownikami platformy, to zespoły, w których wdrożenie się utrwala.
Błędy, które chwilowo zatrzymują wdrożenia
Pomijanie punktu odniesienia, przez co nikt nie może udowodnić poprawy. Rozpoczynanie od stu wygenerowanych testów zamiast od dziesięciu solidnych. Przeprowadzanie POC przez jednego entuzjastę. Traktowanie pytań z pierwszego tygodnia jako porażki zamiast elementu wdrożenia. Bezterminowe utrzymywanie starszego zestawu. I przemilczanie zmiany roli zespołu QA. Każde zatrzymane wdrożenie, które widzieliśmy, można prześledzić do co najmniej jednego z tych błędów – a wszystkich sześciu można uniknąć, stosując opisaną powyżej sekwencję.
Najczęściej zadawane pytania
Ile czasu zajmuje wdrożenie testowania agentowego?
W przypadku narzędzia do testowania AI, takiego jak QA.tech, pierwsze działające testy powstają w kilka minut, ponieważ nie trzeba konfigurować żadnego środowiska; uzyskanie godnego zaufania fundamentu zajmuje od dwóch do czterech tygodni, a pełne wdrożenie produkcyjne – integracja z PR-ami, plany regresji i wycofanie starszych zestawów – zazwyczaj mieści się w ciągu dziewięćdziesięciu dni.
Czy powinniśmy uruchamiać testowanie agentowe równolegle z naszym istniejącym zestawem testów?
Tak, w okresie przejściowym – z określoną datą końcową. Bezterminowe uruchamianie obu systemów podwaja koszty i rozdziela zaufanie; ustal kryteria przekazania dla każdego zestawu i celowo wycofaj stary proces.
Kto powinien odpowiadać za wdrożenie testowania agentowego?
Sponsoruje je lider działu inżynieryjnego, ale codzienna odpowiedzialność najlepiej sprawdza się po stronie QA – osoby te posiadają kontekst produktu potrzebny agentom, a wdrożenie kończy się sukcesem, gdy stają się zaawansowanymi użytkownikami platformy.
Co powinniśmy mierzyć, aby udowodnić, że wdrożenie się powiodło?
Ten sam punkt odniesienia, który ustaliliście przed rozpoczęciem: liczbę godzin poświęcanych na utrzymanie w każdym sprincie, czas od scalenia do uzyskania pokrycia oraz liczbę wydań opóźnionych przez QA. Porównaj wyniki dziewięćdziesiątego dnia.
Gotowi do przeprowadzenia wdrożenia? Zacznij od diagnozy w Poza wąskim gardłem albo skontaktuj się z naszym zespołem, aby zobaczyć, jak najlepsze zespoły deweloperskie wydają szybciej dzięki agentom QA weryfikującym każde wydanie.
