DevOps: che fine ha fatto la QA?

In merita alla relazione tra DevOps e QA (quality assurance) si trovano in rete inquietanti slogan del tipo: If you work in software quality assurance (QA), it’s time to find a new job.

L’affermazione è in parte vera ma nel senso che il modello DevOps elimina la necessità del controllo qualità come entità separata, fondendo la responsabilità per la qualità all’interno dei diversi team.

Una tale evoluzione è molto radicale, personalmente consiglio di procedere sempre per buon senso e quindi per gradi, mantenendo questa disciplina ancora in capo a strutture preposte portando però queste strutture alla partecipazione attiva negli sprint.

Ad ogni modo l’obiettivo della metodologia DevOps e nell’Agile è quello che, quando si esegue il test, ci sono poche, se non nessuna, rigide aderenze ai documenti dei requisiti e liste di controllo. L’obiettivo, invece, è quello di fare semplicemente tutto ciò che è necessario in qualsiasi momento per soddisfare le richieste del cliente, sostituendo la documentazione con riunioni Face2Face e sostituendo funzioni a silos con team di progetto unificati e auto-organizzanti. In una cultura aziendale Agile, ci si aspetta che ognuno lavori a stretto contatto, indipendentemente dal proprio ruolo, per raggiungere un unico obiettivo: un prodotto software di alta qualità che soddisfi tutte le specifiche essenziali che un cliente richiede ad ogni iterazione.

Nel cammino di adozione della metodologia DevOps gli attori che inizialmente sono segregati tra Software Developers, Testers e addetti alla Quality-Assurance sono portati ad “indossare i cappelli l’uno dell’altro” facendo decadere gradualmente le barriere fondendo in un’unico team le singole caratteristiche. È questa dimensione dinamicamente collaborativa che rende distintiva questa metodologia, con un dialogo interno continuo che porta a:

• una migliore comunicazione con i clienti e gli utenti finali;
• una migliore risposta ai requisiti di progetto in continua evoluzione;
• migliori relazioni di lavoro tra gli sviluppatori e tester;
• un prodotto software migliore e più efficiente nel complesso

Come evolvere la QA per il DevOps?

Come prima cosa non c’è un’unica risposta a questa domanda ma ci sono 4 domande a cui dare una risposta:

• 1 Cosa? quali sono le tipologie di test;
• 2 Come? quali sono gli strumenti per la gestione dei test;
• 3 Chi? anche se facilitati da team multidisciplinari definire comunque ruoli e responsabilità;
• 4 Quando? individuare fasi e ambienti su cui effettuare i test.

Anche per queste domande non c’è un’unica risposta ma ogni gruppo che si approccerà a questa metodologia dovrà trovare il proprio modello, quello che più soddisfa le proprie esigenze di prodotto. Inoltre questo modello non sarà mai definitivo ma dovrà evolvere ed essere periodicamente sottomesso a verifica come avviene per ogni sprint nel momento della retrospettiva.

1 Cosa?

Può essere una facilitazione nella definizione delle diverse tipologie di test utilizzare ilraggruppamento in White Box e Black Box Testing.

White Box Testing: sono i test condotti sul codice sorgente al fine di verificare la struttura interna dell’applicazione. Considerata la loro natura, si basano generalmente su disegni/specifiche di dettaglio e sono effettuati da parte degli stessi sviluppatori.

Black Box Testing: sono test effettuati sull’applicazione al fine di verificare che questa sia stata progettata secondo le specifiche dell’utente. Si basano pertanto sui requisiti attesi opportunamente formalizzati e sono svolti da appositi tester (anche privi di conoscenze tecniche).

Per tipologie si intendono tutte le casistiche di test, anche quelle non necessariamente legate al ciclo di vita del software. Le tipologie si suddividono in Functional Testing e Non Functional Testing.

• Functional Testing: tipologie di test volti a verificare le funzionalità dell’applicazione e, quindi, la rispondenza del codice sviluppato rispetto ai requisiti funzionali
• Non Functional Testing: tipologie di test volti a verificare aspetti del software non legati a specifiche funzionalità applicative ma piuttosto a caratteristiche quali il comportamento del sistema a fronte di determinati carichi, la rispondenza rispetto a criteri di sicurezza, ecc

2 Come?

Per rispondere a questa domanda riporto una semplice tabella da usare come guida dove indicare strumenti e responsabili\esecutori per ogni tipologia di test. Ricordo che la metodologia DevOps predilige gli automatismi questo per garantire l’elevata frequenza dei rilasci, vedi sezione Test Automation per alcuni spunti.

3 Chi?

Di seguito un esempio di definizione dei ruoli:

Di seguito l’esempio di una matrice in cui posizionare ruoli e responsabilità:

4 Quando?

Ipotizzando un’infrastruttura composta da 4 ambienti DEV (Ambiente per lo Sviluppo), SIT (Ambiente di System Integration), UAT (Ambiente per gli User Acceptance Test), PRD (Ambiente di Produzione) ecco una esempio di pianificazione dei test:

Test Automation

Il Test Automation consiste nello sviluppo di apposito software che interagisce con il software da collaudare senza bisogno dell’intervento di un operatore umano e fornisce come output un rapporto di qualità.

Per facilitare il Test Automation il modello di sviluppo software dovrebbe essere di tipo test-driven development (TDD) cioè sviluppo del software in cui la stesura dei test automatici avviene prima di quella del software. In questo modello lo sviluppo del software applicativo è orientato all’obiettivo di passare i test automatici precedentemente predisposti. Il Modello TDD prevede un ciclo di sviluppo in tre fasi:

• Fase Rossa: lo sviluppo di una nuova funzionalità comincia sempre con la stesura di un test automatico volto a validare quella funzionalità. Poiché l’implementazione non esiste ancora, la stesura del test produrrà un esito negativo.
• Fase Verde: Quando il codice è pronto vengono lanciati nuovamente tutti i test disponibili sul software modificato. In questo modo ci si rende subito conto se la nuova implementazione ha causato fallimenti di test preesistenti, ovvero ha causato regressioni nel codice. La fase verde termina quando tutti i test sono “verdi” (ovvero vengono passati con successo).
• Refactoring: Quando il software passa tutti i test viene avviata la fase di refactoring per migliorarne la struttura attraverso un procedimento basato su piccole modifiche controllate volte a eliminare o ridurre difetti oggettivamente riconoscibili nella struttura interna del codice. Esempi tipici di azioni di refactoring sono la scelta di identificatori più espressivi, eliminazione di codice duplicato, semplificazione e razionalizzazione del sorgente ecc. L’obiettivo del refactoring non è quello di ottenere del codice “perfetto”, ma quello di migliorarne la struttura, secondo la cosiddetta “regola dei Boy Scout”: “lascia l’area dove ti sei accampato più pulita di come l’hai trovata“. Dopo ciascuna azione di refactoring, i test automatici vengono nuovamente eseguiti per accertarsi che le modifiche eseguite non abbiano introdotto regressioni.

Ci sono due principali approcci per la costruzione dei test automatici:

• Graphical user interface testing: Costruzione di un framework di test che genera eventi dell’interfaccia utente come sequenze di tasti e clic del mouse e osserva le modifiche che risultano nell’interfaccia utente, per verificare che il comportamento osservabile del programma sia corretto.
• API driven testing: Un framework di test che utilizza un’interfaccia di programmazione per l’applicazione per convalidare il comportamento sotto test. In genere, i test basati su API bypassano completamente l’interfaccia utente dell’applicazione. Può anche essere testare interfacce pubbliche (di solito) per classi, moduli o librerie che vengono testati con una varietà di argomenti di input per verificare che i risultati restituiti siano corretti.

Conclusioni

Sebbene apparentemente più complessi gli step per avviare la metodologia DevOps rispetto alle metodologie tradizionali, una volta implementata con successo, porta rapidamente a una maggiore semplicità, liberando il potenziale creativo e l’efficienza dei team in modo sequenziale, lineare e addirittura più rigoroso rispetto agli approcci procedurali e da manuale che raramente sono interamente adottati e che difficilmente perdurano nel tempo.

Agile, come suggerisce il nome, si propone semplicemente di essere un modo più rapido, più prioritario e orientato al rischio e più flessibile, adattabile ed efficiente per condurre il complicato business della produzione di software. Tutto questo mai a discapito della qualità anzi con l’obiettivo di un prodotto software migliore e più efficiente nel complesso la qualità è uno dei primari obiettivi da soddisfare.

Critiche

“Per tutti i suoi sostenitori”, scrive Mike Brown di uTest, “Agile ha la sua giusta dose di scettici e detrattori. Queste sono persone che hanno un’esperienza Agile molto diversa, una caratterizzata da processi caotici, bassa qualità, problemi di comunicazione e numerosi altri problemi“.

…e quei critici non sono in minoranza!

Nel 2012, Max Smolaks di TechWeek Europe, riferendo sulla ricerca condotta da Voke Media per determinare quali 200 diverse società di software hanno pensato al loro tentativo di abbracciare Agile, ha scritto:

Su oltre 200 partecipanti:

• il 64% ha dichiarato che passare a Agile Development è stato più difficile di quanto inizialmente sembrasse;
• Il 40% degli intervistati non ha identificato un ovvio beneficio per la pratica.

Questi risultati suggeriscono fortemente che per le organizzazioni trincerate in anni di pratiche lavorative non Agili, rendere il passaggio può essere difficile, se non controproducente, come spiega Scott Barber di SmartBear:
Credo che la tendenza al “andare Agile” sia fuorviata. Se un’azienda sta sviluppando un buon software, le persone coinvolte nello sviluppo di quel software sono felici di lavorare lì, lo sviluppo del software è sostenibile e il business viene adeguatamente servito da quel software, non c’è davvero bisogno che provino a essere più o meno Agile. Agile ha sfide come qualsiasi altra cultura, ma la più grande sfida che trovo sono le aziende che cercano di risolvere problemi di sviluppo, processo, gestione e/o pianificazione andando Agile. Teams cresciuti in una cultura che è fondamentalmente diversa da Agile semplicemente non troverà facile “andare Agile”.

In altre parole, le aziende che si aspettano che Agile sia una bacchetta magica per risolvere qualunque problema possano restare seriamente deluse, poiché questa evoluzione richiede un cambiamento culturale più sistemico del semplice abbraccio di una nuova serie di strumenti e procedure.

Naturalmente, i sostenitori di Agile suggeriscono che praticamente tutti i problemi, i reclami e le esperienze negative che le aziende che tentano di usare Agile hanno segnalato non sono dovute a un problema con Agile stesso, ma ad una mancata comprensione dell’approccio e dei suoi limiti. Altri, come lo stratega della tecnologia Lajos Moczar, sostengono di comprendere pienamente Agile e tuttavia sostengono che i suoi principi guida sono imperfetti.

Mio personale suggerimento è che quando tutto sta cambiando così velocemente, è semplicemente necessaria una certa agilità.