Leadership nel Test: Strumenti per il Testing
Nota dell'editore: Benvenuti alla serie Leadership nel Test del guru del testing software e consulente Paul Gerrard. La serie è pensata per aiutare i tester con alcuni anni di esperienza—specialmente quelli che lavorano in team agile—a eccellere nei ruoli di coordinamento e gestione dei test.
Nell'articolo precedente, abbiamo esaminato l'infrastruttura del sito e come testarla. In questo articolo vi guiderò attraverso la cassetta degli attrezzi del tester, come scegliere tra soluzioni proprietarie e open source, e proporrò un rapido esercizio di selezione degli strumenti.
Iscriviti alla newsletter di The QA Lead per ricevere notifiche quando nuove parti della serie sono pubblicate. Questi post sono estratti dal corso Leadership nel Test di Paul, che consigliamo vivamente per un approfondimento su questo e altri argomenti. Se decidi di iscriverti, usa il nostro esclusivo codice coupon QALEADOFFER per ottenere $60 di sconto sul prezzo totale del corso!
I team software che si autogestiscono utilizzano una gamma di strumenti più ampia che mai. In un tipico team di sviluppo, potrebbero essere in uso venti o persino trenta strumenti diversi. Per aiutarti a orientarti tra tutti questi, in questo articolo parleremo di:
- Strumenti per il testing
- Architettura degli strumenti
- Gestione dei test
- Progettazione dei test
- Proprietario o open source?
- Un esercizio di selezione degli strumenti
Cominciamo a vedere quali sono le principali tipologie di strumenti che utilizzerai per i test.
Strumenti per il testing
È utile suddividere gli strumenti rilevanti per il testing in tre tipologie:
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
- Strumenti di collaborazione: supportano la raccolta di idee e requisiti, la comunicazione tra i membri del team con un certo grado di integrazione con i processi automatizzati, a volte tramite bot.
- Strumenti di testing: un ampio spettro di strumenti che supportano la gestione dei dati di test, la progettazione dei test, i framework di unit testing, l’esecuzione di test funzionali, test di performance e carico, test statici, la gestione del processo di testing, dei casi di test, della registrazione e dei report dei test.
- Strumenti per DevOps o gestione delle infrastrutture: strumenti che supportano la gestione degli ambienti e delle piattaforme, il deployment attraverso infrastrutture come codice e tecnologie container, e la registrazione, il monitoraggio e l'analisi in produzione.
The Tools Knowledge Base è un registro online di strumenti diverso dalla maggior parte dei registri disponibili perché include strumenti per collaborazione, testing e DevOps. Sono presenti più di 1700 strumenti in queste tre aree. Le pagine web degli strumenti sono indicizzate e ricercabili.
Il sito aggrega e indicizza anche oltre 300 blogger e più di 52.000 blog, anch'essi indicizzati e ricercabili. Abbiamo fornito gli URL alle principali categorie di strumenti e scorciatoie per le ricerche di queste categorie nei blog.
Ci sono oltre 1700 strumenti che supportano collaborazione, testing e DevOps.
Più avanti nell'articolo approfondiremo le principali problematiche che influenzano e supportano la gestione dei test.
Architettura degli strumenti
Nell’immagine qui sotto, abbiamo identificato la gamma di tipologie di strumenti che la maggior parte dei team software moderni utilizza. Abbiamo separato gli strumenti che tendono a essere usati negli ambienti di sviluppo, testing e produzione.
Questi strumenti si basano su strumenti di infrastruttura che forniscono piattaforme, macchine virtuali e container per ospitare gli ambienti, e strumenti che eseguono deployment automatizzati. Gli strumenti utilizzati per gestire le distribuzioni e le release sono chiamati orchestratori di pipeline e release. La comunicazione all'interno del team, così come con molti dei processi automatizzati, è gestita da strumenti di collaborazione o ChatOps.
Sebbene la transizione verso DevOps stia guidando lo sviluppo e l'adozione di strumenti per supportare lo sviluppo continuo, quasi tutti questi strumenti risultano utili a qualsiasi team di sviluppo software o di operations.
Non devi avere una cultura DevOps per utilizzare strumenti “DevOps”.
Gestione dei test
Gli strumenti di gestione dei test sono indispensabili in tutti i progetti su larga scala. I progetti Agile di solito adottano un software per la gestione degli incidenti e, per quanto riguarda i test, fanno anche affidamento sull’uso di business stories e scenari per tracciare gli esempi chiave di test, se non tutti. Gli strumenti di gestione dei test variano per portata, da soluzioni molto semplici come Microsoft Excel a prodotti di Application Lifecycle Management (ALM) più completi.
In generale, il campo d'azione degli strumenti di gestione dei test copre diverse aree:
Modello di Copertura dei Test: La maggior parte degli strumenti di gestione dei test consente di definire un insieme di requisiti contro cui mappare i casi di test e/o i controlli nei test. Questi requisiti possono talvolta essere gerarchici per riflettere la struttura di un sommario di un documento. Sempre più spesso, altri modelli come use case o flussi di processo aziendale possono essere acquisiti. Solitamente sono disponibili report di copertura del piano di test e dell’esecuzione.
Gestione dei Casi di Test: I casi di test e i loro contenuti possono essere gestiti per fornire una traccia documentata dei test. Il contenuto dei casi di test può essere preparato in anticipo rispetto all’attività di test oppure come registrazione dei test effettivamente eseguiti. I casi di test possono essere in formato testo libero oppure strutturati in passaggi con risultati attesi. Importare documenti e immagini da associare ai test o ai passaggi è una pratica comune.
Pianificazione Esecuzione Test: I test possono essere strutturati in una gerarchia o etichettati per fornire una struttura più dinamica. Ai membri del team di test possono essere assegnati i test da eseguire. Le durate previste dei test possono essere utilizzate per pubblicare un programma sincronizzato dei test da eseguire nel team. Sottogruppi di test possono essere selezionati per soddisfare la copertura dei requisiti, testare funzionalità selezionate o rieseguire set di regressione. I test segnalati come non ancora eseguiti, bloccati, falliti o con altro stato possono anch'essi essere selezionati per l'esecuzione.
Esecuzione e Log dei Test: Quando i test vengono eseguiti dal team, si registra lo stato di ogni test. Tutti i test eseguiti devono riportare il nome di chi li ha effettuati e la data/ora e la durata rilevata. I test superati possono avere uno stato "superato" semplice. I risultati falliti, bloccati o anomali possono essere corredati di screenshot, risultati ottenuti e segnalazione dell'incidente. Molti strumenti offrono integrazioni con strumenti di esecuzione dei test che gestiscono ed eseguono test, registrano i risultati e possono persino creare segnalazioni di incidenti in bozza.
Gestione degli Incidenti: I fallimenti dei test vengono registrati nel registro di esecuzione. Questi solitamente richiedono un’indagine ulteriore, con attività di debugging e correzione nel caso in cui il fallimento sia causato da un bug. Le anomalie che necessitano approfondimenti sono generalmente documentate tramite segnalazioni di incidenti, osservazioni o bug report. Le segnalazioni di incidenti possono contenere molte informazioni di supporto. Di norma a ogni incidente viene assegnato un tipo, un oggetto sotto test, una priorità e una severità. Alcune aziende registrano un’enorme quantità di dettagli e li associano a un sofisticato processo di gestione degli incidenti.
Reportistica: Report ed analisi dei dati relativi a tutte le funzionalità sopra indicate, a seconda dei casi. La varietà dei report va dalla copertura pianificata vs effettiva dei test, allo stato delle segnalazioni di incidenti per tracciare indagini, correzioni e ripetizioni da effettuare, alle analisi dei tempi di risoluzione dei diversi tipi di fallimento, per funzionalità, gravità, urgenza e così via.
Lo strumento di gestione dei test più popolare al mondo rimane ancora Microsoft Excel.
Progettazione dei Test
La progettazione dei test si basa su modelli. Nel caso dei tester di sistema e di accettazione, i modelli tipici sono documenti di requisiti, use case, flowchart o diagrammi swim-lane. Modelli tecnici più avanzati come i modelli di stato, i diagrammi di collaborazione, i diagrammi di sequenza e così via costituiscono anch’essi una solida base per la progettazione dei test.
In molti progetti i modelli vengono utilizzati per raccogliere i requisiti o i progetti ad alto livello. Quando sono messi a disposizione dei tester, possono essere impiegati per tracciare i percorsi ed estrapolare direttamente elementi da coprire tramite il modello stesso. Se modelli di questo tipo non sono disponibili, spesso è utile che il team di test realizzi ad esempio flowchart di processo o diagrammi swim-lane. Questi aiutano i tester ad avere discussioni più significative con gli stakeholder, soprattutto per quanto riguarda l’approccio alla copertura.
Nell'ambito proprietario stanno emergendo strumenti che consentono di catturare modelli, come i flowchart, e generare casi di test seguendo i percorsi secondo un dato target di copertura, ad esempio tutti i collegamenti, tutti i processi, tutti gli esiti delle decisioni, tutte le coppie e tutti i percorsi. Questi strumenti possono essere integrati con strumenti di gestione e generazione dei dati di test, per generare combinazioni di dati da usare nei test manuali o automatici.
Esistono anche strumenti che permettono di effettuare la modellazione direttamente nei tool di esecuzione dei test. Ad esempio, questi tool consentono allo sviluppatore dei test di mappare tutti i campi di una pagina web, creare collegamenti per 'unire' i campi e realizzare un modello di navigazione per la pagina – tutto in formato grafico.
Il modello viene poi utilizzato per creare percorsi di navigazione e costruire una suite di test che soddisfi determinati criteri di copertura — proprio come negli strumenti di modellazione sopra citati. Questi strumenti di esecuzione possono generare percorsi di test automatici secondo criteri selezionati o generarli casualmente, e possono anche produrre report di copertura rispetto a questi modelli.
Attualmente si tratta di un settore in forte evoluzione: continuate a monitorare i tool di modellazione che supportano la progettazione e la generazione di test, e i tool di esecuzione che supportano la modellazione del sistema sotto test, la selezione automatica dei percorsi di test e la reportistica.
Proprietario o Open Source?
Negli ultimi vent'anni, l'utilizzo di prodotti software liberi e open-source (FOSS), soprattutto per gestire l'infrastruttura, si è diffuso ampiamente. Il costo delle licenze dei sistemi operativi e dei relativi software per server web di Microsoft, insieme alla convinzione generale che Linux/Unix sia più affidabile e sicuro rispetto a Windows, fanno sì che per molti ambienti Linux/Unix sia il sistema operativo preferito per i server.
Sebbene l'articolo discuta i pro e i contro degli strumenti open-source e proprietari, se cerchi soluzioni che si integrino bene con Jira, la nostra guida completa su strumenti di gestione dei test specifici per Jira può aiutarti a prendere una decisione consapevole.
Le due tabelle seguenti (aggiornate quotidianamente su w3techs.com) mostrano la popolarità relativa dei sistemi operativi e dei prodotti server web. Circa l'85% dei siti utilizza i prodotti server web open-source più conosciuti, Apache e Nginx.
La popolarità di questi prodotti di infrastruttura FOSS dimostra che l'open source può essere tanto, se non più, affidabile dei prodotti proprietari.
Per un team di sviluppo che necessita di venti o trenta strumenti software a supporto delle proprie attività, esistono strumenti FOSS e proprietari affidabili e funzionali per ogni esigenza. Come scegliere tra un prodotto proprietario e uno FOSS?
La tabella seguente riassume alcune delle considerazioni da fare nella selezione di una tipologia di strumento.
| Proprietario | FOSS | |
| Disponibilità | Strumenti disponibili per ogni area. | Alcune aree, in particolare gli strumenti di sviluppo e infrastruttura, sono meglio supportate di altre. |
| Costo di acquisto | Spesso costosi, soprattutto i prodotti "enterprise". | Gratuiti, o licenza ad uso comunitario a costo zero. Possono esistere licenze commerciali per versioni enterprise o in hosting. |
| Documentazione | Di solito molto buona. | Varia. A volte eccellente, a volte inesistente e tutto quello che c'è nel mezzo. Spesso scritta da programmatori per programmatori, quindi meno utilizzabile rispetto alla documentazione commerciale. |
| Supporto tecnico | Molto buono, a pagamento. | Varia. Alcuni autori di strumenti forniscono un supporto eccellente e persino aggiungono funzionalità su richiesta. Molti strumenti hanno forum online – ma possono essere molto tecnici. Altri strumenti sono scarsamente supportati. |
| Affidabilità/qualità | Di solito molto buona. | Variabile. I prodotti con molti utenti, localizzazioni e team di supporto ampi tendono ad essere eccellenti. Alcuni strumenti scritti da singoli individui con pochi contributori e utenti possono essere instabili. |
| Ricchezza di funzionalità | I set di funzionalità tendono a seguire roadmap di prodotto pubblicate e sono di solito completi. | I prodotti tendono a evolversi in base alla domanda degli utenti e alla dimensione del team di contributori. I contributori tendono ad aggiungere funzionalità di loro necessità più che sulla base di sondaggi fra i clienti, ad esempio. |
| Frequenza di release/patch | Le versioni principali tendono a essere rilasciate a distanza di mesi, a volte anni. Rilasci regolari di patch. Avvisi e note di rilascio di solito molto buoni. | Varia. I major release dei grandi prodotti di infrastruttura - come i prodotti proprietari. I prodotti più piccoli e meno popolari tendono a essere aggiornati più frequentemente. Pochi o nessun avviso, note di rilascio scarse e, a volte, perdita della compatibilità all'indietro. |
I prodotti FOSS possono essere più economici da procurare, ma altri costi e responsabilità possono essere significativi. Il fattore decisivo tra i due tipi è di solito una combinazione tra la cultura aziendale, la propensione al rischio e le competenze tecniche.
Quando acquisti prodotti proprietari e contratti di supporto, i rischi associati all'incompatibilità (con altri prodotti), affidabilità, facilità d'uso e supporto tecnico attento sono generalmente ridotti, anche se a volte costosi.
Con i prodotti FOSS di solito è necessario effettuare ricerche molto più approfondite prima di impegnarsi a utilizzarne uno. Dopotutto, non c'è un commerciale con cui parlare e la documentazione può essere funzionale ma non informativa. Naturalmente, è facile impostare un periodo di prova e puoi testare tutti gli strumenti che vuoi, ma dovrai condurre un'indagine più approfondita sulle capacità dello strumento.
Una minore usabilità e l'incompatibilità con gli strumenti già in uso potrebbero presentare dei problemi, quindi potresti dover scrivere software di interfacciamento o plug-in e utility per reportistica o import/export dati.
Inoltre, dovrai formare te stesso e il tuo team per portarli al passo e di solito fornire il supporto software in autonomia. Tuttavia, il tuo team avrà una conoscenza più approfondita del funzionamento dello strumento e sarà in gran parte autosufficiente.
Uno strumento FOSS potrebbe aiutarti a fare esperienza con una nuova tipologia di strumento a costi ridotti. Con questa esperienza, sarai in una posizione migliore per scegliere uno strumento proprietario per il lungo termine.
Un esercizio di selezione degli strumenti
Se stai cercando uno strumento per la gestione dei test per supportare il tuo progetto attuale o uno recente, familiare, e l’applicazione relativa, basandoti sulle aree funzionali trattate sopra nella discussione degli strumenti di test management, crea un elenco di 15-20 funzionalità che siano:
- Obbligatorie
- Desiderabili
Possono includere funzionalità operative, integrazioni, facilità d’uso, supporto, ampia base di utenti o forum/FAQ online. Se già utilizzi uno strumento, non scegliere quello.
Usando il testo dei tuoi requisiti, cerca nella Knowledge Base degli Strumenti tre strumenti (inclusi un prodotto proprietario e uno FOSS) che sembrano corrispondere alle tue esigenze. Utilizzando le descrizioni delle funzionalità degli strumenti, crea una tabella di confronto tra i tre prodotti. Aggiungi una quarta colonna allo strumento che stai effettivamente utilizzando – per confronto.
- Come si confrontano gli strumenti in termini di funzionalità?
- Quali funzionalità mancano agli strumenti FOSS rispetto a quelli proprietari?
- Quanti strumenti esistono che rispondono in modo generale ai tuoi requisiti?
- Quanto tempo pensi sarebbe necessario dedicare alla ricerca per stilare una short-list di, diciamo, tre strumenti?
Iscriviti alla newsletter di The QA Lead per ricevere notifiche quando saranno pubblicate nuove parti della serie. Questi post sono estratti dal corso di Paul Leadership In Test—altamente consigliato a chi vuole approfondire questi e altri argomenti. Se decidi di iscriverti, usa il nostro codice coupon esclusivo QALEADOFFER per ottenere $60 di sconto sul prezzo completo del corso!
Impara dagli altri tester ascoltando i nostri podcast o leggendo i nostri blog. Ecco uno da cui pensiamo potrai imparare molto: COME LE COMPETENZE DI TESTING MI HANNO RESO UN MIGLIORE DEVELOPER DI AUTOMAZIONE
