Bridging the gap between intention and execution — from process maturity to test architecture.
Process Maturity and Result Reliability — CMMI and TMMi
Un comune malinteso nel settore posiziona Waterfall e Agile come opposti ideologici. A livello comportamentale il conflitto è reale. Ma a un livello più profondo, entrambi sono istanze di esecuzione di processo, e la qualità dei risultati di entrambi è governata dalla stessa variabile sottostante: la maturità del processo.
Capability Maturity Model Integration (CMMI) fornisce un framework per misurare e migliorare la maturità del processo organizzativo nell'intero ciclo di vita dello sviluppo software. I suoi cinque livelli di maturità — Iniziale, Gestito, Definito, Gestito quantitativamente, Ottimizzante — descrivono la traiettoria dall'esecuzione ad-hoc verso processi sistematici e auto-miglioranti.
Test Maturity Model Integration (TMMi) è il framework complementare per i processi di test. Mentre CMMI copre l'intero SDLC, TMMi applica la stessa struttura di livelli di maturità esclusivamente al testing — dallo stato iniziale (testing come ripensamento caotico) al Livello 5 (prevenzione dei difetti come obiettivo primario del testing). TMMi e CMMI sono esplicitamente progettati per essere usati insieme.
La catena causale: maturità del processo → prevedibilità del processo → affidabilità dei risultati. Per gli incarichi di advisory MIM2000, l'obiettivo CMMI/TMMi viene applicato in modo diagnostico: valutiamo dove si trovano i processi di un cliente sulla scala di maturità, identifichiamo le specifiche aree di processo che causano varianza di qualità o di pianificazione, e raccomandiamo miglioramenti mirati. L'obiettivo è la riduzione misurabile dei costi di rilavorazione, non la certificazione fine a se stessa.
References: CMMI Institute, TMMi Foundation (R1.2), ISO/IEC 15504.
UML — The Best Standard That Cannot Guarantee Understanding
Il Linguaggio di Modellazione Unificato (UML 2.x, ISO/IEC 19501) è la notazione più completa per la modellazione di sistemi software mai standardizzata — quattordici tipi di diagramma che coprono le viste strutturali, comportamentali e di interazione. Nessun'altra notazione raggiunge questa ampiezza.
Il paradosso fondamentale: UML è un linguaggio visuale formale con una grammatica definita. La conformità a tale grammatica è verificabile. La comprensione del modello trasmesso non lo è. Un diagramma di sequenza può essere sintatticamente perfetto e allo stesso tempo trasmettere a quattro lettori quattro comportamenti previsti completamente diversi. La correttezza grammaticale non garantisce il consenso semantico.
Questo ha un impatto diretto sull'analisi di test: un diagramma di sequenza UML consegnato a un analista di test come "specifica dei requisiti" è frequentemente un test di Rorschach. Ogni analista legge nelle lacune che la notazione non riempie le proprie assunzioni sul sistema. Il risultato sono casi di test che testano il modello mentale dell'analista, non il comportamento del sistema previsto.
I diagrammi UML sono artefatti di coordinamento, non artefatti di verità. Ogni diagramma richiede una narrativa scritta di accompagnamento che renda esplicite le decisioni che la notazione lascia implicite. Senza la narrativa, la grammatica formale crea una falsa fiducia nella comprensione condivisa.
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
Il modello V mappa ogni fase di sviluppo a una fase di test corrispondente. Il modello V avanzato estende questo con dipendenze esplicite degli artefatti e uno strato di Architettura di Test — la disciplina ingegneristica della progettazione del sistema di test stesso.
| Development Phase |
Test Phase |
MIM2000 Service |
| Business Requirements | Acceptance Testing | Test Analysis |
| System Requirements | System Testing | Test Analysis + Test Design |
| Architecture Design | Test di integrazione | Test Design + Test Architecture |
| Detail Design | Component Testing | Test Design + Test Data |
| Implementation | Unit Testing | Test Deployment + Execution |
Decisioni di Test Architecture: cosa testare a quale livello, con quali strumenti e con quali dati — allineati all'architettura complessiva del progetto IT. Aree chiave: ambito del test per livello, condizioni al contorno tra i livelli di test, strategia dei dati di test (sottoinsieme live vs simulati vs generati), topologia dell'ambiente, confine dell'automazione.
Test Automation — Advantages and Limitations
Automatizzare prima al livello API/servizio — il contratto più stabile. Automazione UI solo per i percorsi utente critici con selettori stabili. Non automatizzare mai il test esplorativo: il valore sta nel coinvolgimento cognitivo umano. I test automatizzati possono passare mentre il sistema è sbagliato se le assertion o l'ambito non sono corretti — la falsa fiducia è più pericolosa della mancanza di automazione.
→ Testing & Engineering Blog — field notes by Petr Žemla, CEO & CTO
Architettura della soluzione
Supporto alle decisioni architetturali, selezione del technology stack, progettazione di pattern di integrazione e valutazione della scalabilità. Colmando il divario tra requisiti aziendali e fattibilità dell'implementazione tecnica.
Detailed content in preparation