Scenari di test sbandierati spesso come strategici per una efficace programmazione del software. Ma cosa fanno esattamente? E in che modo i team possono garantire siano efficaci? In questo articolo, gli esperti approfondiscono tutti i dettagli tecnici di una programmazione agile.
Scenari di test: a cosa servono
Identificare e sviluppare scenari di test è una delle componenti più critiche di qualsiasi strategia di programmazione. In estrema sintesi, è necessario analizzare, mappare e descrivere quali componenti, funzioni, interfacce o altri componenti dell’applicazione che verranno testati dal team. Queste informazioni costituiscono poi le basi per la produzione di tutta la documentazione associata alle procedure di test.
Scenari di test e casi di prova: differenze e relazioni
Gli scenari di test e i test case vengono frequentemente discussi insieme ed entrambi accelerano i processi di Quality Assurance. L’importante è non confonderli: ciascuno di essi, infatti, svolge un ruolo diverso rispetto alle attività di test manuali e automatizzate.
- Che cosa sono gli scenari di test: sviluppati in base ai requisiti aziendali e di sistema, gli scenari di test rappresentano la documentazione di alto livello relativa a ciò che i professionisti del controllo qualità andranno a testare, descrivendo sia la funzionalità che il modo in cui l’utente eseguirà la funzione.
- Che cosa sono i test case: si tratta di specifiche tecniche che forniscono una documentazione dettagliata delle procedure di test dell’applicazione, includendo un elenco dei risultati previsti. I professionisti del controllo qualità possono eseguire i test case manualmente o svilupparli in script automatizzati.
Mentre i test case costituiscono la struttura di codifica che i team di controllo qualità utilizzeranno per creare script di test automatizzati, gli scenari di test aiutano gli stessi team a determinare quali test specifici automatizzare.
Come creare scenari di test efficaci
Generalmente i team mettono insieme scenari di test utilizzando una combinazione di storie degli utenti e criteri di accettazione degli utenti. Tuttavia, gli scenari di test possono anche derivare da una modellizzazione delle persone, che fungono da profilo generale dei comportamenti degli utenti previsti e delle esigenze previste. Ad esempio, persone ben sviluppate possono aiutare i team a creare scenari di test incentrati sulle funzionalità che ritengono più importanti per la stragrande maggioranza degli utenti.
Il ruolo di Gherkin nello sviluppo dei test automatizzati
La programmazione guidata dal comportamento (BDD – Behavior-Driven Development) può essere un altro approccio molto produttivo. Il BDD inserisce il lato aziendale nel processo di sviluppo, ma continua a concentrarsi sul comportamento previsto dell’utente. Nel caso di Cucumber (uno strumento software che supporta lo sviluppo basato sul comportamento Ndr), il parser del linguaggio ordinario, chiamato Gherkin, consente di specificare i comportamenti software previsti in modo estremamente intuitivo. La sintassi Gherkin, infatti, ha una struttura semplice e chiara che, utilizzando la formula Given-When-Then, può essere facilmente compresa sia dagli sviluppatori che dal personale aziendale. Grazie al supporto del framework di test Cucumber BDD, Gherkin semplifica lo sviluppo degli script a supporto dei test automatizzati.
Pianificazione di una strategia di test
Una volta che un team ha identificato i propri scenari di test, è il momento di creare una vera e propria strategia finalizzata a determinare gli scenari specifici che il team di controllo qualità testerà manualmente rispetto a quelli schedulati in automatico. Affinché le decisioni risultino efficaci, questo lavoro deve essere svolto all’inizio del processo di sviluppo. La pianificazione di una strategia di test presuppone l’identificazione del dominio di svolgimento. Ad esempio, alcuni requisiti normativi possono determinare tipi di scenari che il team seleziona ed esegue con livelli di dettaglio sia delle procedure di test che della documentazione corrispondente. Un altro fattore rilevante da considerare potrebbero essere le metodologie utilizzate e la loro relativa maturità.
Test automatizzati vs test manuali
Oggi l’automazione è diventata sempre più integrata nelle strategie di test. Ma non tutti gli scenari di test possono essere automatizzati. Anche quando si unisce un processo di test continuo automatizzato in una pipeline CI/CD, i team di controllo qualità devono comunque eseguire manualmente alcune procedure come, ad esempio, i test GUI incentrati sull’UX. E mentre i test case che si svolgono su lunghi periodi di tempo possono essere complessi da automatizzare, un investimento nella manodopera per lo sviluppo di scenari di test manuali accelererà notevolmente i processi di QA su tutta la linea.
Come sottolineano gli esperti, è fondamentale che i team scelgano attentamente gli scenari di test da risolvere manualmente. Di seguito, alcuni esempi di scenari di test appropriati per il test manuale:
- test di convalida per l’UX
- test di verifica per funzionalità a bassa priorità
- test per casi di edge computing non di produzione
- tutti i test che dipendono fortemente dal giudizio di un ingegnere di test
Quando conviene automatizzare gli scenari di test
Gli scenari di test possono essere automatizzati quando le funzionalità critiche richiedono test ripetitivi o sono semplicemente troppo difficili da gestire manualmente. Ad esempio, i test che coinvolgono grandi volumi di dati o complesse procedure di immissione dei dati spesso si adattano ad essere automatizzati.
La piramide dell’automazione dei test
Una tecnica estremamente utile per orientare i criteri di scelta è la piramide agile dell’automazione dei test.
Il modello impone che l’automazione venga applicata principalmente a livello di test delle unità e dei componenti che essendo generalmente meno complessi sono anche i più facili da automatizzare.
Per inciso, un elevato livello di copertura dei test unitari può aiutare i team a rilevare i difetti e a implementare soluzioni correttive nelle prime fasi del processo di sviluppo.
I test a livello di GUI, invece, risiedono in cima alla piramide dell’automazione dei test perché sono quelli più difficili da mantenere. Questo è il motivo per cui è meglio ridurre al minimo l’automazione dei test GUI, se non in presenza di componenti poco complessi.
Test di scenario: quali membri del team devono essere coinvolti
La scelta degli scenari di test per l’automazione dovrebbe essere un lavoro di squadra che include:
- test lead
- specialisti dell’automazione
- SDET (Software Development Engineers in Test)
- sviluppatori
- proprietari di prodotti
I proprietari dei prodotti sono particolarmente importanti in quanto sono qualificati in modo univoco per evidenziare scenari di simulazione più accurati rispetto al flusso di lavoro dell’utente nel mondo reale. Anche gli sviluppatori giocando un ruolo importante nell’evidenziare gli scenari che richiedono test su raccolte di codice complesse.
