Ile to kosztuje, co zwraca

Część 3, ta dla tego, kto podpisuje fakturę.

Uczciwy pitch QA nigdy nie brzmiał “łapiemy bugi”. Brzmi “oto ile ta decyzja kosztuje i oto co zwraca”. Nauczyłem się tego wolną drogą, przechodząc od osoby, która blokuje release, do osoby, która kładzie handel na stole i pozwala zdecydować temu, kto płaci. Więc postawmy decyzję o architekturze w tych kategoriach.

Utrzymanie: jedna zmiana, jedno miejsce

Jednokierunkowy graf zależności zamienia większość zmian w edycję jednego pliku.

Przesunął się selektor. Edytujesz components.ts. Jeden plik. Każdy test, który go używał, jest już naprawiony.

Flow zyskał krok, powiedzmy dodatkowy ekran potwierdzenia. Edytujesz actions.ts. Jeden plik. Wszystkie trzydzieści testów, które wołają ten flow, dziedziczą zmianę.

Nowy scenariusz. Dopisujesz do test.ts. Pozostałe trzy warstwy się nie ruszają.

Porównaj to z metodą od wszystkiego, gdzie selektor i reguła biznesowa siedzą w jednym miejscu. Dotykasz pliku, ryzykujesz drugi obowiązek i re-review całości, żeby mieć pewność. Kosztem nie jest edycja. Kosztem jest promień rażenia edycji.

Skalowanie: aktyw o płaskim koszcie

Nowy tester celuje w jeden folder. Cztery pliki, każdy oczywisty, szablon, który może skopiować i edytować pierwszego dnia. Onboarding spada z tygodni do dni.

Dziesiąty test w feature kosztuje mniej więcej tyle, co drugi, bo kształt się nigdy nie zmienia. Ta płaskość to właściwy aktyw. Większość zestawów robi się droższa za test w miarę wzrostu, dlatego po cichu przestają rosnąć. Ten się tak nie wygina.

Track record, zanonimizowany ale realny

Dwa lata. Mniej więcej 25 miesięcy i licznik bije dalej.

Dziewięć systemów produkcyjnych.

3000+ testów wciąż działa w portfolio, od 180 do 520 na system.

Dwa z dziewięciu projektów umarły z niezwiązanych powodów biznesowych. Pozostałe siedem do dziś uruchamia testy w kształcie CDAT. Nie sprzedaję cudu. Raportuję wskaźnik przeżycia.

Dlaczego to nie jest rozmowa z 2019

Oto część, która sprawia, że decyzja o architekturze jest pilna teraz.

Koszt napisania testu się zapada. Agenty napiszą ich więcej, szybciej, w tym roku i w następnym. Wąskie gardło przesuwa się z “pisania testów” na “utrzymanie testów, które maszyna napisała z prędkością maszyny”. A maszyna pisząca w god-object produkuje dług też z prędkością maszyny.

Więc decyzja o architekturze jest teraz decyzją o AI. Deterministyczna struktura to rzecz, która pozwala ci bezpiecznie podkręcić prędkość generowania. Bez niej szybsze generowanie to po prostu szybszy bałagan. Tooling, agenty, cały kolejny odcinek tej serii, zwracają się tylko na strukturze, która już się trzyma. Kontekst najpierw, potem AI. Kolejność nie podlega negocjacji, a ustawiasz ją raz, na architekturze.

ROI, w walucie która się liczy

Każda godzina, którą senior spędza grepując monolit w poszukiwaniu miejsca, gdzie żyje zmiana, to godzina nie wydana na pokrycie, które zatrzymałoby incydent na produkcji.

Regresja, którą wypuszczasz, bo rozdzielona metoda pozwoliła poprawić jedną połowę i przeoczyć drugą, to nie jest pozycja QA. To pozycja przychodowa. Jakiś procent userów na nią trafia, nie kupuje, a kolejka supportu się zalewa. Ten, kto podpisuje fakturę, decyduje ile to warte, więc podaj mu liczbę w jego walucie: zaoszczędzone godziny utrzymania, obniżone ryzyko incydentu, onboarding liczony w dniach zamiast w tygodniach.

Gdzie traci

Pomiń to, kiedy projekt to pięć testów na statycznej stronie. POM wystarczy, wszystko wystarczy.

Pomiń przy kodzie wyłącznie w JavaScript, który taki zostanie, bo tracisz jedną trzecią wartości siedzącą w bezpieczeństwie typów.

Pomiń, kiedy zespół już dobrze dowozi Screenplay. Nie psuj tego, co działa.

Wzorzec zarabia na siebie na systemach, które muszą przeżyć i szybką pracę nad feature’ami, i miesiąc, w którym pierwotny autor zmienia zespół. Jeśli twój system nie musi tego przeżyć, nie potrzebujesz tego.

Jeśli twój zestaw zaczął gnić

To jest rozmowa, którą prowadzę zawodowo, szczególnie tuż przed tym, jak zespół spuszcza agenty na zestaw, który jeszcze ich nie udźwignie.

Wdrożenie i konsulting: sdet.it/services

Sam wzorzec jest na MIT i publiczny: github.com/darco81/cdat-pattern

Jest endpoint MCP pod cdat.sdet.it/mcp, jeśli chcesz, żeby twój własny asystent przeczytał dokumentację najpierw, co jest pasującym sposobem na zakończenie odcinka o dawaniu maszynie struktury, którą potrafi ogarnąć.

Powiązane

Długie uzasadnienie, każda warstwa z pełnym kodem: deep dive CDAT.

Większy obraz, w który wpina się ten odcinek: Context-First QA, Series #03.

Wzorzec ma własną stronę produktową i sprawdza się na samym sobie, 124 testy CDAT-on-CDAT przeciw niej: cdat.sdet.it.

From the Field to jest to, co realnie buduję, co się psuje i czego się uczę. Realne projekty, realne liczby, realne bugi. Bez tutoriali.