Creazione di una Strategia della Qualità
Ripubblicato con il permesso dell'eccellente blog di Kristin, thinkingtester.
Nell’ultimo post, ho introdotto il concetto di modello di maturità della qualità: una serie di comportamenti collegati ad attributi di qualità che aiutano i team a raggiungere vari attributi di qualità nel loro software.
Una cosa importante da notare è che adottare un Modello di Maturità della Qualità richiede che tutto il team contribuisca alla qualità.
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
La qualità non è qualcosa da "lanciare oltre il muro" ai tester; piuttosto è un obiettivo che sia sviluppatori che tester condividono.
Ma come puoi fare in modo che tutto il team si prenda carico della qualità?
Un modo è attraverso la creazione di una strategia di qualità. Questo è un documento su cui tutto il team si trova d’accordo insieme. Pensalo come un contratto che descrive come il team svilupperà, testerà e rilascerà software di qualità.
Qui discuterò alcune domande a cui potrebbe essere utile rispondere nella strategia di qualità del vostro team.
Creazione e Refinement delle User Story
Domanda: Come decide il team su quali user story lavorare?
Potrebbe essere una decisione presa dall’intero team oppure solo dal product owner. Oppure la priorità potrebbe essere determinata da qualcuno esterno al team.
Domanda: Chi si occupa del refinement delle user story per prepararle allo sviluppo?
Questo potrebbe essere fatto da tutto il team o da un suo sottoinsieme. Idealmente, si vorrebbe almeno la partecipazione di product owner, uno sviluppatore e un tester.
Processo di Sviluppo
Domanda: Come decide il team chi lavora su quale user story?
Potrebbe essere che gli sviluppatori possano scegliere liberamente qualsiasi user story dalla bacheca, oppure che ogni sviluppatore possa scegliere solo tra le storie relative a specifiche aree funzionali.
In alcuni team, anche i tester software lavorano su user story di sviluppo semplici, come la modifica di testi o colori su una pagina web, o l’aggiunta di ID di automazione per facilitare l’automazione.
Domanda: Come appare il “Done” per una user story? Viene misurato dal rispetto di tutti i criteri di accettazione? Lo sviluppatore deve aggiungere dei test unitari prima che la user story possa essere considerata completata? Come si sa se una funzionalità è pronta per i test?
In molti team ci si aspetta che lo sviluppatore effettui dei test iniziali per verificare che ciò che ha sviluppato sia pronto per il test successivo.
Passaggio delle Funzionalità
Domanda: Come viene passata una user story ai tester?
In alcuni team, ciò viene fatto semplicemente spostando la user story nella colonna “Testing” della bacheca. In altri team, è richiesta una cerimonia di passaggio più formale, dove lo sviluppatore mostra la user story realizzata e offre suggerimenti per ulteriori test.
Domanda: Chi si occupa di deployare il codice nell’ambiente di test?
Sembra una cosa banale, ma in realtà può essere causa di molti fraintendimenti e tempo perso. Se lo sviluppatore pensa che tocca al tester fare il deploy del codice nell’ambiente di test e il tester dà per scontato che lo sviluppatore l’abbia già fatto, il tester potrebbe iniziare i test senza accorgersi che il nuovo codice manca, fino a dopo aver perso molto tempo con l’applicazione.
Domanda: Chi si occuperà del testing?
In alcuni team, anche gli sviluppatori possono prendersi carico di user story di test semplici per aumentare la velocità del prodotto, mentre le storie più complesse vengono lasciate agli esperti di testing.
Creazione dei Test Plan
Domanda: Chi creerà i test plan? Come verranno creati? Dove saranno salvati i test plan?
Alcuni team potrebbero preferire test esplorativi ad-hoc con documentazione minima. Altri team potrebbero dotarsi di sofisticati sistemi di gestione dei casi di test che documentano tutti i test per il prodotto. Ci sono molte opzioni intermedie.
Qualunque cosa scegliate dovrebbe essere giusta per il vostro team e per il vostro prodotto.
Domanda: Chi scriverà l’automazione dei test?
In alcuni team, gli sviluppatori scrivono i test unitari e i tester quelli per API e interfaccia utente. In altri team, gli sviluppatori scrivono test unitari e API e i tester creano quelli per l’interfaccia utente. Ancora meglio è quando sia sviluppatori che tester condividono la responsabilità di creare e mantenere i test per API e UI.
In questo modo, gli sviluppatori possono contribuire con la loro competenza nella gestione del codice, mentre i tester portano il loro sapere su cosa debba essere testato.
Domanda: Chi svolgerà altri tipi di testing, come sicurezza, prestazioni, accessibilità e test di user experience?
Alcune aziende più grandi possono avere ingegneri specializzati in sicurezza e prestazioni che si occupano di questi test. Piccole startup potrebbero avere un solo team di sviluppo responsabile di tutto.
Strumenti di Test
Domanda: Quali strumenti verranno utilizzati per i test manuali e automatizzati?
La selezione degli strumenti di test è molto importante quando si vuole che l’intero team si occupi dei test. Gli sviluppatori probabilmente preferiranno utilizzare strumenti che adottano il loro stesso linguaggio di sviluppo, perché questo minimizza i cambiamenti di contesto necessari.
Manutenzione dei Test
Domanda: Chi è responsabile della manutenzione dei test?
È sorprendente quanto velocemente l'automazione dei test possa diventare obsoleta. Anche solo una parola cambiata in una pagina può provocare un test fallito. Idealmente, il team dovrebbe avere una politica "chi rompe, ripara" per cui i test vengono sistemati dalla persona che ha committato il codice che li ha interrotti.
Se questo non è possibile, almeno assicuratevi che tutti nel team comprendano come funzionano i test e come ripararli nel caso in cui sia necessario un intervento rapido.
Bug e Debito Tecnico
Domanda: Come vengono gestiti i bug trovati durante i test? Vengono discussi dallo sviluppatore e dal tester, valutati dall’intero team o registrati in un backlog per essere controllati in seguito?
Spesso è una buona idea risolvere i bug appena vengono identificati, perché lo sviluppatore sta già lavorando su quella sezione di codice.
Domanda: Come gestirà il team il debito tecnico?
Il team ha un accordo per assumersi una certa quantità di debito tecnico per sprint? Alcuni team hanno una politica per cui, quando uno sviluppatore ha terminato le storie su cui lavorare, prende in carico gli elementi di debito tecnico dal backlog.
Rilasci
Domanda: Che tipo di test verranno eseguiti prima di un rilascio? Ci sarà un piano di test di regressione che l’intero team potrà eseguire insieme? E il testing esplorativo?
Un team ad alte prestazioni che conosco si riunisce per svolgere test esplorativi poco prima del rilascio. Usando questa strategia, hanno individuato bug insidiosi e li hanno risolti prima che venissero rilasciati in produzione.
Domanda: Come verrà rilasciato il software?
In alcune aziende esiste un release manager che si occupa di eseguire il rilascio. In altre aziende, i membri del team si alternano nel rilascio del software. Una tecnica molto utile è il Continuous Deployment, in cui il software viene distribuito automaticamente e i test vengono eseguiti automaticamente per verificare il corretto deploy in ogni ambiente, facendo risparmiare tempo e fatica a tutti.
Approfondimento correlato: COME ESEGUIRE API SMOKE TESTS NELLA TUA PIPELINE DI CONTINUOUS DEPLOYMENT
Manutenzione
Domanda: Come misurerete il successo del rilascio?
Una volta che il software è stato rilasciato, è facile per i team di sviluppo dimenticarsene; ma è proprio questo il momento in cui gli utenti iniziano a utilizzarlo. Quali metriche potreste usare per valutare quanto bene sta funzionando il vostro prodotto? Potreste tenere traccia dei difetti segnalati dai clienti, oppure consultare i log per eventuali errori imprevisti.
Domanda: Come monitorerete la salute della vostra applicazione?
Sarebbe una buona idea impostare degli alert in modo da poter venire a conoscenza rapidamente di eventuali problemi con l’applicazione, prima ancora che lo facciano gli utenti.
Domanda: Che tipo di comportamenti dovresti monitorare?
Le strategie di qualità possono essere varie come i fiocchi di neve. Immaginate la differenza tra una piccola startup di dieci persone che sviluppano una app di chat per dispositivi mobili e una azienda di ventimila persone che progetta software per far volare aerei. Queste due realtà avranno bisogno di strategie completamente diverse!
Potete progettare una strategia di qualità che funzioni bene per il vostro team discutendo insieme queste domande e creando una strategia con cui tutti siano d'accordo.
Per strumenti e tecnologie a supporto dei vostri processi, consultate questa lista dei 10 MIGLIORI TOOL PER LA GESTIONE DEI TEST DATA.
