Zrychlili jste psaní. Ověřování ne

Jedna skupina firem má zautomatizovanou celou cestu od zadání až k hotovému kódu. Pak se to nasadí na testovací prostředí a tam to dnes končí.

O tom, jak rychle se věc dostane k zákazníkovi, tím rozhoduje kapacita ověřování. V jednom provozu, který si to změřil, trvá jeden regresní cyklus osm až devět dní.

Ta cesta vede přes zadání, návrh řešení, plán a vývoj. Každý krok po sobě nechá dohledatelný záznam a čeká, dokud ho člověk nepodepíše. Poslední podpis rozhoduje, jestli se kód smí spojit se zbytkem, a pak ho pipeline nasadí na testovací prostředí.

Za tou hranou se testuje rukama. Testeři aplikaci proklikávají sami, maximálně si u toho pomůžou nástrojem.

Je to vědomé rozhodnutí: ověřování zatím stíhá, protože vývoj je kvalitní a chyb je málo. Tým, který ověřuje, se ale nerozšiřuje a rozpočet na něj je druhý rok stejný, zatímco práce přitéká víc.

Na čem vám padají testy

V provozu, který si to změřil, bývá z dvaceti spadlých testů pět opravdových chyb, tedy čtvrtina. Zbylých patnáct spadlo kvůli změněnému textu.

Texty mění marketing, nezávisle na vývoji a bez vazby na testy, které se o ně opírají. Když si v tom provozu regresní cyklus rozložili, vyšla z celého cyklu přibližně třetina testů, u kterých se má opravovat proces, ne test.

V tom provozu teď běží pilot s garancí, že cyklus zkrátí na polovinu. Samotný agent napojený na regrese dá na začátku kolem deseti procent. Na padesát až šedesát procent se firma dostane, až k agentovi přidá změnu procesů. V garanci je proto napsaný předpoklad, že do procesů firma pustí.

Cíl je jeden den. Klient předem slyšel, že za další tři měsíce se tam nedostane.

Co s tím do konce sprintu

• Zjistěte, kdo dnes dostane spadlý test z textové změny. Ne kdo by ho dostat měl. Když ho dostane ten samý člověk jako opravdovou chybu, prochází vaše ověřování jednou schránkou a rozlišuje se až ručně.
• Negenerujte testy jako první krok. V tom provozu jim jiná firma před rokem vygenerovala stovky duplicitních testů. Čím víc vašich testů padá na změněném textu, tím víc si jich generováním přidáte na příští změnu textu.
• Ptejte se na cestu z ověřování zpátky do zadání. Test navázaný na text se dá navázat na chování produktu. Opravuje se to ale tam, kde se zadání píše.

Ta skupina z úvodu má každý krok podepsaný. Krok, který rozhoduje o datu, kdy se věc dostane k zákazníkovi, podpis nemá.

Pohled za byznys — Jakub Štengl

Někdo vám nabídne, že zkrátí regresní cyklus o polovinu. Rozložte si tu nabídku, než ji podepíšete.

Samotný nástroj z toho udělá jen malý kus, zbytek dělá změna procesů u vás. Kdo si to nerozpadne, kupuje desetinu za cenu poloviny a za rok bude hledat, kde se úspora ztratila. Zeptejte se každého dodavatele, kolik z jeho čísla udělá samotný nástroj a kolik vaše procesy. Kdo odpoví bez mrknutí, s tím se dá mluvit dál.

Jeden zadavatel, kterého jsem viděl, má kapacitu ověřování v kontraktu. Dodavatel se zavázal otestovat 120 až 150 položek zadání za dvoutýdenní sprint při konstantní rychlosti. K tomu nese trestné body za chyby, které dojdou až do produkce.

Člověk, který takové zadání u jedné skupiny drží, to řekl přímo: „fakt tady nesedíme pro to, abych vyházal QA.“ Jeho metrika je, kolik regresních cyklů obslouží stejný tým, až přijde další práce.

Pohled za technologie — Jakub Inger

Agenta, který ti píše kód, budeš muset ověřovat taky.

Jednu věc nastav rovnou. Od prvního dne sbírej datasety a logy z vlastních případů. Model se v čase mění a stejný prompt bude interpretovaný jinak. Evaly nad tvými vlastními případy jsou to jediné, čím ten posun poznáš včas.