Che cosa sono i test funzionali?
In questa sezione si collaborerà con il team di Tailspin per definire i test funzionali per la sua pipeline. I test funzionali verificano che ogni funzione del software esegua le operazioni previste.
Il team definisce innanzitutto l'ambito di applicazione di un test funzionale. Prende in esame alcuni tipi di test funzionali. Decide quindi di aggiungere il primo test alla propria pipeline.
Riunione settimanale
Il team sta svolgendo la riunione settimanale. Andy sta presentando la pipeline di versione. Il team osserva il percorso di una build di buon livello lungo la pipeline, da una fase a un'altra. Infine, l'app Web viene promossa alla fase Staging.
Amita: Sono molto soddisfatta della pipeline. Mi è di grandissimo aiuto. Ad esempio, una versione viene distribuita automaticamente nell'ambiente di test. Non devo scaricare e installare manualmente gli artefatti della compilazione nei server di test. Per me è un notevole risparmio di tempo.
Inoltre, gli unit test scritti da Mara e Andy eliminano tutti i bug di regressione prima che io riceva la versione. Questo elimina un grande motivo di frustrazione. Non devo dedicare tempo a cercare e documentare i bug di regressione.
Ma temo che tutti i miei test siano ancora manuali. Il processo è lento e non possiamo mostrare nulla alla dirigenza finché io non ho finito. È difficile perché i test sono importanti. I test garantiscono che gli utenti ottengano l'esperienza corretta. Ma i tempi sono sempre molto stretti.
Andy: Possiamo aiutarti senza dubbio. Quali tipi di test richiedono più tempo?
Amita: Credo che siano i test dell'interfaccia utente. Devo fare clic su ogni passaggio per assicurarsi di ottenere il risultato corretto e devo farlo per ogni browser che supportiamo. Si tratta di un lavoro molto lungo. Inoltre, man mano che il sito Web diventa più complesso, i test dell'interfaccia utente saranno sempre meno praticabili sul lungo periodo.
Mara: I test dell'interfaccia utente sono considerati test funzionali.
Tim: Rispetto a cosa, ai test non funzionali?
Mara: Esattamente. E i test non funzionali sono molto importanti, soprattutto per te.
Tim: Bene, sono confuso.
Che cosa sono i test funzionali e non funzionali?
Mara: I test funzionali verificano che ogni funzione del software esegua le operazioni previste. Il modo in cui il software implementa ogni funzione non è rilevante in questi test. Ciò che conta è che il software si comporti correttamente. Si fornisce un input e si verifica che l'output sia quello previsto. È così che Amita testa l'interfaccia utente. Ad esempio, se seleziona il giocatore in vetta al tabellone punteggi, si aspetta di visualizzare il profilo di quel giocatore.
I test non funzionali controllano determinati aspetti come le prestazioni e l'affidabilità. Un esempio di test non funzionale è la verifica del numero di persone che possono accedere contemporaneamente all'app. Il test di carico è un altro esempio di test non funzionale. Quei problemi di prestazioni e affidabilità sono particolarmente importanti per te, Tim.
Tim: Sì, decisamente. Devo rifletterci un attimo. Mi sarebbe utile un certo livello di automazione della pipeline, ma non so bene cosa posso fare. Quali tipi di test automatizzati posso eseguire?
Mara: Per il momento, concentriamoci sui test funzionali. Sono i tipi di test che esegue Amita. E sembra che sia un'area da migliorare.
Quali tipi di test funzionali posso eseguire?
Esistono molti tipi di test funzionali. Variano in base alle funzionalità da testare e al tempo o al lavoro generalmente richiesto per l'esecuzione.
Le sezioni seguenti illustrano alcuni test funzionali di uso comune.
Test di verifica della compilazione
I test di verifica della compilazione verificano le funzionalità di base dell'applicazione o del servizio. Questi test vengono spesso eseguiti prima di test più completi ed esaustivi. I test di verifica della compilazione dovrebbero essere eseguiti rapidamente.
Si supponga, ad esempio, di sviluppare un sito Web. Il test di verifica della compilazione potrebbe usare curl per verificare che il sito sia raggiungibile e che il recupero della home page generi uno stato HTTP 200 (OK). Se il recupero della home page produce un altro codice di stato, ad esempio 404 (Non trovato) o 500 (Errore interno del server), significa che il sito Web non funziona. Significa anche che non c'è motivo per eseguire altri test. Occorre invece diagnosticare l'errore, correggerlo e riavviare i test.
Unit test
Degli unit test si è parlato nel modulo Eseguire test di qualità nella pipeline di compilazione con Azure Pipelines.
Sostanzialmente, gli unit test verificano i componenti fondamentali del programma o della libreria, ad esempio una singola funzione o un metodo. Si specificano uno o più input insieme ai risultati previsti. Il tester esegue ogni test e verifica se i risultati effettivi corrispondono a quelli previsti.
Si supponga ad esempio di avere una funzione che esegue un'operazione aritmetica di divisione. Si potrebbero specificare alcuni valori che si prevede vengano immessi dagli utenti. Si specificano anche i valori edge-case come 0 e -1. Se si prevede che un determinato input generi un errore o un'eccezione, è possibile verificare che la funzione produca tale errore.
I test dell'interfaccia utente che verranno eseguiti più avanti in questo modulo sono unit test.
Test di integrazione
I test di integrazione verificano che più componenti software interagiscano tra loro per formare un sistema completo. Ad esempio, un sistema di e-commerce potrebbe includere un sito Web, un database dei prodotti e un sistema di pagamento. È possibile scrivere un test di integrazione che aggiunga articoli al carrello ed esegua l'acquisto. Il test verifica che l'applicazione Web sia in grado di connettersi al database dei prodotti e quindi evadere l'ordine.
È possibile combinare unit test e test di integrazione per creare una strategia di testing a più livelli. Ad esempio, è possibile eseguire unit test sui singoli componenti prima di eseguire i test di integrazione. Se tutti gli unit test vengono superati, si può passare ai test di integrazione con maggiore sicurezza.
Test di regressione
Una regressione si verifica quando il comportamento esistente cambia o si interrompe dopo l'aggiunta o la modifica di una funzionalità. I test di regressione consentono di stabilire se il codice, la configurazione o altre modifiche influiscono sul comportamento generale del software.
I test di regressione sono importante perché una modifica in un componente può influire sul comportamento di un altro componente. Si immagini, ad esempio, di ottimizzare un database per le prestazioni di scrittura. Le prestazioni di lettura di quel database, gestite da un altro componente, potrebbero calare in modo imprevisto. Il calo delle prestazioni di lettura è una regressione.
È possibile usare diverse strategie per testare la regressione. Queste strategie variano in genere in base al numero di test eseguiti per verificare che una nuova funzionalità o correzione di bug non interrompa le funzionalità esistenti. Con l'automazione dei test, invece, i test di regressione potrebbero comportare semplicemente l'esecuzione di tutti gli unit test e i test di integrazione ogni volta che il software viene modificato.
Test di integrità
Con i test di integrità vengono testati tutti i componenti principali di un software per verificare che il software sia funzionante e possa essere sottoposto a test più completi. È possibile pensare ai test di sanità come meno accurati rispetto ai test di regressione o agli unit test, ma i test di sanità sono più estesi rispetto ai test di fumo.
Sebbene possano essere automatizzati, i test di integrità vengono spesso eseguiti manualmente a seguito di una modifica delle funzionalità o di una correzione di bug. Ad esempio, un tester di software che sta convalidando una correzione di bug potrebbe verificare anche il funzionamento di altre funzionalità inserendo alcuni valori tipici. Se il software sembra funzionare come previsto, può essere sottoposto a test più completi.
Test dell'interfaccia utente
I test dell'interfaccia utente verificano il comportamento dell'interfaccia utente di un'applicazione. I test dell'interfaccia utente consentono di verificare che la sequenza, o l'ordine, delle interazioni utente produca il risultato previsto. Questi test consentono anche di verificare che i dispositivi di input, come la tastiera o il mouse, interagiscano correttamente con l'interfaccia utente. È possibile eseguire test dell'interfaccia utente per verificare il comportamento di un'applicazione Windows, macOS o Linux nativa. oppure per verificare che l'interfaccia utente si comporti come previsto nei Web browser.
Un unit test o un test di integrazione potrebbe verificare che l'interfaccia utente riceva correttamente i dati. I test dell'interfaccia utente, però, consentono di verificare che l'interfaccia utente venga visualizzata correttamente e che il risultato funzioni come previsto per l'utente.
Ad esempio, un test dell'interfaccia utente potrebbe verificare che venga visualizzata l'animazione corretta in risposta al clic su un pulsante. Un secondo test potrebbe verificare che la stessa animazione venga visualizzata correttamente quando la finestra viene ridimensionata.
In questo modulo vengono utilizzati test dell'interfaccia utente codificati manualmente. Tuttavia, è anche possibile usare un sistema di acquisizione e riproduzione per creare automaticamente i test dell'interfaccia utente.
Test di usabilità
Il test di usabilità è un tipo di test manuale che verifica il comportamento di un'applicazione dal punto di vista dell'utente. I test di usabilità vengono in genere eseguiti dal team che compila il software.
Mentre i test dell'interfaccia utente verificano principalmente che una funzionalità si comporti nel modo previsto, i test di usabilità consentono di verificare che il software sia intuitivo e soddisfi le esigenze dell'utente. In altre parole, i test di usabilità consentono di verificare che il software sia "utilizzabile".
Si immagini, ad esempio, di disporre di un sito Web che include un collegamento al profilo dell'utente. Un test dell'interfaccia utente può verificare che il collegamento sia presente e che, una volta selezionato, rimandi al profilo dell'utente. Se però questo collegamento non è facile da individuare, gli utenti potrebbero essere delusi quando tentano di accedere al proprio profilo.
Test di accettare utente
I test di accettazione utente (UAT), come i test di usabilità, sono incentrati sul comportamento di un'applicazione dal punto di vista dell'utente. A differenza dei test di usabilità, i test di accettazione utente vengono generalmente eseguiti dagli utenti finali reali.
A seconda del software, agli utenti finali potrebbe essere richiesto di completare attività specifiche. In alternativa, gli utenti potrebbero essere in grado di esplorare il software senza seguire specifiche linee guida. Per il software personalizzato, i test di accettazione utente vengono in genere eseguiti direttamente con il client. Per un software più generico, i team potrebbero eseguire test beta. Nei test beta, gli utenti di diverse aree geografiche o che hanno determinati interessi ricevono in anticipo l'accesso al software.
Il feedback dei tester può essere diretto o indiretto. Il feedback diretto può assumere la forma di commenti verbali. Il feedback indiretto può corrispondere alla misurazione del linguaggio del corpo o dei movimenti oculari dei tester oppure del tempo necessario per completare determinate attività.
Abbiamo già parlato dell'importanza della scrittura dei test. Per ribadire il concetto, ecco un breve video in cui Abel Wang, Cloud Advocate presso Microsoft, spiega come assicurare la qualità in un piano DevOps.
Chiedi ad Abel
Che cosa sceglie il team?
Tim: Tutti questi test sembrano importanti. Da quale dovremmo iniziare?
Andy: Abbiamo già unit test funzionanti. Non siamo ancora pronti ad eseguire test di accettazione utente. Da ciò che sento, penso che dovremmo concentrarci sul test dell'interfaccia utente. Attualmente, è la parte più lenta del nostro processo. Amita, sei d'accordo?
Amita: Sì, assolutamente. Ci resta ancora un po' di tempo in questa riunione. Andy o Mara, vuoi aiutarmi a pianificare un test dell'interfaccia utente automatizzato?
Mara: Assolutamente. Ma prima affrontiamo alcune questioni preliminari. Vorrei parlare dello strumento che dovremmo usare e di come verranno eseguiti i test.
Quali strumenti è possibile usare per scrivere test dell'interfaccia utente?
Mara: Per quanto riguarda la scrittura di test dell'interfaccia utente, quali sono le opzioni disponibili? So che ne esistono molte. Alcuni strumenti sono open source. Altri offrono supporto commerciale a pagamento. Ecco alcune opzioni da tenere presenti:
- Driver applicazione Windows (WinAppDriver): WinAppDriver consente di automatizzare i test dell'interfaccia utente nelle app di Windows. Queste app possono essere scritte nella piattaforma UWP (Universal Windows Platform) o in Windows Forms (WinForms). Ci serve una soluzione che funzioni in un browser.
- Selenium: Selenium è un framework di test del software open source portabile per applicazioni Web. Viene eseguito nella maggior parte dei sistemi operativi e supporta tutti i browser moderni. È possibile scrivere test di Selenium in diversi linguaggi di programmazione, tra cui C#. Sono infatti disponibili pacchetti NuGet che semplificano l'esecuzione di Selenium come test NUnit. Noi usiamo già NUnit per i nostri unit test.
- SpecFlow: SpecFlow è destinato ai progetti .NET. Si ispira a uno strumento denominato Cucumber. Sia SpecFlow che Cucumber supportano lo sviluppo basato su comportamento (BDD). BDD usa un parser del linguaggio naturale denominato Gherkin per consentire ai team tecnici e non tecnici di definire le regole e i requisiti aziendali. È possibile combinare SpecFlow o Cucumber con Selenium per creare test dell'interfaccia utente.
Andy guarda Amita.
Andy: So che queste opzioni ti sono nuove. Ti dispiace se scegliamo Selenium? L'ho già utilizzato e supporta linguaggi che conosco già. Selenium fornirà anche supporto automatico per più browser.
Amita: Certo. Se uno di noi ha una certa esperienza, è meglio.
Come si eseguono i test funzionali nella pipeline?
In Azure Pipelines è possibile eseguire test funzionali come qualsiasi altro processo o test. Chiediti:
- In quale fase vengono eseguiti i test?
- Su quale sistema vengono eseguiti i test? Verranno eseguiti nell'agente o nell'infrastruttura che ospita l'applicazione?
Vediamo le risposte del team a queste domande.
Mara: Una cosa che mi entusiasma è che adesso si possono eseguire test in un ambiente simile a quello di produzione, in cui l'app è effettivamente in esecuzione. I test funzionali come i test dell'interfaccia utente hanno senso in quel contesto. Possiamo eseguirli nella fase Test della nostra pipeline.
Amita: Sono d'accordo. Possiamo mantenere lo stesso flusso di lavoro se eseguiamo test automatizzati dell'interfaccia utente nella stessa fase in cui eseguo i test manuali. I test automatizzati ci consentiranno di risparmiare tempo e di concentrarci sull'usabilità.
Tim: Amita testa il sito Web dal suo portatile Windows perché è la stessa situazione in cui si trova la maggior parte degli utenti che visita il sito. Però noi compiliamo in Linux e quindi distribuiamo Servizio app di Azure in Linux. Come possiamo gestire questa situazione?
Mara: Ottima domanda. È anche possibile scegliere dove eseguire i test. Possiamo eseguirli:
- Nell'agente: un agente Microsoft o un agente ospitato
- Nell'infrastruttura di test: sia in locale che nel cloud
La fase Test esistente include un solo processo. Questo processo distribuisce il sito Web al servizio app da un agente Linux. Possiamo aggiungere un secondo processo che esegue i test dell'interfaccia utente da un agente Windows. L'agente Windows ospitato da Microsoft è già configurato per l'esecuzione di test di Selenium.
Andy: Anche in questo caso, limitiamoci a ciò che conosciamo. Usiamo un agente Windows ospitato da Microsoft. In seguito, possiamo eseguire gli stessi test da agenti che eseguono macOS e Linux se è necessario estendere la copertura dei test.
Il piano
Mara: OK. Verranno eseguite le operazioni seguenti.
- Eseguire test dell'interfaccia utente di Selenium da un agente Windows ospitato da Microsoft
- Fare in modo che i test recuperino il contenuto Web dall'app in esecuzione nel servizio app, nella fase Test
- Eseguire i test su tutti i browser supportati
Andy: Mi occuperò di questo con Amita. Amita, ci vediamo domani mattina. Farò qualche ricerca prima del nostro incontro.
Amita: Ottimo! A domani.
Creare un piano di test funzionali
Abbiamo appena visto il team prendere alcune decisioni in merito all'implementazione dei primi test funzionali. Se il team sta iniziando a incorporare test funzionali nella propria pipeline (o anche se questo succede già), tenere presente che è sempre necessario un piano.
Molte volte, quando ai membri del team vengono chieste informazioni sul piano di test delle prestazioni, spesso la risposta è un elenco di strumenti che verranno usati. Un elenco di strumenti, però, non è un piano. È anche necessario stabilire come verranno configurati gli ambienti di test. Devi determinare il processo da utilizzare e come si presentano risultati positivi o negativi.
Il piano deve:
- Prendere in considerazione le aspettative dell'azienda.
- Prendere in considerazione le aspettative degli utenti di destinazione.
- Definire le metriche che verranno usate.
- Definire gli indicatori KPI che si useranno.
Il test delle prestazioni deve essere incluso nella pianificazione fin dalle prime fasi. Se si usa uno storyboard o una lavagna Kanban, può essere utile predisporre un'area in cui pianificare la strategia di test. Nell'ambito della pianificazione dell'iterazione, è consigliabile evidenziare le lacune nella strategia di test. È anche importante stabilire come verranno monitorate le prestazioni dopo la distribuzione dell'applicazione e non solo misurare le prestazioni prima del rilascio.