Bridging the gap between intention and execution — from process maturity to test architecture.
Process Maturity and Result Reliability — CMMI and TMMi
Eine verbreitete Fehlannahme in der Branche stellt Waterfall und Agile als ideologische Gegensätze dar. Auf der Verhaltensebene ist der Konflikt real. Auf einer tieferen Ebene jedoch sind beide Instanzen der Prozessausführung, und die Qualität der Ergebnisse beider wird von derselben Grundvariable bestimmt: der Prozessreife.
Capability Maturity Model Integration (CMMI) bietet einen Rahmen zur Messung und Verbesserung der organisatorischen Prozessreife über den gesamten Software-Entwicklungslebenszyklus. Seine fünf Reifegradebenen — Initial, Gemanagt, Definiert, Quantitativ gemanagt, Optimierend — beschreiben den Weg von Ad-hoc-Ausführung zu systematischen, sich selbst verbessernden Prozessen.
Test Maturity Model Integration (TMMi) ist das ergänzende Framework für Testprozesse. Während CMMI den gesamten SDLC abdeckt, wendet TMMi dieselbe Reifegrad-Struktur ausschließlich auf Tests an — vom Anfangszustand (Testing als chaotischer Nachgedanke) bis Level 5 (Defektprävention als primäres Testziel). TMMi und CMMI sind explizit für die gemeinsame Nutzung konzipiert.
Die Kausalitätskette: Prozessreife → Prozessvorhersagbarkeit → Ergebniszuverlässigkeit. Bei MIM2000-Beratungsaufträgen wird die CMMI/TMMi-Linse diagnostisch angewendet: Wir beurteilen, wo die Prozesse eines Kunden auf der Reifeskala liegen, identifizieren spezifische Prozessbereiche, die Qualitäts- oder Zeitplanabweichungen verursachen, und empfehlen gezielte Verbesserungen. Das Ziel ist die messbare Reduzierung der Nacharbeitskosten, nicht die Zertifizierung um ihrer selbst willen.
References: CMMI Institute, TMMi Foundation (R1.2), ISO/IEC 15504.
UML — The Best Standard That Cannot Guarantee Understanding
Die Unified Modeling Language (UML 2.x, ISO/IEC 19501) ist die umfassendste je standardisierte Notation für die Modellierung von Softwaresystemen — vierzehn Diagrammtypen decken strukturelle, verhaltensbezogene und Interaktionssichten ab. Keine andere Notation erreicht diese Breite.
Das grundlegende Paradoxon: UML ist eine formale visuelle Sprache mit einer definierten Grammatik. Die Einhaltung dieser Grammatik ist überprüfbar. Das Verständnis des übermittelten Modells ist es nicht. Ein Sequenzdiagramm kann syntaktisch perfekt sein und gleichzeitig vier Lesern vier völlig unterschiedliche beabsichtigte Verhaltensweisen vermitteln. Grammatikkorrektheit garantiert keinen semantischen Konsens.
Dies ist direkt relevant für die Testanalyse: Ein UML-Sequenzdiagramm, das einem Testanalytiker als „Anforderungsspezifikation" übergeben wird, ist häufig ein Rorschachtest. Jeder Analytiker liest seine eigenen Systemannahmen in die Lücken, die die Notation nicht füllt. Das Ergebnis sind Testfälle, die das mentale Modell des Analytikers testen, nicht das beabsichtigte Systemverhalten.
UML-Diagramme sind Koordinationsartefakte, keine Wahrheitsartefakte. Jedes Diagramm erfordert eine begleitende schriftliche Beschreibung, die die Entscheidungen explizit macht, die die Notation implizit lässt. Ohne die Beschreibung erzeugt formale Grammatik ein falsches Vertrauen in ein gemeinsames Verständnis.
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
Das V-Modell ordnet jeder Entwicklungsphase eine entsprechende Testphase zu. Das erweiterte V-Modell ergänzt dies durch explizite Artefaktabhängigkeiten und eine Testarchitektur-Ebene — die ingenieurwissenschaftliche Disziplin der Gestaltung des Testsystems selbst.
| Development Phase |
Test Phase |
MIM2000 Service |
| Business Requirements | Acceptance Testing | Test Analysis |
| System Requirements | System Testing | Test Analysis + Test Design |
| Architecture Design | Integrationstests | Test Design + Test Architecture |
| Detail Design | Component Testing | Test Design + Test Data |
| Implementation | Unit Testing | Test Deployment + Execution |
Entscheidungen zur Testarchitektur: Was auf welcher Ebene mit welchen Tools und welchen Daten zu testen ist — abgestimmt auf die Gesamtarchitektur des IT-Projekts. Schlüsselbereiche: Testumfang pro Ebene, Randbedingungen zwischen Teststufen, Testdatenstrategie (Live-Subset vs. gemockt vs. generiert), Umgebungstopologie, Automatisierungsgrenze.
Test Automation — Advantages and Limitations
Zuerst auf API/Service-Ebene automatisieren — der stabilste Vertrag. UI-Automatisierung nur für kritische User Journeys mit stabilen Selektoren. Niemals explorative Tests automatisieren: Der Wert liegt in der menschlichen kognitiven Auseinandersetzung. Automatisierte Tests können bestehen, während das System falsch ist, wenn Assertions oder Umfang falsch sind — falsches Vertrauen ist gefährlicher als keine Automatisierung.
→ Testing & Engineering Blog — field notes by Petr Žemla, CEO & CTO
Lösungsarchitektur
Unterstützung bei Architekturentscheidungen, Auswahl des Technologie-Stacks, Design von Integrationsmustern und Skalierbarkeitsbeurteilung. Überbrückung der Lücke zwischen Geschäftsanforderungen und technischer Implementierbarkeit.
Detailed content in preparation