Leadership nei Test: Strumenti di Testing
Nota dell'Editore: Benvenuti nella serie Leadership In Test dal guru del testing software e consulente Paul Gerrard. La serie è pensata per aiutare i tester con qualche anno di esperienza—soprattutto quelli in team agili—a eccellere nei loro ruoli di test lead e management.
Nell'articolo precedente, abbiamo analizzato 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 un rapido esercizio di selezione degli strumenti.
Iscriviti alla newsletter The QA Lead per ricevere notifiche quando le nuove parti della serie saranno online. Questi post sono estratti dal corso Leadership In Test di Paul, che consigliamo vivamente per approfondire questo e altri argomenti. Se decidi di seguirlo, usa il nostro codice coupon esclusivo 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 team software tipico, potrebbero esserci in uso venti o anche trenta tool. Per aiutarti a orientarti in tutto questo, in questo articolo tratteremo:
- Strumenti per il testing
- Architettura degli strumenti
- Gestione dei test
- Progettazione dei test
- Proprietario o open source?
- Esercizio di selezione degli strumenti
Per prima cosa, diamo un'occhiata ai principali tipi di strumenti che utilizzerai per il testing.
Strumenti per il testing
È comodo suddividere gli strumenti rilevanti per il testing in tre tipologie:
Vuoi di più da The CTO Club?
Crea un account gratuito per completare questo articolo e unirti a una comunità di CTO e leader ingegneristici che condividono framework, strumenti e approfondimenti reali per progettare, implementare e scalare tecnologie guidate dall'IA.
Have an account? Log In
- Strumenti di collaborazione: supportano la raccolta di idee e requisiti, la comunicazione all'interno del team con una certa integrazione con processi automatizzati e talvolta con bot.
- Strumenti di testing: un ampio spettro di strumenti che supportano la gestione dei dati di test, la progettazione dei test, framework per i test unitari, l'esecuzione di test funzionali, prove di carico e prestazioni, test statici, progettazione dei test, gestione del processo di test, casi di test, registrazione e reportistica dei test.
- Strumenti DevOps o per la gestione dell'infrastruttura: questi strumenti supportano la gestione degli ambienti e delle piattaforme, il deployment usando infrastruttura come codice e tecnologie container, oltre al logging, monitoraggio e analisi in produzione.
The Tools Knowledge Base è un registro online per strumenti che si distingue dalla maggior parte degli altri registri online perché la sua portata abbraccia collaborazione, testing e DevOps. Include oltre 1700 strumenti tra queste tre aree. Le pagine web degli strumenti sono indicizzate e sono ricercabili.
Il sito aggrega e indicizza anche oltre 300 blogger e oltre 52.000 blog sono anch'essi indicizzati e ricercabili. Abbiamo fornito gli URL per le categorie principali degli strumenti e scorciatoie per le ricerche di queste categorie nei blog.
Ci sono oltre 1700 strumenti che supportano collaborazione, testing e DevOps.
Analizzeremo più avanti in questo articolo le maggiori questioni che influenzano e supportano la gestione dei test.
Architettura degli strumenti
Nell'immagine sottostante, abbiamo identificato l'insieme di tipologie di strumenti che la maggior parte dei team software moderni utilizza. Abbiamo separato gli strumenti che tendono ad essere usati negli ambienti di sviluppo, testing e produzione.
Questi strumenti sono supportati da strumenti di infrastruttura che forniscono piattaforme, macchine virtuali e container per ospitare gli ambienti, e strumenti che eseguono il deployment automatico. Gli strumenti usati per gestire deployment e release sono chiamati strumenti di orchestrazione della pipeline e del rilascio. Le comunicazioni all'interno del team, e anche con molti dei processi automatizzati, sono gestite da strumenti di collaborazione o ChatOps.
Sebbene la spinta verso DevOps stia guidando lo sviluppo e l'adozione di strumenti di supporto allo sviluppo continuo, quasi tutti questi strumenti sono utili a qualsiasi team di sviluppo o operations software.
Non è necessario avere una cultura DevOps per utilizzare strumenti "DevOps".
Gestione dei test
Gli strumenti di gestione dei test sono indispensabili in tutti i progetti di una certa dimensione. I progetti Agile solitamente adottano un software per la gestione degli incidenti e, per quanto riguarda i test, fanno affidamento anche sull'uso di business stories e scenari per tracciare esempi chiave di test, se non tutti. Gli strumenti di gestione dei test variano in termini di ampiezza: da soluzioni molto semplici, come Microsoft Excel, fino a prodotti completi per la Gestione del Ciclo di Vita delle Applicazioni (ALM).
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 a cui associare casi di test e/o controlli nei test. Questi requisiti possono talvolta essere gerarchici per riflettere un indice di un documento. Sempre più spesso è possibile acquisire anche altri modelli come use case o flussi di processo aziendale. Sono solitamente disponibili report sulla 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 documentazione delle prove effettuate. Il contenuto dei casi di test può essere preparato in anticipo rispetto al testing oppure come traccia dei test eseguiti. I casi di test possono essere in formato testo libero o strutturati in passaggi con risultati attesi. È comune l'importazione di documenti e immagini da allegare ai test o ai singoli passaggi.
Pianificazione dell’esecuzione dei 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 determinati test. Le durate pianificate dei test possono essere utilizzate per pubblicare una programmazione sincronizzata delle prove da eseguire in tutto il team. Può essere selezionato un sottoinsieme di test per coprire determinati requisiti, esercitare funzionalità selezionate o rieseguire set di test di regressione. È anche possibile selezionare test che non sono ancora stati eseguiti, bloccati, falliti o con altro stato.
Esecuzione dei test e logging: Durante lo svolgimento dei test da parte del team, lo stato dei test viene registrato. Ogni test eseguito avrà associato il nome del tester, la data/ora e la durata. I test superati potranno avere semplicemente lo stato Passato. I risultati anomali, bloccati o falliti possono includere screenshot, risultati specifici del test e la creazione di una segnalazione di incidente. Molti strumenti dispongono di collegamenti con strumenti automatici di esecuzione che gestiscono e conducono i test, registrano i risultati ed eventualmente creano bozze di segnalazioni di incidenti.
Gestione degli incidenti: I fallimenti riscontrati vengono annotati nel registro delle esecuzioni. Di norma, questi richiedono ulteriori indagini, inclusi debug e correzioni nel caso la causa sia un bug. Gli errori che necessitano di approfondimenti vengono solitamente registrati tramite segnalazioni di incidenti, osservazioni o bug report. Le segnalazioni di incidenti possono includere molte informazioni di supporto. Generalmente, a ciascun incidente sono associati la tipologia, l’oggetto testato, la priorità e la gravità. Alcune aziende tengono traccia di un’enorme quantità di dati e li integrano in processi di gestione degli incidenti molto sofisticati.
Reportistica: Report e analisi dei dati di tutte le funzionalità sopra descritte, dove opportuno. L’ampiezza dei report può variare: dalla copertura pianificata vs. quella effettiva, allo stato delle segnalazioni per tracciare attività di analisi, risoluzione e re-test, passando per l’analisi dei tempi di risoluzione per vari tipi di malfunzionamenti, per funzionalità, gravità, urgenza e così via.
Lo strumento di gestione dei test più popolare al mondo è ancora Microsoft Excel.
Progettazione dei Test
La progettazione dei test si basa su modelli. Nel caso dei test di sistema e di accettazione, i modelli tipici sono documenti dei requisiti, use case, flowchart o diagrammi swim-lane. Modelli più tecnici come diagrammi di stato, diagrammi di collaborazione, diagrammi di sequenza e simili rappresentano anch’essi un solido punto di partenza per la progettazione dei test.
In molti progetti, i modelli vengono utilizzati per raccogliere requisiti o progetti di alto livello. Se vengono messi a disposizione dei tester, possono essere impiegati per tracciare i percorsi e individuare direttamente gli elementi di copertura. Nel caso questi modelli non fossero 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, specialmente riguardo l’approccio alla copertura.
Nell’ambito dei software proprietari, stanno emergendo strumenti che consentono di catturare modelli come i diagrammi di flusso e di utilizzarli per generare casi di test tracciando percorsi secondo un target di copertura specifico (ad esempio tutti i collegamenti, tutti i processi, tutti gli esiti delle decisioni, tutte le coppie e tutti i percorsi). Questi strumenti possono essere collegati a strumenti per la gestione e creazione di dati di test al fine di generare combinazioni di dati da utilizzare in test manuali o automatici.
Esistono anche strumenti che permettono la modellazione direttamente negli strumenti di esecuzione dei test. Ad esempio, tali strumenti consentono allo sviluppatore dei test di catturare tutti i campi di una pagina web, creare collegamenti tra i campi e realizzare un modello di navigazione della pagina, il tutto in formato grafico.
Il modello viene quindi utilizzato per creare percorsi di navigazione e generare una suite di test che soddisfino determinati criteri di copertura, proprio come avviene con gli strumenti di modellazione sopra menzionati. Questi strumenti di esecuzione sono in grado di creare percorsi di test automatici secondo criteri scelti, oppure generarne casualmente, e producono report di copertura rispetto a tali modelli.
Questo settore è attualmente molto dinamico: tenete d’occhio sia i tool di modellazione che supportano la progettazione e generazione dei test, sia quelli di esecuzione che permettono la modellazione dei sistemi da testare e la selezione e reportistica automatica dei percorsi di test.
Proprietari o Open Source?
Negli ultimi vent'anni, l'uso di prodotti software gratuiti e open source (FOSS), soprattutto per la gestione dell'infrastruttura, si è diffuso ampiamente. Il costo delle licenze dei sistemi operativi e dei relativi software di server web di Microsoft, unitamente alla visione 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 discuta i pro e i contro degli strumenti open source e proprietari, se stai cercando 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 informata.
Le due tabelle seguenti (aggiornate quotidianamente su w3techs.com) mostrano la popolarità relativa dei sistemi operativi e dei prodotti web server. Circa l'85% dei siti utilizza i più noti server web open source, Apache e Nginx.
La popolarità di questi prodotti FOSS per l'infrastruttura 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 per supportare le proprie attività, esistono strumenti FOSS e proprietari affidabili e funzionali per svolgere qualsiasi compito. Come scegliere tra un prodotto proprietario e uno FOSS?
La tabella seguente riassume alcune delle considerazioni che potresti fare nella selezione di una tipologia di strumento.
| Proprietario | FOSS | |
| Disponibilità | Strumenti disponibili per ogni ambito. | Alcuni ambiti, in particolare quelli di sviluppo e infrastrutturali, sono meglio supportati rispetto ad altri. |
| Costo di acquisto | Spesso costosi, soprattutto i prodotti “enterprise”. | Gratuiti o con licenza ad uso comunitario a costo zero. Per le versioni enterprise o in cloud possono esistere licenze commerciali. |
| Documentazione | Di solito molto buona. | Variabile. Talvolta eccellente, talvolta inesistente o tutto quello che c'è in mezzo. Spesso scritta da programmatori per programmatori, quindi meno fruibile rispetto alla documentazione commerciale. |
| Supporto tecnico | Molto buono, ma a pagamento. | Variabile. Alcuni autori di strumenti forniscono supporto eccellente e in alcuni casi aggiungono funzionalità su richiesta. Molti strumenti offrono forum online – spesso molto tecnici. Altri strumenti sono scarsamente supportati. |
| Affidabilità/qualità | Di solito molto buona. | Variabile. I prodotti con molti utenti, in più lingue e un ampio team di supporto tendono ad essere eccellenti. Strumenti sviluppati da singoli, con pochi contributori e pochi utenti, possono essere instabili. |
| Ricchezza di funzionalità | Il set di funzionalità segue solitamente le roadmap pubblicate e sono generalmente complete. | I prodotti tendono ad evolvere in base alla domanda degli utenti e alla dimensione del team di contributori. I contributori, ad esempio, aggiungono le funzionalità di cui hanno bisogno piuttosto che basarsi su sondaggi tra i clienti. |
| Frequenza di rilascio/patch | Le versioni principali tendono ad essere rilasciate ogni mesi o anche anni. Patch regolari. Le indicazioni e le note di rilascio sono generalmente molto buone. | Variabile. I principali prodotti infrastrutturali rilasciano importanti versioni – come quelli proprietari. I prodotti più piccoli o meno popolari tendono a rilasciare più frequentemente. Scarse o assenti le segnalazioni, note di rilascio povere e talvolta perdita della compatibilità con versioni precedenti. |
I prodotti FOSS possono essere più economici da acquisire, ma altri costi e responsabilità possono essere significativi. Il fattore decisivo tra i due dipende solitamente dal mix di cultura aziendale, propensione al rischio e capacità tecnica.
Quando acquisti prodotti proprietari e contratti di supporto, i rischi associati a incompatibilità (con altri prodotti), affidabilità, facilità d'uso e supporto tecnico attento sono generalmente bassi, sebbene a volte costosi.
Con i prodotti FOSS di solito devi fare ricerche molto più approfondite prima di impegnarti ad adottarne uno. In fin dei conti, non esiste un commerciale con cui parlare e la documentazione può essere funzionale più che informativa. Naturalmente, è facile impostare un periodo di prova e puoi adottare tutti gli strumenti che vuoi, ma dovrai valutare più attentamente le capacità dello strumento.
Peggiore usabilità e incompatibilità con i tuoi strumenti esistenti potrebbero creare problemi, e potresti dover sviluppare software di interfacciamento o plug-in, e utility per reportistica o import/export dei dati.
Inoltre, dovrai formare te stesso e il team per portarli rapidamente a regime e, di solito, occuparti autonomamente del supporto software. Tuttavia, il tuo team avrà una conoscenza più approfondita del funzionamento dello strumento e sarà ampiamente autosufficiente.
Uno strumento FOSS potrebbe aiutarti a fare esperienza con una nuova tipologia di strumento a basso costo. Con questa esperienza, sarai più preparato a scegliere uno strumento proprietario per il lungo termine.
Un esercizio di selezione di strumenti
Se stai cercando uno strumento di gestione dei test per supportare il tuo progetto attuale o uno recente con cui hai familiarità. Basandoti sulle aree di funzionalità discusse sopra riguardo agli strumenti di gestione dei test, fai un elenco di 15-20 caratteristiche che siano:
- Obbligatorie
- Desiderabili
Queste possono includere capacità funzionali, integrazioni, un’attenzione alla facilità d’uso, il supporto o una vasta base di utenti oppure forum/FAQ online. Se hai già uno strumento in uso, non scegliere quello.
Utilizzando il testo dei tuoi requisiti, cerca nella Knowledge Base degli Strumenti per trovare tre strumenti (includendo sia un prodotto proprietario che uno FOSS) che sembrano soddisfare i tuoi requisiti. Usando le descrizioni delle funzionalità degli strumenti, crea una tabella comparativa delle caratteristiche dei tre prodotti. Aggiungi una quarta colonna per lo 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 soddisfano in modo ampio i tuoi requisiti?
- Quanto tempo pensi di dover dedicare alla ricerca degli strumenti per stilare una short list di, diciamo, tre soluzioni?
Iscriviti alla newsletter di The QA Lead per essere avvisato quando saranno pubblicate le nuove parti della serie. Questi post sono estratti dal corso Leadership In Test di Paul: altamente consigliato per chi desidera approfondire questo e altri argomenti. Se decidi di farlo, usa il nostro coupon esclusivo QALEADOFFER per ottenere $60 di sconto sul prezzo intero del corso!
Impara dagli altri tester ascoltando i nostri podcast o leggendo i nostri blog. Ecco un contenuto da cui pensiamo tu possa imparare molto: COME LE COMPETENZE DI TESTING MI HANNO RESO UN MIGLIOR AUTOMATION DEVELOPER
