Za léta v oboru testování systémů, dominantně softwaru, enterprise systémů, jsem dospěl k závěru, že s fyzikálním backgroundem vidím testing dosti jinak než většina kolegů, kteří se s s ním seznamovali v rámci computer science studií. Fyzika je disciplína, ve které (pokud funguje tak jak má, tedy jak se osvědčila) hypotéza, interpretace a experiment se navzájem motivují a potřebují. Měření je v základu a v tom, jak je experiment postaven se současně zrcadlí míra pochopení problému a také způsobu získávání a vyhodnocování dat – převedení na to, čemu se trochu populárně říká fyzikální veličina. Hodnota fyzikální veličiny je smysluplná pouze tehdy, když je spojena s měřicí procedurou a jednotkou. Stejný princip platí bez úprav pro kvalitu softwaru. To ale neznamená, že je v projektu SW systému náležitě reprezentován – a jako praktik mohu říct, že jsem se jen velmi málo kdy setkal s tím, že by test architekt a test analytik byli náležitě přítomni již v inception fázi celého „dobrodružství“. Což pravidelně vede k tomu, že se z takového projektu opravdu stává dobrodružství ve smyslu adrenalinového sportu.
Měření jako fundamentální akt
Kelvinovo dictum je jednoznačné: „Když dokážeš to, o čem mluvíš, změřit a vyjádřit číslem, něco o tom víš; když to nedokážeš, tvoje znalost je chudá a neuspokojivá.“ Kvalita, která se nedá měřit, je názor. Kvalita měřená podle definovaných kritérií je inženýrský výsledek. Testování v inženýrských disciplinách reprezentuje – ačkoliv je v principu stejné – trochu něco jiného než při vědecké práci (alespoň pokud se bavíme o práci prvotřídní, nikoliv pouze repetitivní, to je však již jiné thema). Nejlépe to „vidí“ Test Architekt během fáze návrhu testování jako celku, kdy je třeba celostní pohled a vyhodnocení rizik ze širší perspektivy. Tomu jistě budeme věnovat více postřehů v jiných příspěvcích, je to téma zásadní a ani v běžné SW literatuře nějak dobře uchopené.
Testovací analýza je z tohoto úhlu pohledu akt odvozování měřitelných testovacích cílů (Test Targets) z testovací báze — specifikace požadavků, architektonických kontraktů, definicí rozhraní atd. atp. Testovací cíl je inženýrský protějšek toho, čemu se v moderním fyzikálním dictu (zejména s odkazem na kvantově mechanický úzus) říká „měřitelná“(observable) : přesně specifikovaná vlastnost systému, pro niž lze definovat koherentně metriku a následně formulovat kritérium průchodu/selhání. Bez tohoto derivačního kroku se testování stává náhodným průzkumem a výsledky nelze reprodukovat.
Pokrytí jako problém vzorkování
Teorie pokrytí v testování zrcadlí teorii vzorkování v experimentální vědě. Prostor možných vstupů do jakéhokoli netriviálního softwarového systému je astronomicky velký. Prostor stavů systému je -při přístupu bottom-up „od kódu“ – exponenciálně narůstající. Zapojení třetích stran v podobě dnes populárních Machine learningových systému jako je Agentic LLM based to, čemu se říká „A.I.“ situaci z hlediska možných modů selhání nejen že nezlepšuje, naopak přidává stupně volnosti, které nemáme pod kontrolou. Vyčerpávající testování ve smyslu plného pokrytí, jak na vstupech, tak na stavech systému korespondujících empiricky relevantním funkcionalitám, včetně všech možných hraničních, subhraničních a přeshraničních stavů, je kombinatorická sebevražda. Automatizace sice zlevňuje opakované regresní testy a relativně usnadňuje testy v případě, že máme pro funkcionalitu dobře napsaný test script (parametrizace daty), ale vyžaduje údržbu a kontrolu nad průchodem prostředími/datovými sadami. Opět, generativní tooly radikálně zlevňují produkci skriptů, někdy mockovacích dat, ale ne nutně správnost pokrytí na úrovni funkcionality (semantika je prevít) a produkují vícepráce na straně údržby test sad a test dat. Úkolem testanalytika (ve spolupráci s ostatními projektovými hráči) je tedy vybrat konečný, reprezentativní vzorek, který poskytuje statisticky spolehlivé pokrytí prostoru datových vstupů a prostoru stavů systému, což spolu úzce souvisí..
Invariant testování
Testování — jakožto Měření — je invariantní vůči metodologiím, podobně jako zákony fyziky nejsou na metodologii zvolené pro měření závislé (i když způsob jejich formulace býti může, ale to je zase na jiný post). Funkce se buď chová podle specifikace, nebo ne. Hranice sprintu to nemění. Architektonický pattern to nemění. Co se mezi metodologiemi mění, je kadence, v níž se měření provádí, a rozsah testovací báze dostupný v každém měřicím bodě. To je asi komukoliv zběhlému ve větších SW projektech zjevné.
Inženýrsko manažerský důsledek, na který bychom chtěli upozornit: náklady na opravu defektů strmě rostou se vzdáleností mezi bodem vnesení a bodem detekce. Toto není manažerský princip — je to důsledek struktury softwarových artefaktů. Ekonomický incentive pro včasné angažmá Test Architekta a následně Test Analytika do týmu je tím dán poměrně jasně. Lze jej zkusit i změřit, ve finančním slova smyslu, což se dle mé zkušenosti děje málokdy, neboť tolerance vůči bugům se v posledních dvou dekádách zvýšila, zatímco tolerance vůči rychlosti dodávky a nákladům se zhoršily. Nicméně incentive pro časnou testovací analýzu vyplývá bezprostředně z nastíněné struktury.