Co není testovatelné, není specifikované

Existuje jednoduchý test na to, jestli je požadavek hotový. Ne test kódu, test zadání. Zkuste k té větě napsat konkrétní scénář, který jednoznačně řekne, kdy je splněná a kdy ne. Když to jde, máte specifikaci. Když se u toho zaseknete, protože nevíte, co doplnit, nemáte požadavek, máte přání.

„Systém musí být rychlý.“ Zkuste to otestovat. Za jak dlouho, u jaké operace, při jakém zatížení, z čeho měřeno. Dokud tyhle odpovědi nejsou na papíře, není to specifikace, je to pocit. A pocit se nedá naprogramovat, dá se jen odhadnout, což znamená, že za vás rozhodne někdo jiný než vy, nejspíš ten, kdo to zrovna píše.

Tady se mi osvědčil hierarchický Gherkin, ne kvůli nástroji, ale kvůli formě, kterou vynucuje. Když píšu Given, When, Then, nemůžu zůstat u obecnosti. Given mě nutí pojmenovat výchozí stav. When mě nutí říct, co se přesně děje. Then mě nutí popsat pozorovatelný výsledek, ne dojem. Ta struktura je konstrukčně nepřátelská k vágnosti. Nedovolí mi napsat „mělo by to fungovat dobře“, protože se ptá dobře jak, poznáno čím.

Hierarchie k tomu přidává druhý rozměr. Nahoře je scénář v jazyce byznysu, o úroveň níž jeho funkční rozpad, ještě níž technické detaily a nakonec automatizovatelný krok. Každá vrstva mluví ke své roli, ale všechny musí sedět na sobě. Když technická vrstva neodpovídá byznysové, ukáže se to hned, protože je vidíte vedle sebe. Vágnost nemá kam schovat, protože každé patro musí obstát před tím nad sebou.

Neznamená to víc byrokracie. Znamená to, že práci, kterou stejně někdo udělá, uděláme vědomě a dopředu, ne omylem a pozdě. Otázka na konec tedy nezní, jestli máte čas psát testovatelné zadání. Zní, kdo za vás dopíše to, co v zadání chybí, když ho nenapíšete vy?