Da una collaborazione con la software house svizzera Triplo M’s S.A. è nata l’esigenza di strutturare la parte di testing e di QA.
I requisiti di un progetto vanno atomizzati per garantire una migliore tracciabilità e coverage durante l’esecuzione dei test, ma come vedremo in questo articolo non solo per questo.
Questo articolo non vuole essere una spiegazione di cosa sia l’atomizzazione e di quali siano i criteri per scrivere correttamente i requisiti.
A tal proposito, infatti, c’è una letteratura cospicua e ci sono corsi ad hoc di requirement engineering che trattano approfonditamente questi argomenti, ai quali rimando chi volesse approfondire.
Senza riportare ovviamente dati sensibili descriverò il metodo da me utilizzato per costruire una specifica testabile e tracciabile.
Evidenzierò anche i benefici che ci si aspetta di avere nel prosieguo della collaborazione a seguito di tale attività.
Come si procede nel concreto
Ho scomposto ogni paragrafo della specifica fornitami in frasi singole e semplici.
I requisiti atomici sono scritti in lingua inglese ed ho utilizzato l’espressione ‘shall’ che è una convenzione di specifica per l’atomicità.
Questo rende il requisito obbligatorio e verificabile.
‘Shall’ diventa quasi una parola chiave.
Ho pensato ogni frase per descrivere un solo comportamento per requisito, ciò è necessario per garantire la testabilità.
L’emergere di comportamenti trascurati
Attenzione a non commettere l’errore di ridurre l’atomizzazione alla semplice riscrittura di un paragrafo.
Questa attività ha lo scopo di individuare anche i comportamenti nascosti e sfuggiti ad una prima stesura della specifica.
Analizzando i documenti, l’atomizzazione mi ha consentito di pensare in modo critico a funzionalità importanti che un semplice paragrafo descrittivo spesso non riesce a mettere in evidenza.
Una buona atomizzazione produce un gran numero di requisiti ovvero una quantità di testo superiore al paragrafo originario.
Un esempio
Un’applicazione, accessibile via web e tramite app, consente di controllare da remoto un impianto di condizionamento domestico.
Di seguito l’estratto della specifica da atomizzare:
“L’applicazione consente di spegnere l’impianto da remoto in qualsiasi momento. La chiusura dell’applicazione, tuttavia, non deve modificarne lo stato di funzionamento. L’applicazione deve inoltre mostrare lo stato corrente dell’impianto, anche se l’utente lo modifica in locale. Se la connessione tra l’applicazione e l’impianto è assente, per mancanza di rete o per qualsiasi altra ragione, l’applicazione deve visualizzare un apposito messaggio di avviso.”
Riporto di seguito il risultato dopo l’atomizzazione, utilizzo l’inglese per evidenziare la parola chiave ‘shall’.
Req 1 – Remote system shutdown
The user shall be able to switch off the air-conditioning system remotely at any time through the application.
Req 2 – System state preservation on application closure
Closing the application shall not change the operating state of the air-conditioning system.
Req 3 – Current system status display
The application shall display the current operating state of the air-conditioning system, including when the system state has been changed locally.
Req 4 – Connection loss warning
When the connection between the application and the air-conditioning system is unavailable, the application shall display a warning message.
Le riflessioni e l’aggiunta di altri requisiti
Alcune domande emergono, una su tutte: come può l’utente non essere tratto in inganno dallo stato mostrato dall’applicazione quando il dispositivo non è connesso anche se compare il messaggio di warning.
Un utente medio potrebbe lasciare spento l’impianto e trovare lo stato coerente sull’applicazione anche in caso di accensione in locale, con tutte le conseguenze del caso.
Espliciterei un nuovo requisito che è sotteso:
Req 5 – System status reliability during connection loss
When the connection between the application and the air-conditioning system is unavailable, the application shall indicate that the displayed system status may not reflect the current state of the system.
I benefici
Ecco il vantaggio: ogni volta che ho esplicitato un requisito, lo stesso andrà poi testato e validato con appositi test cases.
Quando ben fatta, l’atomizzazione serve proprio a sollevare open point, chiarimenti di specifica da sottoporre agli stakeholder.
Le review con gli stakeholder produrranno delle CR (change request) per rendere espliciti nuovi comportamenti non previsti oppure per cambiare i comportamenti precedenti.
Il grosso rischio è che questi comportamenti emergano poi in fase avanzata del progetto rendendo onerose le correzioni necessarie.
È un risparmio di tempo, è un risparmio di costi: è maggiore qualità.