Le insidie dell’automazione dei test
Automazione, a Fette Sottili
Non si può negare che l’automazione dei test abbia rivoluzionato il collaudo del software. E proprio al momento giusto! Nel mondo odierno, caratterizzato da servizi ultra-distribuiti, containerizzati e continuamente aggiornati, un testing significativo del software sarebbe impossibile senza di essa.
Siamo fortunati ad avere a disposizione così tanti strumenti di testing automatico sofisticati. E, lasciate che lo dica, anche ottimi ingegneri QA ben formati che li utilizzano a beneficio di tutti nello sviluppo.
Ciononostante, per qualche motivo, è tipico della nostra industria ridurre abitualmente questi importanti progressi in mode passeggere, e queste mode in slogan svuotati di significato e frasi fatte che vengono ripetute automaticamente dai manager di alto livello, dagli opinionisti e dai consulenti che vogliono solo una scusa per smettere di riflettere sul problema. O per guadagnare facilmente.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
Così è anche per le conquiste nell’automazione dei test, che sono rapidamente finite nella narrazione riduttiva del "dobbiamo solo automatizzare tutti i nostri test! Ora! E tutti i nostri problemi di testing saranno risolti!"
Non solo questa è un’idea pessima, anche se fosse proposta da chi prende il problema sul serio e non cerca semplicemente di evitarlo. È anche perniciosa, perché è una narrazione che, chiudendo ogni possibilità di riflettere a fondo su come integrare l’automazione nei test, ne assicura il fallimento. Il che è ingiusto per tutte le persone (clienti compresi) che dipendono dal suo successo.
Da questo punto di vista, l’automazione dei test eredita una particolare istanza dell’approccio generale alla SQA di chi non la comprende, e non vuole comprenderla. È trattata come una merce all’ingrosso, non come una competenza complessa. Ecco perché spesso chi lavora nel QA si sente dire dai dirigenti: "ci serve solo più QA!" come se da qualche parte esistesse una salumeria del software dove puoi ordinarla a fette sottili, al peso.
Ecco perché ora il mantra è "ci serve solo più automazione!" senza alcuna riflessione su cosa ciò significherebbe davvero nel contesto dei vostri sforzi di sviluppo software. Questo tipo di discorso alimenta le disfunzioni della vostra organizzazione invece di risolverle.
Cercare di contrastare direttamente queste tendenze di moda è come tentare di impedire al sole di sorgere. O, in questo caso, di tramontare. Il miglior modo di resistere è annuire e sorridere ai vicepresidenti e ai consulenti, tornare alla vostra scrivania e studiare il modo giusto di fare automazione, per poi presentare quelle idee come se fossero il frutto dell’immaginazione dei vostri manager. Ma probabilmente avete già imparato questa lezione su altri temi.
Dunque, facciamo proprio così. Ecco il mio elenco delle insidie nell’implementazione dell’automazione nei test e di come mitigarle, affinché l’automazione possa mantenere le sue grandi promesse nei vostri sforzi di testing.
Ambito dell’Automazione
La domanda più importante da porsi all’inizio è dove l’automazione del testing apporta il miglior rapporto qualità-prezzo nei vostri sforzi di test. Dedicarci del tempo ora vi risparmierà molti mal di testa in futuro.
Rispondere a questa domanda significa stabilire quanta parte delle vostre attività di testing deve essere automatizzata e quanta deve rimanere manuale. Questo potrà sorprendere chi è costantemente bombardato dal vangelo dell’“automatizzare tutti i test!”. Non date retta a queste sciocchezze, queste persone non hanno idea di cosa stiano parlando.
Automatizzare tutti i vostri test – ammesso che sia possibile – sarebbe una pessima decisione che porterebbe solo al disastro nei vostri sforzi di testing.
Ci sono cose meravigliose che l’automazione può realizzare e che il testing manuale non può, o almeno non così velocemente e con tale ripetitività. Ma anche il contrario è vero. Ci sono aspetti che solo il testing manuale sa fare davvero bene, che l’automazione non riesce a coprire. Quali sono queste attività in ciascun caso?
Dove il testing manuale eccelle rispetto a quello automatizzato è proprio nel fattore umano. Il vantaggio di avere una persona che esegue con pazienza test esplorativi approfonditi non può essere duplicato dall’automazione. E non parlo solo della scoperta di bug.
Chiunque può trovare bug. I clienti lo fanno gratis di continuo. Il valore aggiunto di un professionista QA risiede nell’intuizione di come "rompere" un software, in particolare nel capire come possa essere usato dai clienti in modi per cui non era progettato ma che – spesso con conseguenze disastrose – risultano comunque possibili.
Un altro vantaggio del testing manuale è che, individuato un bug, il tester manuale può subito valutarne portata e gravità. Ossia, restringere il campo dei contesti di test (sistemi operativi, workflow, interazioni e dipendenze tra servizi) in cui si manifesta e quelli in cui non si manifesta.
Gli script di test automatizzati non sono affatto in grado di fare questo efficacemente e, dal punto di vista dell’ingegnere del software, questa è proprio l’informazione chiave per diagnosticare e correggere un bug. Un bug report che si limita a dire "ho fatto così e così ed è successo questo problema" per loro è inutile.
I test manuali sono spesso molto più efficienti nel fornire queste informazioni e, essendo intrinsecamente interattivi e allineati con il lavoro degli sviluppatori, trasmettono feedback molto più ricchi di informazioni e fondamentali nell’analisi delle cause.
Sì, Virginia, il testing manuale non è sempre il modo meno efficiente e più dispendioso per trovare, diagnosticare e correggere bug, e per validare (o meno) le relative correzioni.
Dove l'automazione ha un vantaggio evidente, tuttavia, è nel testing continuo per la disponibilità e la stabilità—specialmente per i sistemi distribuiti. Questo aspetto è oggi molto più centrale, dato il nostro contesto di sviluppo attuale caratterizzato da integrazione e distribuzione continue in ambienti distribuiti in tempo reale.
L'automazione è anche più efficiente in quello che si potrebbe definire “testing di massa”, ossia quando si ha una grande matrice di migliaia di condizioni di sistema e delle loro variabili da coprire per verificare se qualcuna di esse sia completamente rotta o possa causare il blocco del sistema.
La regola pratica che dovresti usare per guidare i tuoi progetti e decidere dove privilegiare il testing manuale o quello automatico è la seguente:
Il testing manuale è solitamente preferibile nella fase iniziale di verifica di nuove funzionalità e capacità. Il testing automatico è chiaramente il migliore per la verifica continua delle regressioni generali, e per il testing di carico e prestazioni.
Nel corso del ciclo di vita di un prodotto o servizio, la verifica della stessa funzionalità dovrebbe evolvere da manuale ad automatizzata. Si tratta di un continuum nel ciclo di vita della capacità. Non di un muro invalicabile, che non possa mai essere oltrepassato, e dove nessuna delle due parti abbia bisogno di sapere cosa accade dall’altra parte. L’ipotesi di default dovrebbe essere che ciò che oggi viene testato manualmente debba, col tempo, passare al testing automatizzato.
Qualifiche per Ingegneri dell’Automazione
È forse inevitabile che, nel processo di selezione di ingegneri per il testing automatizzato, le qualifiche fondamentali ricercate siano (a) i livelli di competenza dei candidati negli strumenti di automazione che dovranno utilizzare, e (b) i linguaggi di scripting per i test utilizzati da tali strumenti.
Ma se queste sono le uniche qualifiche su cui ti stai concentrando, stai facendo un grande errore. Si tratta di requisiti necessari, ma ben lontani dall’essere sufficienti per il ruolo di ingegnere dell’automazione.
Perché? Per il semplice motivo che sapere come utilizzare uno strumento di automazione e come creare script nel suo linguaggio non ci dice assolutamente nulla sulla reale comprensione che hanno del Quality Assurance stesso.
Purtroppo, quasi mai vedo ingegneri dell’automazione che abbiano questa preparazione o background. Vengono assunti semplicemente perché sono maghi dello scripting, non perché hanno alcuna competenza nella progettazione di test efficaci e diagnostici.
Queste qualifiche sono in realtà più importanti dell’esperienza con strumenti e linguaggi di automazione che utilizzeranno. Possono imparare facilmente questi strumenti se necessario. Ma ci vuole molto tempo e sforzo per formare qualcuno su come progettare test e interpretarne i risultati.
Sarebbe infatti meglio prendere un analista esperto già all’interno dell’azienda e formarlo sugli strumenti di automazione necessari. Queste competenze di automazione, dopotutto, sono ormai una commodity. L’intuizione e la sensibilità di un tester esperto non lo sono.
Automatizzare l’ignoranza significa soltanto produrre ignoranza più velocemente e in modo più ripetibile, minando l’efficienza che si stava cercando nell’automatizzazione dei test.
Standard di Progettazione dell’Automazione
È ovvio che, se stai per avviare una vasta iniziativa di automazione dei test, dovrai prima definire standard generali a cui tutta l’automazione dovrà conformarsi per poter essere accettata nei test. Eppure, come spesso accade con le cose più ovvie, sembra che ci siano meno cervelli in giro di quanto uno potrebbe aspettarsi.
Ecco cosa dovrebbero coprire questi standard.
Comprensibilità
Uno dei misteri frustranti dello sviluppo software è quanto spesso si riveli artigianale. Non è purtroppo raro che un ingegnere del software ti dica che non può correggere un bug perché non ha scritto lui il codice in cui appare. È come se il codice scritto da un altro ingegnere fosse in una lingua straniera che non comprende.
Purtroppo, questa situazione è altrettanto comune anche nell’ingegneria dell’automazione dei test. Non saprei dire quante volte un ingegnere QA mi ha detto di non sapere come aggiornare una porzione di automazione dei test per un importante aggiornamento di prodotto perché non l’ha scritta lui e quindi non la conosce, né può capirla. Ah, e l’ingegnere che l’ha scritta ha lasciato l’azienda due mesi fa.
Questo è ancora meno accettabile nel caso degli script di test automatizzati rispetto al nuovo codice software che implementa la logica di progetto, non solo determinati passaggi da compiere. Eppure è sorprendentemente comune.
Ciò significa che, prima di assumere una dozzina di ingegneri QA e metterli a produrre allegramente script di test automatizzati a centinaia, assicurati di aver prima definito e formato su standard generali di comprensibilità.
Deve essere un requisito che tutti gli script di test siano mutuamente comprensibili da chiunque tra i tuoi ingegneri QA, così da non ritrovarti vincolato alla manutenzione affidata a una singola risorsa, spesso transitoria.
Definisci ed applica un processo di revisione/accettazione di tutti gli script candidati all’automazione rispetto a questi standard prima che possano essere utilizzati nei test.
Manutenibilità
La manutenibilità è strettamente legata al problema dell’intelligibilità, tuttavia le due cose sono logicamente e operativamente distinte. Uno script di test può essere facilmente compreso da ingegneri del test che non l’hanno scritto e comunque essere strutturato in modo tale da risultare un incubo da aggiornare o modificare.
Ecco un esempio reale.
Presso uno dei miei datori di lavoro, stavamo preparando lo sforzo di testing per un aggiornamento di livello medio del prodotto di punta. Era previsto un ciclo di rilascio di quattro settimane, che in questo caso era effettivamente ragionevole.
Mentre pianificavo il lavoro di testing richiesto, mi sono reso conto che avremmo dovuto anche aggiornare lo script principale di test di regressione automatico. Quando ho chiesto al responsabile QA quanto tempo avrebbe richiesto l’aggiornamento, mi ha risposto "otto settimane". Il doppio del tempo dell’intero rilascio! Anche considerando l’abitudine ingegneristica di gonfiare le stime, questa era davvero un’esagerazione.
Ho fatto rivedere lo script e la stima da altri ingegneri del collaudo. Tutti hanno concordato che lo script era scritto in modo così goffo e inefficiente che sarebbero servite molte settimane di riscrittura minuziosa per aggiornarlo per la prossima release, anche se gli aggiornamenti stessi non erano riscritture fondamentali del prodotto.
Quella situazione era un classico esempio di un peccato dell’ingegneria del software trapiantato nell’ingegneria del testing. È ora di porre fine a questa follia.
Il mio consiglio qui è identico a quello che do sopra per la questione dell’intelligibilità. Non permettere, in nessun caso, che gli ingegneri QA si isolino nelle loro "caverne" dell’ingegneria dei test per poi riemergere una o due settimane dopo con qualcosa che potrebbe anche funzionare come test, ma sarà un incubo di sofferenza aggiornarlo in modo tempestivo.
Stabilisci degli standard per la possibilità di aggiornamento tempestivo e crea un processo di revisione e accettazione che li garantisca. Questo può essere facilmente integrato negli sforzi già in atto per assicurare l’intelligibilità, così tutto farà parte dello stesso processo di revisione.
I tuoi ingegneri QA non sono pittori rinascimentali, non gli stai chiedendo di ridipingere la Cappella Sistina. Non dovrebbe richiedere una vita intera.
Ruoli nel testing e automazione dei test
Uno degli schemi di inefficienza che ostacolano l’integrazione fluida e fruttuosa dell’automazione nel tuo lavoro di test globale è la convinzione errata che ogni passaggio nel processo di test automatizzato debba necessariamente avvenire all’interno del gruppo di automazione stesso.
Questo è un altro errore. Anche se in questo caso, non del tutto evidente.
Gli ingegneri dell’automazione probabilmente saranno le risorse più pagate del tuo team, quindi il loro tempo è prezioso. Inoltre, il volume di script di test che quel team dovrà creare e aggiornare continuamente crescerà nel tempo, mentre il tuo gruppo di ingegneri del testing non potrà espandersi altrettanto velocemente. Nemmeno se lavori per Google.
Ha quindi senso organizzativo introdurre alcune divisioni di compiti tra il team di automazione e il resto del team. In particolare, la divisione tra le risorse che creano e mantengono script e strumenti automatizzati, e quelle che invece eseguono effettivamente i test automatici.
Chiaramente, la prima serie di responsabilità può essere svolta solo dal team di automazione. È per questo, dopotutto, che sono stati assunti. Tuttavia, ciò non è vero per la seconda attività.
Non c’è motivo per cui anche gli analisti non debbano essere in grado di eseguire autonomamente i test automatici e interpretarne i risultati.
Pochi pensano in questi termini, ma questa divisione del lavoro ha davvero senso. Innanzitutto, libera una notevole quantità di tempo, permettendo agli ingegneri dell’automazione di concentrarsi sulla creazione di nuove automazioni.
Inoltre, rafforza il requisito dell’intelligibilità definito sopra. Se l’automazione è centrale nel tuo lavoro di testing, allora deve essere altrettanto fondamentale che chiunque nel tuo team di test, ingegnere dell’automazione o meno, sia in grado di capire e usare i test automatizzati. Anche i tester manuali.
Un sistema simile di definizione dei ruoli aumenterà notevolmente la flessibilità delle risorse di tutto il team QA, e quindi creerà anche efficienze di tempo e di gestione che altrimenti non esisterebbero.
Considerazioni finali
Sviluppare una solida capacità di testing automatico, come definito sopra, oggi è semplicemente una necessità. Non si può parlare di QA professionale ed efficace senza questa componente.
Eppure molte avventure brillanti iniziano con entusiasmo e gioia, solo per concludersi con la sconfitta al termine del viaggio. Questo succede spesso anche nella QA per quanto riguarda l’automazione dei test.
Il problema è che l’automazione dei test è relativamente facile in cui immergersi. Costosa, ma facile almeno da far finta di impegnarsi. Tuttavia, l’automazione dei test può anche trasformarsi in una scogliera su cui, come Willy il Coyote nei cartoni di Beep Beep, corri distrattamente solo per cadere un secondo dopo, appena ti accorgi che manca il terreno sotto i piedi.
Deve essere chiaro fin dall’inizio che l’automazione dei test ha un ciclo di vita. Ogni script di test ha un ciclo di vita di mesi se non di anni.
Non si tratta solo di scrivere un gran numero di script di test automatizzati che soddisfino tutte le tue esigenze per il prodotto così come si presenta attualmente nello sviluppo. Si tratta di capire come potrai far evolvere senza soluzione di continuità tutte queste automazioni man mano che il prodotto evolve durante il suo ciclo di vita.
Se ignori i problemi relativi all’ambito dell’automazione, alle qualifiche degli ingegneri QA, all’intelligibilità, alla manutenibilità e alla definizione dei ruoli, scoprirai che, col tempo, tutti quegli sforzi di automazione si saranno trasformati in un elefante bianco e in una voragine di denaro impossibile da comprendere o mantenere.
E tutti i soldi che ci hai speso saranno stati sprecati. Una cosa che i capi dei tuoi capi non mancheranno di notare.
D’altra parte, se segui i consigli che ho dato sopra, naturalmente adattati alle particolarità delle tue sfide e alla tua situazione, eviterai in gran parte questa crisi di obsolescenza e potrai godere dei frutti di un’automazione dei test produttiva per molti anni a venire.
Come sempre, buona fortuna.
Letture correlate:
- 10 MIGLIORI STRUMENTI PER IL MONITORAGGIO DEI SERVER WEB
- BEST PRACTICES PER L’AUTOMAZIONE NELLA TRASFORMAZIONE DIGITALE
Vale la pena dare un’occhiata: COS’È MABL? PANORAMICA E TOUR DELLE FUNZIONALITÀ
