Bridging the gap between intention and execution — from process maturity to test architecture.
Process Maturity and Result Reliability — CMMI and TMMi
A common industry misconception positions Waterfall and Agile as ideological opposites. At a behavioural level, the conflict is real. But at a deeper level, both are instances of process execution, and the quality of outcomes from both is governed by the same underlying variable: process maturity.
Capability Maturity Model Integration (CMMI) provides a framework for measuring and improving organisational process maturity across the full software development lifecycle. Its five maturity levels — Initial, Managed, Defined, Quantitatively Managed, Optimising — describe the trajectory from ad-hoc execution towards systematic, self-improving processes.
Test Maturity Model Integration (TMMi) is the complementary framework for testing processes. Where CMMI covers the full SDLC, TMMi applies the same maturity-level structure exclusively to testing — from initial state (testing as a chaotic afterthought) to Level 5 (defect prevention as the primary testing objective). TMMi and CMMI are explicitly designed to be used together.
The causality chain: process maturity → process predictability → result reliability. For MIM2000 advisory engagements, the CMMI/TMMi lens is applied diagnostically: we assess where a client's processes sit on the maturity scale, identify specific process areas causing quality or timeline variance, and recommend targeted improvements. The goal is measurable reduction in rework cost, not certification for its own sake.
References: CMMI Institute, TMMi Foundation (R1.2), ISO/IEC 15504.
UML — The Best Standard That Cannot Guarantee Understanding
The Unified Modeling Language (UML 2.x, ISO/IEC 19501) is the most comprehensive notation for software system modelling ever standardised — fourteen diagram types covering structural, behavioural, and interaction views. No other notation achieves this breadth.
The fundamental paradox: UML is a formal visual language with a defined grammar. Conforming to that grammar is verifiable. Understanding the model conveyed is not. A sequence diagram can be syntactically perfect and simultaneously convey four completely different intended behaviours to four readers. Grammar correctness does not guarantee semantic consensus.
This matters directly in test analysis: a UML sequence diagram handed to a test analyst as the "requirements specification" is frequently a Rorschach test. Each analyst reads their own system assumptions into the gaps the notation does not fill. The result is test cases that test the analyst's mental model, not the intended system behaviour.
UML diagrams are coordination artefacts, not truth artefacts. Every diagram requires an accompanying written narrative that makes explicit the decisions the notation leaves implicit. Without the narrative, formal grammar creates false confidence in shared understanding.
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
The V-model maps each development phase to a corresponding testing phase. The advanced V-model extends this with explicit artefact dependencies and a Test Architecture layer — the engineering discipline of designing the test system itself.
| Development Phase |
Test Phase |
MIM2000 Service |
| Business Requirements | Acceptance Testing | Test Analysis |
| System Requirements | System Testing | Test Analysis + Test Design |
| Architecture Design | Integration Testing | Test Design + Test Architecture |
| Detail Design | Component Testing | Test Design + Test Data |
| Implementation | Unit Testing | Test Deployment + Execution |
Test Architecture decisions: what to test at what level, with what tooling, and with what data — aligned to the overall IT project architecture. Key areas: test scope per level, boundary conditions between test levels, test data strategy (live subset vs mocked vs generated), environment topology, automation boundary.
Test Automation — Advantages and Limitations
Automate at API/service layer first — the most stable contract. UI automation only for critical user journeys with stable selectors. Never automate exploratory testing: the value is the human cognitive engagement. Automated tests can pass while the system is wrong if assertions or scope are incorrect — false confidence is more dangerous than no automation.
→ Testing & Engineering Blog — field notes by Petr Žemla, CEO & CTO
Solution Architecture
Architectural decision support, technology stack selection, integration pattern design, and scalability assessment. Bridging the gap between business requirements and technical implementation feasibility.
Detailed content in preparation