Guida definitiva al continuous testing - ca.com · a coprire l'intero ciclo di sviluppo del...

Guida definitiva al continuous testing2018

Come completare con successo il percorso verso il continuous testing

Mentre il ritmo del business continua ad accelerare, le aziende stanno iniziando a capire che, per mantenersi competitive, devono modificare il processo di sviluppo e rilascio del software. La frequenza delle release è notevolmente aumentata. Un ciclo di 6-18 mesi per l'individuazione e la correzione dei bug, che il cliente un tempo trovava accettabile, oggi non è più ammissibile. Tutto deve essere più veloce e deve essere pronto e perfetto in tempi più brevi.

Siamo di fronte a un'inversione di tendenza, in cui la responsabilità del testing viene anticipata per avvicinarla all'inizio del ciclo di sviluppo del software, per poi seguirlo fino alla fine. Questo approccio sta abbattendo le barriere che separano da sempre sviluppatori e tester, in un processo in cui la qualità è una responsabilità di tutti. Il testing è diventato irrinunciabile, perché le conseguenze di un testing inaccurato oggi sono molto più visibili.

È un cambiamento tecnico che impone un cambiamento culturale. A mano a mano che il testing si evolve fino a coprire l'intero ciclo di sviluppo del software, le aziende e i relativi reparti IT devono trovare una soluzione per cambiare le modalità di sviluppo e test del software.

In pratica: dobbiamo smettere di vedere il testing come un evento. Non è un processo da eseguire in un momento specifico, ma un'attività che tutti devono svolgere continuamente, anche prima dell'inizio dello sviluppo. Difetti e problemi devono essere eliminati sul nascere, non cercati o ignorati fino a quando il prodotto non arriva sul PC del cliente.

La metodologia DevOps si prefigge proprio l'obiettivo di abbattere queste barriere fra sviluppo e operations al fine di garantire che il software, auspicabilmente realizzato con la metodologia Agile, possa essere distribuito agli utenti appena pronto, senza sacrificare la qualità. Ma anche negli ambienti che adottano DevOps, le aziende sono ancora costrette a scendere a compromessi fra qualità e velocità.

Nella cultura di testing attuale, il 63% dei ritardi nello sviluppo del software si verifica nella fase di test-QA del ciclo di vita e il 70% dei test viene ancora eseguito manualmente. Ma oggi non possiamo più permettercelo. Non ci si può più limitare a eseguire i test manualmente e ci sono anche altri problemi da considerare:

Gli errori, soprattutto quelli che arrivano fino al pubblico, danneggiano i dati, i processi di business, l'adozione da parte dei clienti, la fidelizzazione e il brand. Con i vecchi processi waterfall, e nemmeno con i processi Agile, non è possibile analizzare a fondo il software garantendo al tempo stesso velocità e qualità.

CAPITOLO 1

Il 56%

Il 50%

Il 64%

delle dipendenze critiche non è disponibile

del tempo viene dedicato alla ricerca dei dati di test

dei difetti è riconducibile alla fase di definizione dei requisiti

01Guida definitiva al continuous testing |

Occorre una soluzione più esaustiva, dinamica e fluida per garantire la qualità intrinseca del software sviluppato e distribuito, rilevando gli errori fin dall'inizio, anziché affidandosi a una verifica eseguita alla fine del ciclo di vita. Proprio per questo, dobbiamo intraprendere un percorso di continuous testing.

CHE COS'È IL PERCORSO VERSO IL CONTINUOUS TESTING?


Il continuous testing è una pratica che prevede l'esecuzione di test in ogni singola attività del ciclo di sviluppo del software, per scoprire e correggere i comportamenti imprevisti appena si manifestano.

Il continuous testing impone l'integrazione del testing come aspetto fondamentale e ordinario di ogni singola attività lungo il ciclo di vita di un'applicazione, dalla definizione dei requisiti alla produzione, per garantire la generazione del valore di business previsto.

La vita non è mai stata facile per l'IT. È un dipartimento pieno di artigiani e tecnici dedicati, che fanno tutto il possibile per sviluppare e realizzare un prodotto conforme alle specifiche, ma tali specifiche non sempre rispecchiano le aspettative e le limitazioni degli utenti finali. Il ruolo del software è cambiato. I prodotti devono essere accessibili su una vasta gamma di piattaforme e devono offrire una serie di servizi in continua evoluzione.

Se le persone responsabili di testare, sviluppare e definire i requisiti del software vengono tenute separate, la qualità ne soffre. L'IT non deve essere più visto come un'attività di back-office, ma deve occupare il posto che gli spetta nel processo decisionale.

La qualità soffre anche quando vengono imposte scadenze non realistiche e quando le funzioni vengono introdotte in una release senza utilizzare metriche adeguate per valutarne la qualità.

Il testing viene da sempre eseguito a compartimenti stagni, determinando livelli di affidabilità deludenti. I tester e il business si chiedono: "Qual è il livello di efficacia delle mie procedure di testing? Qual è il livello di copertura funzionale del testing? Il testing offre anche una copertura funzionale, oltre a quella del codice? Quali sono i criteri di accettazione? I test che eseguo sono veramente efficaci, da questo punto di vista?" Molti tester non lo sanno.

Per garantire qualità e velocità allo stesso tempo, i tester devono cercare di eseguire moltissimi test a livello di unità, qualcuno meno a livello di API e un numero ancora più limitato a livello di interfaccia utente. In pratica, il testing deve essere un'attività parallela o simultanea (test di funzioni, performance e sicurezza nello stesso tempo), pertanto deve essere anticipata per garantire che venga eseguita in modo continuativo fin dall'inizio del ciclo di vita.

Troppo spesso il personale perde tempo con attività prive di valore, testando le aree sbagliate o il set sbagliato. Un team di otto persone può anche sentirsi "grande", ma in genere è necessario ri-testare e correggere il 40% del lavoro e questo significa che un team di otto persone fa il lavoro di quattro, spesso con due mesi di ritardo. Occorre eseguire un'analisi del flusso di valore per assicurare la corretta esecuzione del testing. L'analisi del flusso di valore è un metodo per analizzare i processi correnti e identificare soluzioni più efficaci ed efficienti, applicando un'ideologia di gestione lean.

CAPITOLO 2 OSTACOLI AL RAGGIUNGIMENTO DELLA QUALITÀ


MENO TEST

UI

PIRAMIDE DI AUTOMAZIONE DEI TEST

Automazione a livello di unità

API Testing

La maggior parte delle aziende utilizza strumenti "legacy", che potevano bastare per i metodi waterfall ma non risultano abbastanza efficaci quando si anticipa il testing. Questi strumenti ostacolano l'esecuzione dei test alla velocità di Agile. Tali strumenti non supportano l'automazione nel modo appropriato a un ambiente di integrazione continua, pertanto gli sviluppatori si rifiutano di usarli. Occorre una nuova serie di strumenti che non ostacolino il raggiungimento degli obiettivi di velocità e qualità, strumenti che consentano di integrare la qualità direttamente nel processo, anziché limitarsi a collaudare l'applicazione, come avveniva in passato.

Ma oltre a modificare le tecniche di automazione del testing, è necessario migliorare anche il processo di definizione dei requisiti, che devono essere privi di ambiguità, completi e verificabili.

Molto spesso i requisiti vengono specificati ad alto livello. Questo può essere sufficiente per gli sviluppatori e i tester più esperti in materia, che possiedono le competenze necessarie per interpretarli e colmare le lacune. Tuttavia, i membri del team possono interpretare la stessa cosa in modo diverso, introducendo difetti nel ciclo di vita prima ancora di scrivere una singola riga di codice. Viceversa, i requisiti possono anche essere specificati in modo estremamente dettagliato, arrivando a riempire varie decine di pagine. In questo caso la definizione dei requisiti richiede troppo tempo e con il tempo l'aggiornamento diventa estremamente complicato. Per non parlare del fatto che sviluppatori e tester faticano a cogliere il senso di un tale volume di informazioni presentato come un singolo, enorme requisito. Occorre trovare una soluzione migliore per specificare i requisiti, su misura per i team Agile che adottano DevOps.

Anche il controllo qualità deve essere affrontato diversamente. Deve partire dai senior leader, i quali devono prestare attenzione anche alla qualità, oltre che alla delivery, perché oggi la delivery include tutta l'esperienza dell'utente o del cliente e non si limita al semplice deployment o rilascio del software. In questo modo è possibile creare i presupposti per fornire un set di requisiti che consenta a sviluppatori e tester di comprendere quello che stanno realizzando. Oggi, con release di frequenza mensile, è fondamentale disporre di un ciclo di feedback efficiente. Il QA non deve più essere visto, né comportarsi, come un cittadino di serie B solo perché, fino ad oggi, è sempre stato identificato come una proprietà condivisa tra più servizi.

Questo cambiamento è possibile solo se supportato da cambiamenti culturali e organizzativi. Il problema è più umano che tecnico, ma risolverlo è fondamentale per concludere con successo il percorso di continuous testing. Non tutti sono in grado di gestire i cambiamenti tecnologici o a livello di processo, come il continuous testing o l'anticipazione dei test. Questo cambiamento spaventa anche i Center of Excellence (CoE), perché i tester si domandano come possono affidare il "testing" a personale non specializzato.

Proprio per questo, il "Center of Excellence" (CoE) deve trasformarsi in un "Center of Enablement" (CoE). Queste due strutture devono assumersi la responsabilità di eseguire i test lungo l'intero ciclo di sviluppo del software, devono conoscere i processi appropriati e devono disporre degli strumenti necessari per semplificarli, grazie all'assistenza dei tester più esperti e competenti. Occorre anche il supporto della gestione del cambiamento, sia dall'alto verso il basso che dal basso verso l'alto.

Così come si anticipa il testing, occorre fare lo stesso anche per sicurezza e performance. Questi aspetti non devono più essere considerati "non funzionali", ma devono essere trattati esattamente come il testing funzionale. Il testing

Attualmente, il 64% dei difetti è riconducibile alla fase di definizione dei requisiti.


della sicurezza attualmente eseguito prima del deployment in produzione è inadeguato ed è arrivato il momento di trattare la sicurezza come un cittadino di serie A, integrando pratiche di testing specializzate nel processo di continuous testing.

Una volta che l'applicazione è in produzione, ci si può accorgere che non funziona correttamente nelle condizioni di traffico reali. Per risolvere rapidamente il problema si può provare ad aumentare la potenza, ma questo è possibile solo in un'infrastruttura basata su cloud. Occorre pertanto assicurarsi che le performance delle app vengano testate prima del passaggio in produzione, iniziando dall'estrema sinistra, a livello di unità da parte degli sviluppatori, e quindi aumentare incrementalmente l'ambito dei test di performance a mano a mano che le unità di codice iniziano a formare componenti più grandi che danno vita a story, funzioni ed epic, sempre avvalendosi dei test di performance più limitati creati in precedenza. A tale scopo, le aziende devono garantire la disponibilità di strumenti e processi adeguati.

Un cambiamento culturale impone iniziative di cambiamento top-down e bottom-up accompagnate da una leadership efficace. Nel complesso, occorre instaurare una cultura di continuous testing. Executive e IT manager devono parlare a tester e sviluppatori, e concentrarsi sulla stesura di un piano congiunto. È necessario coinvolgere queste persone affinché diventino parte integrante della soluzione. Devono avere la possibilità di sbagliare e imparare dai propri errori.


CAPITOLO 3 IN COSA CONSISTE IL CONTINUOUS TESTING

Tutte le persone che partecipano al continuous testing scrivono codice ed eseguono test. Tutti i membri del team hanno la responsabilità, singolarmente e collettivamente, di progettare e fornire software di alta qualità. Questo sottolinea l'evoluzione dai metodi waterfall all'approccio water-scrum-fall, fino ad Agile e alla combinazione di Agile e DevOps con la business agility, attraverso il continuous testing.

La responsabilità collettiva impone l'analisi retrospettiva, allo scopo di esaminare e adattare il processo e i suoi risultati, ridefinendo il concetto stesso di "prodotto finito". Per diffondere una mentalità di continuous testing occorre fornire un feedback tempestivo agli sviluppatori, affinché siano sicuri che il codice funzioni e possano procedere speditamente lungo la pipeline di release. È necessario creare o trovare i dati da utilizzare in tutti i cicli di test funzionale e non funzionale, prima e dopo il passaggio in produzione.

Il continuous testing è costituito da tra elementi chiave:

L'azienda deve assicurarsi che tutti abbiano chiaramente compreso la definizione di continuous testing. Si tratta di un concetto relativamente nuovo e, come molte altre aree dello sviluppo software, definizioni e procedure possono variare.

È una sorta di catena di montaggio automatizzata per il software, che prevede test in ogni singola fase, a partire dalla raccolta dei requisiti, che viene attivata automaticamente dal primo check-in del codice, e in seguito per tutte le fasi fino al passaggio in produzione. Sono inclusi tutti gli aspetti del testing lungo l'intero percorso, fino ai test di integrazione e performance e quindi al monitoraggio in produzione. Il continuous testing deve essere un regime di test efficace ed efficiente, incentrato sull'applicazione e con un ambito end-to-end che include CI, CD e produzione. L'obiettivo è raggiungere i massimi livelli di efficienza umanamente possibili per implementare i cambiamenti in produzione con il minimo lead time e con la massima qualità, assicurando una customer experience eccellente.

Il continuous testing è una pratica che prevede l'esecuzione di test in ogni singola attività del ciclo di sviluppo del software, per scoprire e correggere i comportamenti imprevisti appena si manifestano.

Occorre fornire capacità di testing agli sviluppatori. Sviluppatori e team Agile devono comprendere che il testing è anche una loro responsabilità.

Occorre un'automazione totale.

È necessario fornire soluzioni di testing che gli sviluppatori siano disposti a utilizzare. Questo significa open source "come codice" nel cloud.

PERSONE

PROCESSI

TECNOLOGIA


CAPITOLO 4 DISCIPLINE COINVOLTE NEL CONTINUOUS TESTING

Per accelerare e migliorare il processo di release del codice attraverso il continuous testing occorre una serie di discipline che consentano alla qualità di evolversi di pari passo. Per incorporare la qualità nelle applicazioni, i team devono inserire procedure di testing più moderne sotto forma di brevi controlli di qualità da eseguire lungo l'intera pipeline applicativa. Questo permette di testare continuativamente piccole sezioni di codice.

L'automazione dei test non è sempre il primo problema da affrontare. Poiché persino i test di API e GUI sono automatizzati e integrati in un agente di integrazione continua, prima di eseguirli è necessario soddisfare dipendenze quali dati, interfacce e ambienti di test. È necessario:

• Eliminare tutti i vincoli ambientali e lasciare sviluppatori e tester liberi di dedicarsi alle proprie mansioni, anche manualmente. Virtualizzare tutte le interfacce, di qualsiasi tipo, che non rientrano nelle responsabilità e nel controllo del team o che non si desidera testare.

• Utilizzare ambienti di testing temporanei.

• Automatizzare il provisioning e la gestione dei dati di test da fornire on-demand ai test automatici o manuali.

• Automatizzare i test di modo che possano essere eseguiti sulle interfacce virtualizzate utilizzando i dati di test appropriati.

• Configurare il motore di orchestrazione della pipeline in modo da eseguire i precedenti passaggi senza richiedere alcun intervento manuale.

• A questo punto, occorre concentrarsi sulle discipline complementari.

1. AMBIENTI VIRTUALIZZATI Il continuous testing implica un aumento della frequenza dei test. Questo significa che occorre testare più

ambienti con una frequenza superiore. Ma se questi ambienti non sono costantemente disponibili, questo può determinare la formazione di un collo di bottiglia. Alcuni ambienti sono accessibili tramite API, altri utilizzando varie interfacce di messaggistica. Tali ambienti possono presentare architetture moderne o essere costituiti da vecchie strutture client/server monolitiche o da sistemi mainframe. Ma come si può coordinare il testing fra più ambienti con proprietari diversi, che non sempre li mantengono operativi ai fini dei test? Virtualizzando questi ambienti è possibile testare il codice senza preoccuparsi delle aree che rimangono invariate (ovvero, altri ambienti e sistemi). Realizzando ambienti temporanei, disponibili on-demand attraverso la virtualizzazione, è possibile rimuovere questa limitazione dal ciclo di sviluppo, perché sono sempre disponibili. Puoi controllarli e alternarli come necessario.

2. TEST DATA MANAGEMENT Occorre avere a disposizione i dati appropriati, con il giusto livello di diversificazione, per riprodurre scenari sia positivi che negativi. Questa diversificazione non è facile da trovare nell'ambiente di produzione, e questo aspetto riveste un'importanza critica. La generazione di dati sintetici consente pertanto di implementare il continuous testing con l'assoluta certezza di non esporre i dati personali ad alcuni rischio. Inoltre, non sarebbe possibile estrarre i dati dall'ambiente di produzione, condizionarli e fornirli con la velocità richiesta dalla pipeline applicativa.

3. AUTOMAZIONE DEI TEST In una pipeline applicativa completamente orchestrata, gli script attuali non funzionano a causa di elementi non

correlati al codice dell'applicazione, impedendo di ottenere risultati attendibili. Per implementare il continuous testing è necessario automatizzare i test in modo affidabile.

LE 11 DISCIPLINE DEL CONTINUOUS TESTING


4. ORCHESTRAZIONE DELLA PIPELINE Costituisce la spina dorsale dell'intero processo. È l'elemento che collega tutto e deve essere integrato con la suite

di automazione. Devi comprendere come funziona, come interpretare i risultati e come renderla scalabile. Questo consente di configurare il continuous testing in modo tale da integrarne gli attributi all'interno della pipeline. Assicurati che sia trasparente e che tutti dispongano di visibilità completa sui componenti eseguiti all'interno della pipeline. Si tratta di uno strumento automatizzato per la gestione del workflow, che esegue tutti i test automatizzati e si integra completamente con le attività di deployment del codice a mano a mano che avanza lungo la pipeline. In qualsiasi iniziativa di adozione di DevOps, non è realistico aspettarsi di implementare il continuous testing senza l'affidabilità e la velocità garantite da una pipeline automatizzata e standardizzata.

5. TESTING DELLE API Garantisce l'allineamento della piramide di testing. L'azienda dovrebbe fare tutto il possibile per testare soprattutto

a livello di unità e API, riducendo al minimo la dipendenza dai test dell'interfaccia utente. Per implementare il continuous testing è necessario comprendere correttamente il concetto di piramide di test, intensificare il testing di unità e API e limitare la dipendenza dai test dell'interfaccia utente, soprattutto per il testing della logica di business.

6. TEST DI CARICO E PERFORMANCE Anche se l'applicazione è corretta dal punto di vista funzionale, devi cambiare radicalmente il tuo concetto di

testing delle performance. Anticipando il testing, si anticipa l'esecuzione dei test nel ciclo di vita, riducendo il numero di componenti di applicazioni e infrastruttura, pertanto i test presentano un ambito intrinsecamente più limitato. Il volume risulta tuttavia superiore. Estendi l'accesso a questa capacità a tutti i membri del team Agile. In questo modo, tutti gli sviluppatori e i tester saranno in grado di creare ed eseguire autonomamente un test di performance, senza inviare richieste a nessuno.

7. TESTING DELLA SICUREZZA Gli sviluppatori devono comprendere chiaramente quale deve essere lo stato del codice affinché possa essere

lanciato. Devono ricevere una formazione appropriata e disporre della strumentazione necessaria per misurare il livello di sicurezza del codice. Gli sviluppatori devono ricevere una formazione continua, perché il campo della sicurezza applicativa è in continua evoluzione. La pipeline applicativa deve essere configurata in modo da eseguire automaticamente analisi statiche, analisi dinamiche e analisi di composizione del software, al fine di identificare ed evidenziare tutti i problemi di sicurezza e utilizzarli come opportunità di crescita per gli sviluppatori. Il testing della sicurezza deve essere eseguito in ogni fase del ciclo di vita.

8. ACCETTAZIONE DELLO SVILUPPO BASATO SUI TEST E DELLO SVILUPPO BASATO SUL COMPORTAMENTO Utilizza i criteri di accettazione di ogni singola user story per creare i test che consentono di verificarne il rispetto. In questo modo il testing rimane incentrato sugli sprint e gli sviluppatori hanno la certezza di soddisfare le aspettative del business. Con il tempo, i team imparano a definire criteri di accettazione più dettagliati e questo richiede l'esecuzione di test più esaustivi.

9. GENERAZIONE DI TEST AUTOMATIZZATI Le attività manuali di progettazione e scrittura dei test manuali o degli script per i test automatizzati costituiscono

un collo di bottiglia. Genera automaticamente i nuovi test di accettazione per il testing automatico e manuale fin dall'inizio dello sprint. In questo modo, appena gli sviluppatori iniziano a eseguire il check-in e a combinare i vari componenti di lavoro del codice, è possibile avviare l'esecuzione automatica dei test. Ciò consente agli sviluppatori di ricevere un feedback immediato sulla qualità del codice, a mano a mano che eseguono il check-in nel sistema di controllo del codice sorgente.

10. PROGETTAZIONE DEI REQUISITI Tutte le parti interessate al ciclo di sviluppo del software devono essere coinvolte nel percorso di continuous testing.

A tale scopo, è necessario trovare una soluzione ottimale per comunicare i requisiti e collaborare alla loro definizione. Prima si include la progettazione dei requisiti nell'iniziativa di continuous testing, più lineare sarà il percorso di continuous testing, perché tutti i membri del team potranno contare sullo stesso livello di comprensione fin dall'inizio.

11. CICLI DI FEEDBACK Sono essenziali per garantire il successo del continuous testing. I dashboard in tempo reale devono essere automatici e accessibili a tutti i membri del team. È necessario utilizzare i cicli di feedback nell'intero ciclo di sviluppo del software, non solo in produzione, come cartina al tornasole per analizzare la trasformazione del continuous testing.


Diffondere una cultura di continuous testing è fondamentale ai fini della metodologia DevOps, ma richiede impegno per sviluppare nuove pratiche e competenze. A tale scopo sono necessarie persone dotate di esperienza, ma anche di solide conoscenze teoriche e pratiche. L'urgenza di questo tipo di iniziative di miglioramento è giustificata dal fatto che i clienti, sia nel settore retail che nel settore B2B, manifestano chiaramente una scarsa tolleranza alle esperienze di basso livello, e questo influisce in modo estremamente rapido e visibile sulle possibilità di successo dell'azienda.

Alcune di queste nuove pratiche potrebbero contrapporsi alla cultura attuale, ma questo fa parte del concetto stesso di cambiamento e innovazione. I membri del team devono essere istruiti sulle nuove pratiche e ricevere formazione o assistenza nella gestione della transizione.

Ad esempio, quando si crea il codice di una funzionalità, è necessario incorporare le note sulla release direttamente nel codice, affinché tutti abbiano la possibilità di leggerle. Come avviene con la gestione dei progetti, occorre creare un piano efficace al punto da consentire ad altri di subentrare quando necessario.

Il controllo qualità (QA, Quality Assurance) dovrebbe evolversi in progettazione della qualità, come Center of Enablement. Questo consente ai team di integrare nel software le competenze necessarie per eseguire autonomamente tutte le attività di test, deployment, monitoraggio e persino autoriparazione, affinché i team applicativi possano utilizzarle nei propri Scrum senza dipendere dal personale esterno.

Tutto deve essere gestito come codice, affinché possa essere controllato attraverso la CI con modalità standard e scalabili. Questo impone ai team di pensare a come si svolgeranno i test al fine di garantire che, se il codice deve essere integrato nel repository del codice sorgente, si comporterà esattamente come previsto e non provocherà effetti avversi in altre aree dell'applicazione.

Tutte le persone coinvolte, ovvero sviluppatori e tester, devono diventare parte integrante di questa nuova cultura. È necessario prevedere un reparto DevOps con il compito preciso di assumere e fidelizzare dipendenti disposti a sviluppare e affinare le proprie competenze tecniche per diventare in grado di svolgere varie mansioni. A tale scopo potrebbe essere necessario creare un'organizzazione a matrice che permetta al team di sviluppo delle app di assumere o utilizzare personale specializzato nel momento in cui è necessario. Con gli esseri umani, la gestione del cambiamento è essenziale quanto la trasformazione fisica per il continuous testing.

Per quanto riguarda la piattaforma, il cloud svolge un ruolo determinante per il successo. Non è possibile seguire un percorso di continuous testing utilizzando solo sistemi on-premise e legacy.

CAPITOLO 5 ACCELERARE LE CURVE DI APPRENDIMENTO

CONTROLLO QUALITÀ

PROGETTAZIONE DELLA QUALITÀ

CENTER OF ENABLEMENT


All'inizio del percorso di continuous testing, arriva il momento in cui responsabili e parti interessate devono chiedersi a che punto sono nella timeline di deployment. È fondamentale comprendere l'imperativo del continuous testing e definirlo adeguatamente ma, in vista del lancio, occorre anche chiedersi dove si trova il team.

A questo punto è possibile adottare alcune nuove tecniche, ma anche identificare ed eliminare gli ostacoli lungo il cammino.

1. MIGLIORARE I RAPPORTI FRA TESTER E SINGOLI SVILUPPATORI Utilizza team di piccole dimensioni, promuovi la collaborazione all'interno del team e semplifica l'accesso e la

condivisione dei report online.

2. ATTRIBUIRE LA MASSIMA PRIORITÀ ALL'AUTOMAZIONE Non eliminare completamente le attività di test manuali, ma adotta un approccio che privilegi l'automazione.

Concentrati sulle aree da eseguire ripetutamente. In pratica, devi preparare prima l'impianto idraulico, affinché in seguito l'acqua possa scorrere senza problemi di perdite. Prepara una mappa del ciclo di sviluppo del software e identifica le opportunità di automazione.

3. PROCEDERE PER PICCOLI PASSI Suddividi il lavoro in piccoli incrementi, facili da testare dopo la progettazione e la scrittura del codice. Questo

semplifica sia l'automazione dei test, sia il deployment dei componenti.

4. TENERE TRACCIA DI TUTTI GLI ASPETTI Usa le metriche e definisci i criteri di superamento e fallimento. Il continuous testing ha lo scopo preciso di

determinare immediatamente se i componenti funzionano o meno, pertanto assicurati che possa essere predisposto facilmente.

5. SCEGLIERE GLI STRUMENTI APPROPRIATI PER IL CONTINUOUS TESTING Trova gli strumenti che possono aiutarti a svolgere continuativamente le attività di sviluppo, test e analisi. Scegli strumenti all'avanguardia, che si integrano in modo tale da essere facilmente incorporati nell'ambiente di lavoro. Scegli strumenti che possano contare sul supporto di una community, in cui tutti parlano dei propri problemi, soluzioni e scenari di utilizzo interessanti.

6. SVILUPPARE UN SISTEMA PER ESPORRE I RISULTATI Devi analizzare a fondo i risultati, perché solo così saprai se il codice funziona e dove si trovano le lacune.

Definisci gli indicatori KPI e i criteri di accettazione, quindi rendili quantificabili. Crea dashboard per tenere traccia degli indicatori KPI, includendo una baseline e le modifiche successive.

CAPITOLO 6 COME DETERMINARE LA PROPRIA POSIZIONE LUNGO IL PERCORSO DI CONTINUOUS TESTING

• Mettere sempre il cliente al centro del processo di cambiamento e delle attività di continuous testing che ne derivano • Stabilire come misurare adeguatamente la qualità.

DUE PUNTI CRITICI DA RICORDARE IN QUESTA FASE

TECNICHE DA ADOTTARE


La transizione al continuous testing può sembrare difficile, ma è preferibile cominciare con un piccolo progetto, portarlo al successo e quindi utilizzarlo come base per creare altri piccoli progetti. Si tratta di un processo iterativo, in cui occorre raggiungere obiettivi modesti per poi continuare a costruire, al fine di accumulare slancio e competenze.

Gli errori capitano. Quando questo succede, team e responsabili devono essere pronti a limitare i danni e prepararsi alle conseguenze (fail forward), quindi imparare dalla propria esperienza.

La dimostrazione di responsabilità dei senior leader nei confronti dell'azienda può fare un'enorme differenza. Un singolo evangelista può entrare in contatto solo con il 20-30% della popolazione. Per il resto dell'azienda, spetta alla leadership definire le aspettative e mantenersi sulle retta via.

La transizione al continuous testing è piena di ostacoli, che devono essere identificati uno per uno. Tali problemi possono includere l'incapacità di accedere all'open source e utilizzarlo. La cultura aziendale, che oltre alle persone include anche le procedure, potrebbe non essere ancora pronta. Il tempo a disposizione potrebbe non essere sufficiente per iniziare l'implementazione, la formazione e la transizione al continuous testing. A questo potrebbero aggiungersi una leadership inefficiente e la presenza di applicazioni legacy.

In questa fase, il vero obiettivo consiste nello sviluppare e implementare un maturity model del continuous testing. Questo richiede la diffusione di una mentalità appropriata in termini di atteggiamento e preparazione. Predisponi l'automazione dei test a livello di unità e API per il testing della sicurezza, delle funzioni e delle performance e mantieni al minimo l'automazione dei test a livello di interfaccia utente, perché gli script non sono in grado di tenere il passo con l'evoluzione della UI. Nell'ambito della pipeline, aggiungi un ciclo di feedback che includa strumenti per il monitoraggio di performance e utenti negli ambienti di pre-produzione. La telemetria completa accelera la correzione dei difetti.

Tutte queste funzionalità devono essere completamente integrate e collaborative, e non devono presentare alcun tipo di compartimentazione. Le aziende devono essere in grado di accettare e comprendere l'open source, poiché consente di sperimentare e "fallire più in fretta", senza essere costretti a giustificare le spese. Devono inoltre garantire un accesso adeguato ai dati di test, che costituisce uno dei principali ostacoli al completamento.


Ogni progetto ha bisogno di metriche per determinare lo stato di avanzamento e il livello di qualità, oltre che per identificare il valore di business. E questo vale anche per il continuous testing. In effetti, il continuous testing è una sorta di convalida continua, perché è necessario verificare continuamente se l'app o il servizio fornirà (o sta già fornendo) il valore di business previsto. Alcuni dei benchmark più completi includono l'adozione da parte del cliente, l'interazione e il profitto. I team devono trovare il modo di comprendere e quantificare i sentimenti degli utenti finali, per aggiungerli al ciclo di feedback continuo da restituire a sviluppatori e business.

Devi anche riuscire a tracciare il numero dei problemi riscontrati, il numero dei difetti nelle fasi di pre-produzione e produzione, quindi utilizzare questi dati per determinare la potenziale velocità di deployment. A mano a mano che la qualità del codice migliora, il numero dei difetti deve diminuire in proporzione a fronte di una cadenza di release costante o, meglio ancora, in aumento.

Considera la copertura del codice e la copertura richiesta (copertura funzionale) e combina questi dati per tenere traccia della copertura complessiva a livello di funzionalità.

Assicurati di aver chiaramente compreso il significato del termine "qualità" per la tua azienda e definisci una baseline. Se non sai da dove parti, non puoi capire se stai migliorando. Utilizza un indicatore KPI che definisca la qualità della produzione.

Determina il tipo di copertura necessario per unit test e test funzionali, oltre che per sicurezza e performance. Non devi più ragionare in termini di testing funzionale e non funzionale.

Misura il tempo complessivo fino al passaggio in produzione. Lo scopo del continuous testing consiste nel ridurre le tempistiche per garantire release di qualità superiore, che forniscono valore di business. Concentrati sull'aumento delle release, mentre il numero dei difetti di produzione diminuisce, e riduci il time-to-market grazie all'automazione.

Aiuta il personale ad andare oltre il concetto di successo e fallimento, sviluppando una definizione comune di prodotto finito. È necessario tenere traccia dei difetti al fine di utilizzare l'analisi come spunto per il miglioramento.

Per misurare il successo del continuous testing, puoi eseguire i test negli ambienti di test inferiori, che sono più limitati e pertanto più rapidi. Ricorda che il testing può tenere il passo con lo sviluppo e che puoi rilasciare il codice in qualsiasi momento, non solo alla fine dello sprint.

Quando valuti e misuri la qualità in funzione della quantità, tieni conto di quanto segue:

CAPITOLO 7 METRICHE

TIME-TO-MARKET

TEMPISTICHE E COSTO DI ESECUZIONE DEI TEST MANUALI

TEST DI REGRESSIONE

ANALISI DEL FLUSSO DI VALORE


Inizia l'anticipazione del testing dagli sviluppatori, estendendo a tutti l'accesso agli strumenti di testing e trasformando i tester in ingegneri.

Ogni leader può e deve avere una propria opinione sulle metriche più importanti per il continuous testing. In teoria, le metriche da tracciare includono:

Quando si passa dall'approccio waterfall ad Agile, l'adozione richiede una maggiore efficienza di testing, che in teoria può essere ottenuta grazie all'automazione e all'anticipazione del testing. Mentre si prosegue verso cicli di release sempre più brevi nel percorso di continuous testing, aumentare l'automazione e anticipare il testing non basta: occorre rivedere completamente la metodologia di test.

Questo richiede competenze di continuous testing che non si collocano fra CI e CD, ma che sono alla base di CI e CD, supportate da una serie di strumenti che permettono di cambiare le metodologie di testing e il modo stesso di intendere il testing.

Occorrono strumenti che semplificano la pianificazione, i piani di test e l'automazione dei test e tutto questo deve essere implementato in tutte le catene degli strumenti di implementazione per CI e CD.

LEAD TIME

INCIDENTI DI PRODUZIONE

VALORE DI BUSINESS

RELEASE


Durante la definizione della strategia di transizione al continuous testing, è fondamentale attribuire la massima priorità al problema della sicurezza. Gli esperti di sicurezza ti faranno giustamente notare che la sicurezza è sempre stata considerata "l'ultimo dei problemi", oltre che un ostacolo allo sviluppo. Quando gli sviluppatori non vedono l'ora di immettere il prodotto sul mercato, vengono regolarmente fermati dalle obiezioni degli esperti di sicurezza.

La sicurezza merita di essere inserita fin dall'inizio nel flusso di continuous testing. Costituisce un problema essenziale per l'identificazione e la conferma di tutti gli aspetti della catena del valore, dalla concezione iniziale al cliente. I cicli di feedback consentono di verificare se il prodotto è finalmente pronto e permettono al team di identificare e risolvere i problemi correlati alla sicurezza a mano a mano che si manifestano.

Spesso gli sviluppatori creano inconsapevolmente vulnerabilità di sicurezza. Il continuous testing della sicurezza non permette solo di identificare queste vulnerabilità, ma anche di determinare il tipo di formazione necessario per aiutare gli sviluppatori a comprendere le problematiche inerenti e a prestarvi attenzione durante la scrittura del codice, per evitare completamente di introdurre le vulnerabilità. Il responsabile della sicurezza deve diventare un partner, un consulente di fiducia e un esperto, che fornisce agli sviluppatori la formazione e la strumentazione necessaria per effettuare le misurazioni a valle.

Il testing della sicurezza deve essere eseguito a ogni passaggio. Pertanto, gli sviluppatori devono effettuare scansioni di sicurezza per identificare i problemi a mano a mano che si manifestano. Attualmente, sicurezza e testing si trovano dalla parte opposta della barricata, rispetto agli sviluppatori. Occorre comprendere che la sicurezza non si contrappone alla qualità, ma è necessario collaborare affinché vadano di pari passo.

È necessario specificare chiaramente i requisiti che definiscono un livello di sicurezza sufficiente. La sicurezza è una responsabilità di tutti, ma abbiamo bisogno di capire quando il lavoro è terminato. Il team di sviluppo deve ricevere la formazione necessaria per capirlo e gli strumenti appropriati per eseguire le misurazioni a fronte dei requisiti. L'uso di questi strumenti di test deve essere integrato nella pipeline, per consentirci di valutare costantemente il nostro lavoro. E in qualsiasi procedura DevOps efficace, la scansione di sicurezza fornisce un feedback utile per misurare lo stato attuale e anticipare la formazione, in modo da continuare ad aumentare le competenze del team nel corso del tempo. Oltre a migliorare la sicurezza, insegnare agli sviluppatori a scrivere correttamente il codice fin dall'inizio consente anche di aumentare la velocità.

La responsabilità della sicurezza è anche un problema dei vertici aziendali. Da qui, le domande e le soluzioni si propagano spontaneamente fino ai livelli più bassi dell'organizzazione. Partendo dal basso, è possibile ottenere il consenso di alcuni team, ma per un'adozione reale nell'intera azienda è necessaria la sponsorizzazione degli executive.

Infine, il team di sicurezza deve evolversi a sua volta per garantire che i suoi membri si considerino parte integrante dell'IT.

CAPITOLO 8 SICUREZZA

DEV SEC OPS


Infine, un piano di continuous testing deve includere la predisposizione per il futuro, in un'era caratterizzata da velocità e cambiamenti incessanti. Per prepararsi al futuro occorre una strategia per tutti gli aspetti dello sviluppo, ovvero dalla scrittura del codice al testing, incluse funzioni, performance e sicurezza. Questo include anche la gestione dell'ambiente, dalla generazione dei dati di test alla Service Virtualization.

È fondamentale mantenere una visuale nitida per garantire che anche gli strumenti utilizzati per il continuous testing puntino nella stessa direzione. Occorre adottare un approccio in linea con la direzione della strategia di business e l'IT deve fare parte di tale strategia, anziché limitarsi a svolgere un ruolo di supporto.

A tale scopo, servono risorse dedicate. Questo aspetto non può essere completamente affidato a terze parti, ma tali parti non devono essere neanche escluse. Per raggiungere i suoi obiettivi, l'azienda può ricorrere a Global Systems Integrator (GSI) e Global Service Provider (GSP), ma deve coinvolgere anche il personale interno nel processo. Deve imparare dalla sua stessa esperienza, ma anche analizzare e consolidare i propri rapporti con terze parti perché oggi, o domani, potrebbero offrire una soluzione integrabile nella pipeline.

Identifica e forma team dedicati alla realizzazione di piattaforme che supportano la pipeline applicativa e metriche base in linea con il continuous testing. L'azienda deve pertanto evolversi da un piccolo gruppo di tecnici e tester che usano metodi manuali a un'impresa capace di costruire.

Il percorso di continuous testing deve determinare una riduzione del testing black box, mentre il testing white box deve diventare sempre più importante e significativo e i tester devono essere all'altezza del compito. Questo impone la trasformazione dei CoE da Center of Excellence a Center of Enablement, cosa che a sua volta esige un cambiamento nella formazione dei team e dei gruppi di tester.

I Big Data sono destinati a svolgere un ruolo critico per il testing, soprattutto al fine di perfezionare la copertura del codice per tutti i tipi di test. Il mercato trabocca di suite per i test di copertura e regressione. Sono disponibili soprattutto strumenti che permettono di sviluppare una soluzione scientifica per determinare se i test di regressione sono in grado di assicurare il livello appropriato di copertura del codice.

Le aziende devono prepararsi al cambiamento ed essere disposte a seguirlo. Ecco alcuni punti chiave:

La leadership esecutiva deve essere consapevole della velocità con cui sta cambiando il mondo attorno a noi. Si lavora con tecnologie mobile e applicazioni basate su cloud e la velocità costituisce la linfa vitale. Tutto punta a una customer experience end-to-end completamente trasparente. Cloud, DevOps, Agile e Big Data convergono tutti su una customer experience completamente integrata. E tu devi decidere come applicare tutto questo al testing. È il punto di incontro fra due mondi.

CAPITOLO 9 PREPARARSI AL FUTURO

IL RUOLO CHIAVE DI AI

• L'automazione dell'automazione e la generazione automatica e istantanea dei test sostituiranno le suite di test di regressione, che in futuro non saranno più gestibili. • L'osservazione del comportamento degli utenti in tempo reale è sempre più importante e, di conseguenza, si renderà necessario convalidare tali osservazioni. • Registrazione e riproduzione sono ormai un ricordo del passato. • Verrà prestata sempre più attenzione alla corretta definizione dei requisiti e ai nuovi metodi per analizzarli e identificare le carenze.


L'utente/consumatore deve percepire il valore che il business desidera offrirgli. È proprio qui che il continuous testing diventa il veicolo dell'innovazione.

Nell'Internet of Things i device si connettono in tutti i modi possibili. Al momento, ci preoccupiamo del continuous testing di browser e API, ma parlando di device fisici e mobile e di Internet of Things, saranno gli hub di integrazione che consentono il continuous testing a promuovere il cambiamento. Il pubblico sta iniziando a notare questo tipo di carenze.

Devi sempre essere tre passi avanti sulle tecnologie, come gli analytics predittivi.

I migliori esperti di QA e QE si evolvono rapidamente. Il loro livello di competenze continua ad aumentare e in futuro la preparazione richiesta per il continuous testing sarà molto diversa da quella attuale. Le aziende devono attribuire la massima priorità al mobile e alle esperienze multicanale.

Le aziende più agili non puntano solo a estendere la propria quota di mercato attraverso l'adozione di una cultura di continuous testing, ma si impegnano anche per attirare i migliori talenti che possono aiutarle.

La transizione al continuous testing è un percorso, come era e rimane la transizione ad Agile e DevOps. Aziende e team IT incontreranno vari ostacoli, che devono essere anticipati e accettati. Proprio per questo è essenziale pianificare ogni singolo passo del percorso di continuous testing.

Oltre che una tecnica, il continuous testing è anche una cultura. Tutto il team può imparare dagli errori, adottando un approccio "fail-forward" che prenda le distanze dai compartimenti stagni del passato. Tutti i grandi progressi e le vittorie personali affondano le proprie radici nel punto di incontro fra conoscenza ed esperienza.

Anche se il continuous testing si avvale di strumenti tecnologici, alla base c'è sempre l'essere umano. A mano a mano che acquisiscono fiducia e sicurezza, le persone riescono a esprimere tutta l'energia, la lungimiranza e le straordinarie capacità pratiche di cui hanno bisogno.

Il raggiungimento di questi obiettivi permette di trovare un nuovo slancio, consentendo alle aziende di raggiungere un livello sufficiente per muoversi con successo nella nuova economia globale.

RIEPILOGO


Copyright © 2018 CA Technologies, Inc. Tutti i diritti riservati. Tutti i marchi citati nel presente documento sono di proprietà delle rispettive società. Il presente documento non contiene alcuna garanzia e ha scopo esclusivamente informativo. Le funzionalità descritte possono essere applicabili solo ai clienti citati e le performance effettive del prodotto possono variare. CS200-383435_0818

Guida definitiva al continuous testing - ca.com · a coprire l'intero ciclo di sviluppo del...

Documents

Transcript of Guida definitiva al continuous testing - ca.com · a coprire l'intero ciclo di sviluppo del...