Překlenutí mezery mezi záměrem a realizací — od zralosti procesů po testovací architekturu.
Process Maturity and Result Reliability — CMMI and TMMi
Běžné průmyslové nedorozumění staví Waterfall a Agile jako ideologické protiklady. Na behaviorální úrovni je konflikt reálný. Na hlubší úrovni jsou však oba instancemi procesního provádění a kvalita jejich výsledků je řízena stejnou základní proměnnou: procesní vyspělostí.
Capability Maturity Model Integration (CMMI) poskytuje rámec pro měření a zlepšování procesní vyspělosti organizace v celém životním cyklu vývoje softwaru. Jeho pět úrovní vyspělosti — Počáteční, Řízená, Definovaná, Kvantitativně řízená, Optimalizující — popisuje trajektorii od ad-hoc provádění k systematickým, sebelepšícím se procesům.
Test Maturity Model Integration (TMMi) je doplňkovým rámcem pro testovací procesy. Zatímco CMMI pokrývá celý SDLC, TMMi aplikuje stejnou strukturu úrovní vyspělosti výhradně na testování — od počátečního stavu (testování jako chaotický dodatek) až po úroveň 5 (prevence defektů jako primární cíl testování). TMMi a CMMI jsou explicitně navrženy pro společné použití.
Kauzální řetězec: procesní vyspělost → procesní předvídatelnost → spolehlivost výsledků. V poradenských zakázkách MIM2000 je optika CMMI/TMMi aplikována diagnosticky: hodnotíme, kde se procesy klienta nacházejí na škále vyspělosti, identifikujeme konkrétní procesní oblasti způsobující odchylky v kvalitě nebo harmonogramech a doporučujeme cílená zlepšení. Cílem je měřitelné snížení nákladů na přepracování, nikoli certifikace sama o sobě.
References: CMMI Institute, TMMi Foundation (R1.2), ISO/IEC 15504.
UML — The Best Standard That Cannot Guarantee Understanding
Unified Modeling Language (UML 2.x, ISO/IEC 19501) je nejkomplexnější notací pro modelování softwarových systémů, jaká kdy byla standardizována — čtrnáct typů diagramů pokrývajících strukturální, behaviorální a interakční pohledy. Žádná jiná notace nedosahuje takové šíře záběru.
Základní paradox: UML je formální vizuální jazyk s definovanou gramatikou. Shoda s touto gramatikou je ověřitelná. Porozumění přenášenému modelu nikoli. Sekvenční diagram může být syntakticky dokonalý a zároveň čtyřem čtenářům sdělovat čtyři zcela odlišná zamýšlená chování. Gramatická správnost nezaručuje sémantický konsenzus.
To má přímý dopad na testovací analýzu: sekvenční diagram UML předaný testovacímu analytikovi jako „specifikace požadavků" je často Rorschachovým testem. Každý analytik do mezer, které notace nezaplňuje, vkládá své vlastní předpoklady o systému. Výsledkem jsou testovací případy, které testují mentální model analytika, nikoli zamýšlené chování systému.
Diagramy UML jsou koordinační artefakty, nikoli artefakty pravdy. Každý diagram vyžaduje doprovodný písemný narativ, který explicitně vyjadřuje rozhodnutí, která notace ponechává implicitní. Bez narativu vytváří formální gramatika falešnou jistotu sdíleného porozumění.
References: Fowler — UML Distilled (3rd ed.); Rumbaugh, Jacobson, Booch — UML Reference Manual (2nd ed.); ISO/IEC 19501:2005.
SW Testing Services — Advanced V-Model and Test Architecture
V-model mapuje každou fázi vývoje na odpovídající fázi testování. Rozšířený V-model to doplňuje explicitními závislostmi artefaktů a vrstvou Testovací architektury — inženýrskou disciplínou návrhu samotného testovacího systému.
| Development Phase |
Test Phase |
MIM2000 Service |
| Business Requirements | Acceptance Testing | Test Analysis |
| System Requirements | System Testing | Test Analysis + Test Design |
| Architecture Design | Integrační testování | Test Design + Test Architecture |
| Detail Design | Component Testing | Test Design + Test Data |
| Implementation | Unit Testing | Test Deployment + Execution |
Rozhodnutí o testovací architektuře: co testovat na jaké úrovni, s jakými nástroji a s jakými daty — v souladu s celkovou architekturou IT projektu. Klíčové oblasti: rozsah testů na úrovni, hraniční podmínky mezi testovacími úrovněmi, strategie testovacích dat (živá podmnožina vs. simulovaná vs. generovaná), topologie prostředí, hranice automatizace.
Test Automation — Advantages and Limitations
Automatizujte nejprve na vrstvě API/služeb — nejstabilnější kontrakt. UI automatizace pouze pro kritické uživatelské cesty s stabilními selektory. Nikdy neautomatizujte průzkumné testování: hodnota spočívá v lidském kognitivním zapojení. Automatizované testy mohou projít, zatímco systém je vadný, pokud jsou tvrzení nebo rozsah nesprávné — falešná jistota je nebezpečnější než žádná automatizace.
→ Testing & Engineering Blog — field notes by Petr Žemla, CEO & CTO
Architektura řešení
Podpora architektonických rozhodnutí, výběr technologického zásobníku, návrh integračních vzorů a hodnocení škálovatelnosti. Překlenutí propasti mezi obchodními požadavky a technickou proveditelností implementace.
Detailed content in preparation