Leadership nei test: strumenti di test

• Strumenti di collaborazione: supportano la raccolta di idee e requisiti, la comunicazione all’interno del team con una certa integrazione con i processi automatizzati e, talvolta, con i bot.
• Strumenti di test: un ampio spettro di strumenti che supportano la gestione dei dati di test, la progettazione dei test, i framework per i test unitari, l’esecuzione dei test funzionali, i test delle prestazioni e del carico, i test statici, la progettazione dei test, la gestione del processo di test, i casi di test, la registrazione e la reportistica dei test.
• Strumenti di gestione DevOps o dell’infrastruttura: supportano la gestione degli ambienti e delle piattaforme, la distribuzione tramite infrastruttura come codice e tecnologie container, nonché la registrazione, il monitoraggio e l’analisi in produzione.

The Tools Knowledge Base è un registro online degli strumenti che si differenzia dalla maggior parte dei registri online perché il suo ambito comprende collaborazione, test e DevOps. Sono presenti oltre 1700 strumenti distribuiti in queste tre aree. Le pagine web degli strumenti sono indicizzate e ricercabili.

Il sito aggrega e indicizza inoltre oltre 300 blogger e più di 52.000 blog, anch’essi indicizzati e ricercabili. Abbiamo fornito gli URL delle principali categorie di strumenti e collegamenti rapidi per effettuare ricerche in queste categorie all’interno dei blog.

Sono disponibili oltre 1700 strumenti che supportano la collaborazione, i test e DevOps.

Più avanti in questo articolo analizzeremo le principali problematiche che riguardano e supportano la gestione dei test.

UNISCITI ALLA COMUNITÀ

Arricchisci la tua casella di posta con più saggezza sulla leadership tecnologica per offrire software e sistemi migliori.

Create Free Account

Have an account? Log In

Architettura degli strumenti

Nel grafico seguente abbiamo identificato la gamma di tipi di strumenti utilizzati dalla maggior parte dei team software moderni. Abbiamo separato gli strumenti che tendono a essere utilizzati negli ambienti di sviluppo, test e produzione. 

Questi strumenti si basano su strumenti di infrastruttura che forniscono piattaforme, macchine virtuali e container per ospitare gli ambienti, oltre a strumenti che eseguono distribuzioni automatizzate. Gli strumenti utilizzati per gestire le distribuzioni e i rilasci sono chiamati strumenti di orchestrazione dei rilasci e delle pipeline. Le comunicazioni all’interno del team, così come quelle con molti processi automatizzati, sono gestite da strumenti di collaborazione o ChatOps.

Sebbene il passaggio verso DevOps stia guidando lo sviluppo e l’adozione di strumenti a supporto dello sviluppo continuo, quasi tutti questi strumenti sono utili a qualsiasi team di sviluppo software o operativo.

Non è necessario adottare una cultura DevOps per utilizzare gli strumenti “DevOps”.

Gestione dei test

Gli strumenti di gestione dei test sono indispensabili in tutti i progetti di una certa portata. I progetti Agile di solito adottano uno strumento per la gestione degli incidenti e, per quanto riguarda i test, fanno affidamento in parte sull'uso di storie e scenari aziendali per tenere traccia degli esempi chiave di tutti i test, o almeno della maggior parte di essi. Gli strumenti di gestione dei test variano per portata, da soluzioni molto semplicistiche, come Microsoft Excel, a completi prodotti di gestione del ciclo di vita delle applicazioni (ALM).

In generale, l'ambito degli strumenti di gestione dei test comprende diverse aree:

Modello di copertura dei test: la maggior parte degli strumenti di gestione dei test consente di definire un insieme di requisiti ai quali associare casi di test e/o verifiche nei test. Questi requisiti possono talvolta essere gerarchici, per riflettere l'indice di un documento. Sempre più spesso è possibile acquisire anche altri modelli, come casi d'uso o flussi di processo aziendale. Di solito sono disponibili report sulla copertura della pianificazione e dell'esecuzione dei test.

Gestione dei casi di test: i casi di test e il loro contenuto possono essere gestiti per fornire una registrazione documentata dei test. Il contenuto dei casi di test può essere preparato prima dell'esecuzione dei test oppure fungere da registrazione dei test eseguiti. I casi di test possono essere in formato di testo libero o strutturati in passaggi con risultati attesi. È comune importare documenti e immagini da archiviare insieme ai test o ai singoli passaggi.

Pianificazione dell'esecuzione dei test: i test possono essere strutturati in una gerarchia o contrassegnati con tag per fornire una struttura più dinamica. Ai membri del team di test possono essere assegnati dei test. Le durate pianificate dei test possono essere utilizzate per pubblicare una pianificazione sincronizzata dei test da eseguire nell'intero team. È possibile selezionare sottoinsiemi di test per soddisfare la copertura dei requisiti, verificare funzionalità specifiche e rieseguire insiemi di test di regressione. È inoltre possibile selezionare per l'esecuzione test registrati come non ancora eseguiti, bloccati, non riusciti o con un altro stato.

Esecuzione e registrazione dei test: man mano che il team esegue i test, ne viene registrato lo stato. Per ogni test eseguito vengono identificati il tester e la data/ora, oltre alla durata. Ai test superati può essere assegnato un semplice stato di superamento. Ai risultati dei test non riusciti, bloccati o anomali possono essere associati schermate, risultati dei test e un rapporto sull'incidente. Molti strumenti forniscono collegamenti a strumenti di esecuzione dei test che gestiscono ed eseguono i test, registrano i risultati e creano persino bozze di rapporti sugli incidenti.

Gestione degli incidenti: gli errori dei test vengono registrati nel registro di esecuzione. Di solito richiedono ulteriori indagini, con attività di debug e correzione quando l'errore è stato causato da un bug. Gli errori che richiedono un'indagine vengono normalmente registrati utilizzando rapporti di incidente, osservazione o rapporti sui bug. I rapporti sugli incidenti possono contenere una grande quantità di informazioni di supporto. Di solito, agli incidenti vengono assegnati un tipo, un oggetto sottoposto a test, una priorità e una gravità. Alcune aziende registrano un'enorme quantità di informazioni e la associano a un sofisticato processo di gestione degli incidenti.

Reportistica: report e analisi dei dati provenienti da tutte le funzionalità sopra descritte, quando appropriato. La gamma di report varia dalla copertura dei test pianificata rispetto a quella effettiva, allo stato dei rapporti sugli incidenti per monitorare le attività di indagine, correzione e ripetizione dei test ancora da svolgere, fino alle analisi del tempo necessario per correggere i vari tipi di errore, per funzionalità, gravità e urgenza, e così via.

Lo strumento di gestione dei test più diffuso al mondo è ancora Microsoft Excel.

Progettazione dei test

La progettazione dei test si basa sui modelli. Nel caso dei tester di sistema e di accettazione, i modelli tipici sono i documenti dei requisiti, i casi d'uso, i diagrammi di flusso o i diagrammi a corsie. Anche modelli più tecnici, come modelli di stato, diagrammi di collaborazione, diagrammi di sequenza e così via, costituiscono una solida base per la progettazione dei test.

In molti progetti, i modelli vengono utilizzati per acquisire i requisiti o i progetti di alto livello. Quando sono messi a disposizione dei tester, possono essere utilizzati per tracciare i percorsi e selezionare direttamente dal modello gli elementi di copertura. Se modelli di questo tipo non sono disponibili, spesso è utile che il team di test acquisisca, ad esempio, diagrammi di flusso dei processi o diagrammi a corsie. Questi aiutano i tester ad avere discussioni più significative con gli stakeholder, soprattutto per quanto riguarda l'approccio alla copertura.

Nell'ambito dei prodotti proprietari stanno emergendo strumenti che consentono di acquisire modelli, come i diagrammi di flusso, e di utilizzarli per generare casi di test tracciando percorsi in base a un determinato obiettivo di copertura, ad esempio tutti i collegamenti, tutti i processi, tutti gli esiti decisionali, tutte le coppie e tutti i percorsi. Questi strumenti possono essere collegati a strumenti di gestione e generazione dei dati di test per generare combinazioni di dati di test da utilizzare con test manuali o automatizzati.

Esistono anche strumenti che consentono di eseguire la modellazione negli strumenti di esecuzione dei test. Ad esempio, questi strumenti consentirebbero allo sviluppatore dei test di acquisire tutti i campi di una pagina web, creare collegamenti per “unire” i campi e creare un modello di navigazione per la pagina, il tutto in formato grafico.

Il modello viene quindi utilizzato per creare percorsi di navigazione e realizzare una suite di test che soddisfi determinati criteri di copertura, proprio come negli strumenti di modellazione descritti sopra. Questi strumenti di esecuzione possono creare percorsi di test automatizzati utilizzando criteri selezionati oppure generarli casualmente, oltre a produrre report sulla copertura rispetto a questi modelli.

Questo è attualmente un ambito dinamico: è opportuno tenere d'occhio gli strumenti di modellazione che supportano la progettazione e la generazione dei test e gli strumenti di esecuzione che supportano la modellazione del sistema sottoposto a test, la selezione automatizzata dei percorsi di test e la relativa reportistica.

More Articles

• Ciclo di vita dei test del software: fasi, strumenti e migliori pratiche
• Progettazione dei Test: Una Competenza Fondamentale per il QA
• 5 vantaggi dei test Shift-Left per ridurre i costi oggi stesso

Proprietario o a codice aperto?

Negli ultimi vent'anni, l'uso di prodotti software gratuiti e open source (FOSS), soprattutto per eseguire 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 di Windows, fa sì che, in molti ambienti, Linux/Unix sia il sistema operativo preferito per i server. 

Sebbene l'articolo analizzi i pro e i contro degli strumenti open source e proprietari, se stai cercando specificamente soluzioni che si integrino bene con Jira, la nostra guida completa agli strumenti di gestione dei test specifici per Jira può aiutarti a prendere una decisione informata.

Le due tabelle seguenti (aggiornate quotidianamente su w3techs.com) mostrano la popolarità relativa dei sistemi operativi e dei prodotti per server web. Circa l'85% dei siti utilizza i prodotti open source per server web più conosciuti, Apache e Nginx.

La popolarità di questi prodotti infrastrutturali FOSS dimostra che l'open source può essere affidabile quanto, se non più, dei prodotti proprietari.

Per un team software che necessita di venti o trenta strumenti software per supportare le proprie attività, esistono strumenti FOSS e proprietari affidabili e funzionali per svolgere ogni attività. Come si sceglie tra un prodotto proprietario e uno FOSS?

La tabella seguente riassume alcune delle considerazioni che potresti fare nella scelta del tipo di strumento.

	Proprietario	FOSS
Disponibilità	Strumenti disponibili per ogni ambito.	Alcuni ambiti, in particolare gli strumenti di sviluppo e infrastrutturali, sono supportati meglio di altri.
Costo di acquisto	Spesso costosi, in particolare i prodotti «enterprise».	Gratuiti oppure con licenza per uso comunitario a costo zero. Possono esistere licenze commerciali per le versioni enterprise o ospitate.
Documentazione	Di solito molto buona.	Variabile. A volte eccellente, a volte inesistente, con tutte le situazioni intermedie. Spesso scritta da programmatori per programmatori, quindi meno utilizzabile della documentazione commerciale.
Supporto tecnico	Molto buono, a pagamento.	Variabile. Alcuni autori degli strumenti forniscono un supporto eccellente e aggiungono persino funzionalità su richiesta. Molti strumenti dispongono di forum online, ma possono essere molto tecnici. Altri strumenti sono supportati poco.
Affidabilità/qualità	Di solito molto buona.	Variabile. I prodotti con molti utenti, impostazioni locali e grandi team di supporto tendono a essere eccellenti. Alcuni strumenti scritti da singoli sviluppatori, con pochi collaboratori e pochi utenti, possono essere instabili.
Ricchezza delle funzionalità	I set di funzionalità tendono a seguire le roadmap di prodotto pubblicate e sono generalmente completi.	I prodotti tendono a evolversi in base alla domanda degli utenti e alle dimensioni del team di collaboratori. I collaboratori tendono ad aggiungere le funzionalità di cui hanno bisogno, invece di basarsi, per esempio, sui sondaggi tra i clienti.
Frequenza di rilascio/patch	I rilasci principali tendono a essere distanziati di mesi, talvolta di anni. Rilasci regolari di patch. Gli avvisi e le note di rilascio tendono a essere molto buoni.	Variabile. I rilasci principali dei grandi prodotti infrastrutturali sono simili a quelli dei prodotti proprietari. I prodotti più piccoli e meno popolari tendono a essere rilasciati più frequentemente. Avvisi scarsi o assenti, note di rilascio carenti e, occasionalmente, perdita della compatibilità con le versioni precedenti.

I prodotti FOSS possono essere più economici da ottenere, ma gli altri costi e le responsabilità possono essere significativi. Il fattore decisivo tra i due è solitamente un insieme di cultura aziendale, propensione al rischio e capacità tecnica.

Quando acquisti prodotti proprietari e contratti di supporto, i rischi associati all'incompatibilità (con altri prodotti), all'affidabilità, alla facilità d'uso e a un supporto tecnico attento sono generalmente bassi, anche se talvolta costosi.

Con i prodotti FOSS, di solito devi svolgere una ricerca molto più approfondita prima di impegnarti a utilizzarne uno. Dopotutto, non c'è un commerciale con cui parlare e la documentazione può essere funzionale, anziché informativa. Naturalmente, è facile configurare un periodo di prova e puoi adottare tutti gli strumenti che desideri, ma dovrai svolgere un'indagine più completa sulle capacità dello strumento. 

Una scarsa usabilità e l'incompatibilità con gli strumenti esistenti potrebbero causare problemi, quindi potresti dover scrivere software di interfacciamento o plug-in e utilità per la reportistica o per l'importazione/esportazione dei dati. 

Inoltre, dovrai formare te stesso e il team per portarli al livello necessario e, di solito, occuparti personalmente del supporto software. Tuttavia, il tuo team avrà una conoscenza più approfondita del funzionamento dello strumento e sarà in gran parte autonomo nel supporto.

Uno strumento FOSS potrebbe aiutarti a fare esperienza con un nuovo tipo di strumento a costi contenuti. Grazie a questa esperienza, sarai in una posizione migliore per scegliere uno strumento proprietario a lungo termine.

Un esercizio di selezione degli strumenti

Se stai cercando uno strumento di gestione dei test a supporto del tuo progetto e della tua applicazione attuali, oppure di un progetto e di un'applicazione recenti che conosci bene, in base alle aree funzionali discusse sopra sugli strumenti di gestione dei test, crea un elenco di 15-20 funzionalità che siano:

• Obbligatorie
• Desiderabili

L'elenco può includere funzionalità operative, integrazioni, particolare attenzione alla facilità d'uso, all'assistenza o a un'ampia base di utenti, oppure a forum online/FAQ. Se hai già uno strumento in uso, non scegliere quello.

Utilizzando il testo dei tuoi requisiti, cerca nel Tools Knowledge Base tre strumenti (incluso un prodotto proprietario e uno FOSS) che sembrino corrispondere ai tuoi requisiti. Utilizzando le descrizioni delle funzionalità degli strumenti, crea una tabella comparativa delle funzionalità dei tre prodotti. Aggiungi una quarta colonna per lo strumento che stai effettivamente utilizzando, a fini di confronto.

• Come si posizionano gli strumenti in termini di funzionalità?
• Quali funzionalità mancano agli strumenti FOSS rispetto agli strumenti proprietari?
• Quanti strumenti esistono che soddisfano in larga misura i tuoi requisiti?
• Quanto tempo pensi che dovresti dedicare alla ricerca degli strumenti per stilare una rosa ristretta, ad esempio, di tre strumenti?

Iscriviti alla newsletter di The QA Lead per ricevere una notifica quando saranno pubblicate nuove parti della serie. Questi articoli sono estratti dal corso Leadership nei test di Paul, che consigliamo vivamente a chi desidera approfondire questo e altri argomenti. Se lo fai, utilizza il nostro codice coupon esclusivo QALEADOFFER per ottenere uno sconto di $60 sul prezzo intero del corso!

Impara dai tuoi colleghi addetti ai test ascoltando i nostri podcast o consultando i nostri blog. Ecco un articolo dal quale pensiamo imparerai moltissimo: COME LE COMPETENZE DI TEST MI HANNO RESO UN MIGLIOR SVILUPPATORE DI AUTOMAZIONE DEI TEST