Gdzie wciąż decyduje człowiek

O 20:25 Dispatcher wysłał mi plan testów z 32 krokami. Trzy funkcje były wtedy na produkcji od kilku godzin, każda bramka była zielona i nic nie zostało wycofane. Nadal nie było wiadomo, czy to jest to, o co prosiłem. Ta część jest o sprawdzeniach, które zostają przy człowieku, i o trzeciej porażce tego dnia, która wydarzyła się właśnie w takim kroku.

Plan testów, który agent napisał dla mnie

Automatyczne bramki nie powiedzą, czy funkcja robi to, czego chciał biznes, więc pod koniec drugiego przebiegu Dispatcher zaplanował dla mnie sprawdzenie przez człowieka. Napisał plan testów akceptacyjnych: 32 kroki w 9 sekcjach, każdy z opisem, co zrobić, oczekiwanym wynikiem i pustym polem na moją uwagę. Przygotował dwie paczki testowe: dobrą, z tabelą, obrazkiem i PDF, oraz uszkodzoną, którą panel powinien odrzucić. Ułożył kroki tak, żeby test asystenta szedł na artykule opublikowanym kilka kroków wcześniej, a ostatnia sekcja sprząta, żeby żadna testowa treść nie została w pamięci asystenta.

Zajęło mi to około 40 minut. Wpisywałem wyniki w pola, wklejałem zrzuty ekranu tam, gdzie coś wyglądało źle, zapisałem plik i napisałem Dispatcherowi, że jest gotowy.

Co znalazłem

22 z 32 kroków przeszło bez uwag. Jednego nie dało się jeszcze wykonać, bo potrzebna poprawka była w drodze. Pozostałe dziewięć było najciekawsze:

• Dwa defekty. Angielska i polska lista artykułów pokazywały co innego: angielska wymieniała artykuł testowy, polska mówiła, że nic jeszcze nie opublikowano. A spis treści na stronie instrukcji nie wyglądał jak nawigacja i miał paski przewijania, których nie powinno być.
• Pięć nowych próśb. Otwierać artykuł w nowej karcie po publikacji. Wysyłać e-mail kontaktowy w mojej identyfikacji wizualnej. Pozwolić mi dodawać fakty do wiedzy asystenta, a nie tylko je edytować. Pozwolić mi przywrócić usunięty fakt. Pozwolić mi zaznaczyć kilka artykułów i wycofać albo usunąć je naraz.
• Jedna luka w instrukcjach. Skill do publikowania nie wyjaśniał, jak dołączać pliki PDF ani jak opublikować artykuł w dwóch językach.
• Jeden błąd w samym planie testów. Asystent nie odpowiedział na pytanie o artykuł testowy. Dispatcher doszedł do przyczyny: wcześniejszy krok kazał mi usunąć fakt, a następny pytał asystenta właśnie o ten fakt. Asystent zachował się poprawnie i odmówił powoływania się na fakt, który usunąłem. Agent, który napisał plan, sprawdzał własną funkcję ze złym oczekiwanym wynikiem.

Dispatcher przeczytał wyniki, do każdej uwagi napisał diagnozę i w ciągu kilku minut uruchomił poprawki jako nowy pakiet.

Uwaga: zielone testy, zła funkcja. Bramki są tak dobre, jak to, co sprawdzają. Tutaj CI sprawdza kod, zasady treści i build, a testy na produkcji potwierdzają, że strona odpowiada. Nic automatycznego nie sprawdza, czy funkcja robi to, czego chciał biznes. Ten przegląd nadal robi człowiek i trzeba go zaplanować. Niech agent go przygotuje, ale czytaj jego plan tak krytycznie jak jego kod.

Uwaga: każde demo wydłuża listę życzeń. Gdy ludzie zobaczą działającą funkcję, od razu widzą, czego jeszcze chcą. Mój własny test dał pięć nowych próśb. Rozrost zakresu to stary problem; zmieniło się tempo, w jakim następuje. Każda prośba wygląda na dwie godziny pracy agenta, więc wydaje się darmowa. Dwie godziny tu, dwie tam i kolejne dziesięć godzin znika. Hamuj świadomie. Zapisuj każdą prośbę, oddzielaj defekty od życzeń i zdecyduj, które życzenia wchodzą do tego wydania, zanim ktokolwiek zacznie je budować.

Nocna zmiana

Poszedłem spać. Dispatcher pracował beze mnie do 01:01. Wdrożył poprawki z mojego testu, zbudował nawigację dla formatu serii i przyjrzał się dwóm testom, które od czasu do czasu nie przechodziły. Jeden z nich ukrywał prawdziwy błąd serwera: wgranie pliku ponad limit rozmiaru zamykało połączenie, zamiast zwrócić czytelny błąd. Nauczyłem się traktować testy, które czasem nie przechodzą, jak błędy.

Zanim wgrał cokolwiek prawdziwego, przeszedł całą ścieżkę publikacji na serii testowej: wgranie, podgląd, publikację wszystkich części naraz, nawigację w obu językach, wycofanie i powrót każdego adresu do "nie znaleziono". Potem wgrał prawdziwą serię jako szkic prosto z dokumentu Claude Docs i napisał mi nowy plan testów na rano, z zaznaczonymi do mojej akceptacji nowymi etykietami, które sam wybrał.

Nic nie stało się publiczne w nocy. Ostatnia kontrola należy do mnie: przechodzę plan i nic nie trafia na stronę, dopóki nie powiem tak.

Gdzie agent się zatrzymuje

Niektóre kroki nigdy nie powinny należeć wyłącznie do agenta. W drugim przebiegu Dispatcher zbudował skill, który publikuje artykuły z mojego narzędzia do pisania na stronę przez API. Ten skill potrzebował danych dostępowych maszyny do panelu administracyjnego i tu agent się zatrzymał. Otworzył właściwą stronę w mojej przeglądarce, rozpisał każde kliknięcie i poprosił o zgodę, zanim cokolwiek zmienił na koncie. Sekret wygenerowałem i zapisałem sam, a na swój komputer wprowadziłem go poleceniami, które agent przygotował; agent nigdy go nie widział. Zanim dotknął konfiguracji serwera, zapytał ponownie. Hasła, płatności i wiadomości wysyłane w moim imieniu zostają przy mnie. Całą resztę agent może zrobić.

Porażka 3: niewidoczne znaki w danych dostępowych

Krok, który zatwierdziłem, i tak poszedł źle. Za moją zgodą agent dopisał identyfikator danych dostępowych do konfiguracji serwera. Po drodze przez powłokę Windows wartość złapała dwa niewidoczne znaki: znacznik kolejności bajtów (BOM) na początku i znak końca linii na końcu. Usługa się zrestartowała, testy na produkcji były zielone i nikt nic nie zauważył.

Wykryło to następne wydanie. Pięćdziesiąt minut później mała poprawka zatrzymała się na kontroli konfiguracji przed wejściem na produkcję, a produkcja została na poprzednim wydaniu, nietknięta. Agent znalazł przyczynę, ponownie poprosił o moją zgodę i oczyścił tę jedną linię. Zapisał też własny błąd: po zapisaniu wartości policzył linie w pliku, zamiast sprawdzić bajty.

Z jednej linii konfiguracji wyciągnąłem dwie lekcje. Dobry test sprawdza to, czego dotknęła zmiana, a nie tylko to, czy strona odpowiada. A krok, który wymaga zgody człowieka, nie jest przez to automatycznie bezpieczny; często jest najsłabiej przetestowanym krokiem w całym procesie.

Uwaga: ręczny krok, którego nikt nie sprawdza. Pipeline'y są testowane codziennie, a kroki przy sekretach, kontach i ustawieniach serwera wykonuje się raz i im się ufa. Zamień je w skrypty, sprawdzaj wynik bajt po bajcie i niech kolejne wydanie weryfikuje konfigurację, od której zależy.

Gdybym prowadził twój zespół

Prosiłbym agenta o napisanie planu testów akceptacyjnych dla każdej funkcji, a potem dawał go do wykonania product ownerowi, a nie agentowi. Każdemu ręcznemu krokowi przy sekretach i ustawieniach dałbym też skrypt i kontrolę, nawet jeśli wykonuje się raz w roku.

Do pobrania

• Przykład: plan testów akceptacyjnych z moimi wynikami (po angielsku) (PDF, 601 KB). Plan, który Dispatcher napisał do mojego ręcznego sprawdzenia: 32 kroki i oczekiwany wynik dla każdego. Moje wyniki i zrzuty ekranu są w szarej kolumnie; puste pole znaczy, że krok przeszedł. Bez wewnętrznych ścieżek.