Test esplorativi a supporto degli addetti al controllo della qualità del software. A differenza di altre tipologie di test del software, che utilizzano una serie di passaggi dettagliati supportati dagli script, i test esplorativi sono un approccio di tutt’altro tipo. A fare la differenza è che questo tipo di test è basato sulla creatività del professionista QA (Quality Assurance).
Test esplorativi: che cosa sono
Quando si tratta di test esplorativi non esiste un modo predefinito per eseguirne lo stile. Il più delle volte capita che sia progettato ad hoc. La caratteristica saliente dei test esplorativi è che non richiedono documentazione e che presuppongono una formazione quasi nulla. Questi test:
- sono flessibili
- comportano una grande creatività
- sono rapidi da implementare
Gli ingegneri del controllo qualità per formalizzare gli sforzi e realizzare i loro test esplorativi devono considerare:
- la comprensione del comportamento umano
- l’esperienza dell’utente
- la finalità dell’applicazione
Questo approccio alle attività di testing funziona molto bene per gli sviluppatori Agile in virtù della velocità e della capacità di adattarsi a qualsiasi fase del ciclo di vita della programmazione software, includendo requisiti e revisione del progetto.
Test esplorativi in 3 fasi, tutte sincronizzate
I test esplorativi triangolano:
- pianificazione
- sviluppo
- esecuzione dei casi di test
Queste fasi si verificano tutte contemporaneamente per cui gli ingegneri addetti al controllo qualità devono eseguire test esplorativi su tre livelli, in ogni momento e sulla qualunque.
Con i test basati sugli script, invece, il codice dell’applicazione deve esistere, in uno stato verificabile, prima che il team addetto al controllo qualità possa sviluppare ed eseguire casi di test.
Come affrontare i test esplorativi
I professionisti del controllo qualità possono utilizzare le tecniche dei test esplorativi per valutare:
- la funzionalità dell’applicazione
- il modo in cui il codice verrà distribuito nei server di test e di produzione
I team addetti al controllo qualità devono pianificare come affrontare i test esplorativi. Dopo la pianificazione, lo stile del test è tutto basato sulla scoperta e l’indagine. Indipendentemente da come il team documenta o esegue le prove, infatti, i test esplorativi si basano sulla creatività, la diligenza e l’esperienza del professionista QA.
Guida ai test esplorativi
Per spiegare gradualmente le diverse tecniche a partire da quelle più adatte ai principianti per arrivare a quelle per gli esperti del controllo qualità, gli esperti entrano nel dettaglio.
I professionisti del controllo qualità possono migliorare rapidamente le loro abilità e il loro istinto quando eseguono i test esplorativi. I tester dovrebbero imparare a:
- gestire e pianificare il proprio approccio
- individuare quali sono i punti deboli nella progettazione delle applicazioni
- scoprire sia i difetti software evidenti che quelli più nascosti
Approcci sperimentali per principianti
I test esplorativi non richiedono una particolare formazione e neppure una comprensione complessa dei processi di back-end. Lo stile del testing può disorientare i principianti perché impone di pensare fuori dagli schemi al contrario dei test tramite script che sono sicuramente più facili da seguire.
È importante creare una vera e propria carta del team per principianti ed eseguire il test time-box. Ma, attenzione, i charter sono dichiarazioni che riportano le linee guida dei test, non sono script da seguire. Una carta del team spiega l’approccio o il piano di test, esplicitando chi svolge una determinata funzione, su quali caratteristiche e su quali aree del software. Queste informazioni aiutano a distribuire i test per coprire l’intera applicazione.
Ecco cinque tecniche di test esplorativi che i principianti possono provare per:
- creare scenari o storie utente
- andare oltre il percorso tradizionale
- non confermare solo la funzione ma trovare anche i difetti
- analizzare le possibili lacune nella funzionalità
- tracciare una mappa concettuale
Crea scenari o storie utente
I tester esplorativi possono costruire descrizioni testuali di una funzione applicativa all’interno di un flusso di lavoro dell’utente. È importante dettagliare un percorso utente singolo attraverso l’applicazione.
Ecco un esempio di uno scenario per l’utente finale. Si sta testando un’applicazione medica che consente all’operatore sanitario di monitorare la salute di un paziente su un particolare farmaco e di modificare il dosaggio secondo necessità. I passaggi supportati dal software sono:
- Il medico accede e trova lo stato del paziente e la durata del trattamento
- Guarda i risultati di laboratorio e confronta i valori dell’ultimo mese con sei mesi fa.
- Visualizza un rapporto che confronta i risultati di laboratorio.
- Analizza se il paziente ha bisogno di un cambiamento nel dosaggio per ottenere risultati migliori. Di conseguenza, in questo scenario, il medico modifica un’ipotetica dose di 0,5 milligrammi.
- Chiede al paziente di sottoporsi a nuovi test di laboratorio in due mesi.
- Invia tramite e-mail o messaggio di testo il modulo di laboratorio appropriato al paziente e passa all’appuntamento successivo
Questo esempio di test esplorativo valuta come il flusso di lavoro del medico si interseca con il database del software, i valori calcolati e qualsiasi analisi incorporata nella funzione di reporting. Questo scenario verifica anche la capacità dell’utente del software di modificare una dose con un valore realistico e di inviare al paziente sia una richiesta di laboratorio sia un modulo di laboratorio attraverso più canali di comunicazione.
Il tester può espandere questa user story in base alla funzionalità dell’applicazione, ad esempio sondando cosa succede con più pazienti, cambiando schermate tra i pazienti. Lo stesso tester potrebbe anche implementare un livello di test di sicurezza per garantire che quando un utente passa da una schermata paziente all’altra, le pagine si aggiornano con i dati della persona appropriata. Le storie possono essere lunghi flussi di lavoro o brevi frammenti: queste descrizioni possono essere basate sull’utente o sulla funzione da eseguire all’interno dell’applicazione.
Una volta che i tester QA acquisiranno familiarità con il processo di pensiero delle storie degli utenti, potranno pensare in modo critico e valutare diversi flussi di lavoro degli utenti, sia previsti che imprevisti. La copertura dei test e i vantaggi della documentazione, poiché le storie dei test possono informare future valutazioni sull’utilizzo dell’applicazione.
Osare oltre la via maestra
Molte suite di test di regressione con degli script definiscono passaggi precisi e previsti nonché punti di validazione. Questi test, sia automatici che manuali, verificano che l’applicazione esegua una funzione come previsto o si verifichi il flusso logico programmato.
Come tester esplorativo, è necessario anche verificare il flusso non logico. È importante uscire dai sentieri battuti per:
- Provare la risposta dell’applicazione ai pulsanti a doppio o triplo clic
- Usare il famigerato pulsante back sul browser
- Immettere i campi previsti in un ordine illogico
- Andare avanti e indietro, cambiando anche idea
- Cambiare i valori
- Fare clic sui pulsanti in una sequenza inaspettata
Esisterà sempre un percorso felice o un flusso atteso per centinaia o migliaia di utenti. Ma attenzione, dicono gli esperti: esistono altrettanti modi in cui gli utenti possono agire seguendo un modello totalmente diverso, seguendo logiche completamente diverse. Esplorare il maggior numero possibile di questi percorsi aiuta a contemplare variabili inaspettate che, integrate nel software, contribuiranno a garantire la sua qualità per un maggior numero di utenti.
Trovare i difetti
Non basta solo confermare la funzione di un software. È necessario anche trovare i possibili difetti. I tester esplorativi dovrebbero provare a rompere un programma, non solo a verificare che questo funzioni.
Oltre ad affidarsi alla propria esperienza personale è bene utilizzare nuovi programmi software per cercare difetti analoghi. Ad esempio, molte famose applicazioni di documentazione gestiscono male elenchi puntati e numerati. Quante volte è capitato che un tester abbia dovuto cancellare un elenco e ricominciare da capo proprio perché in qualche modo la voce di testo era fuori linea, o faceva un ritorno a capo per cui modificare l’elenco si tramutava in una missione impossibile?
Ecco un altro esempio: accedere a un’applicazione bancaria e selezionare la casella accanto a Ricordami o Ricorda questo dispositivo per 30 giorni. Queste opzioni di accesso non sono solo una pessima idea per motivi di sicurezza: il problema è che la maggior parte di questo tipo di funzionalità non funziona quasi mai come previsto.
Raccogliere tutti questi difetti rispetto all’uso quotidiano delle applicazioni aiuta gli sviluppatori a mettersi alla prova.
Analizzare le lacune nella funzionalità
Molte organizzazioni che si occupano di sviluppo software mappano i requisiti o il flusso di progettazione graficamente o in forma scritta. La documentazione rappresentata graficamente dei flussi di lavoro aiuta i tester a trovare le lacune nella funzionalità. Questa tecnica di test esplorativo, controlla il progetto analizzando i requisiti mancanti prima che diventino difetti o ulteriori storie di sviluppo. È possibile anche adottare questo approccio utilizzando una documentazione scritta. L’unica cosa è che sarà opportuno mappare i requisiti per avere un’idea di come funzionerà l’applicazione completa.
Dedicare del tempo a trovare lacune
È importante analizzare dove e come l’applicazione estrae o trasferisce i dati nel database o in altre applicazioni connesse. Bisogna controllare quando e come vengono aggiornati i dati della pagina. Se l’applicazione consente a un utente di generare messaggi di posta elettronica o SMS esternamente o internamente, è necessario verificare se la funzionalità si attiva come previsto. I problemi di connessione con i sistemi di messaggistica di terze parti sono numerosi: è meglio mapparne quanti più possibili.
Disegnare una mappa concettuale
I project manager durante la pianificazione del progetto in genere usano le mappe concettuali (vale a dire dei raggruppamenti graficati di idee e concetti) per assicurarsi di non dimenticare tutti gli elementi necessari allo sviluppo. Durante i test esplorativi la mappatura mentale è un modo eccellente per assumere la funzione, la storia o il flusso di lavoro che si desidera testare e tracciare, considerando tutte le opzioni possibili. Le mappe mentali dei test esplorativi possono raggiungere dimensioni impressionanti. Questi diagrammi forniscono ai tester molte vie per trovare i difetti.
Ad esempio, l’applicazione di ordinazione di consegna di un ristorante ha una varietà infinita di opzioni sul menu:
- un gran numero di combinazioni
- singoli articoli
- opzioni di pagamento
- indicazioni di consegna
Un professionista della qualità del software può mappare come testare ciascuna opzione nonché varie combinazioni in diversi flussi di lavoro dell’utente.
Durante i test esplorativi ci sono anche una lista ulteriore di domande da considerare come, ad esempio:
- Cosa succede se l’utente modifica un ordine e lo salva?
- Vuoi salvarlo?
- Cosa succede se il pagamento non viene elaborato?
- In che modo l’applicazione gestisce più tipi di pagamento?
- Vuoi pagare in contanti?
Le mappe concettuali a supporto del test funzionale è possibile formalizzarlo su un qualsiasi supporto cartaceo. Ma è possibile anche disegnare il diagramma in un formato non analogico, utilizzando soluzioni come Google Documenti, Microsoft Word, Apple Pages o qualsiasi altro strumento di documentazione di base. Ognuna offre la possibilità di aggiungere una varietà di forme con testo che si può spostare nella pagina. Se si preferisce tracciare le mappe mentali visive in modo digitale, sono disponibili opzioni software, come Ayoa, Microsoft Visio, Lucidchart, Milanote e Coggle.
Tecniche avanzate di sperimentazione esplorativa
I tester di tutti i livelli di esperienza e background possono utilizzare vari metodi di test esplorativi. Il processo di test esplorativo sfrutta tutte le competenze di un tester, il che significa che il tester continua a migliorare nel tempo.
I tester esperti possiedono una creatività che li aiuta a scoprire flussi di lavoro degli utenti fuori dai percorsi noti. Questi tester spesso prendono direzioni tortuose per trovare difetti che altrimenti sarebbero passati inosservati.
Scopri come test esplorativo come un professionista con queste cinque tecniche:
- analizzare i punti di forza e di debolezza dei singoli sviluppatori
- ricercare di lacune nei dati e nei processi di back-end
- piegare alcuni test di integrazione
- separare le esigenze del cliente dalla funzionalità dell’app
- non aver paura
Analizzare i punti di forza e di debolezza dei singoli sviluppatori
Non bisogna psicanalizzare un team di sviluppo software, ma comprenderne i comportamenti. Quando si lavora con un team di sviluppo, attraverso una singola versione o per diversi anni di versioni di sviluppo, si impara a conoscere le modalità di lavoro di ogni singola persona.
Spesso gli sviluppatori testano solo sul proprio computer locale. E spesso, per limiti di tempo, vogliono ottenere il codice per il QA il più rapidamente possibile. In alternativa, il team di sviluppo potrebbe solo rivedere il codice, non testarlo. Quando gli sviluppatori producono codice ma non producono unit test e quando non eseguono test al di fuori della propria macchina locale, i difetti del software sono facili da individuare. È possibile trovare bug proprio all’inizio del test, senza troppe analisi o sforzi di creatività.
Alcuni sviluppatori, invece, vanno oltre: creano unit test e quindi le eseguono nell’applicazione dopo aver unito il codice, prima di passarlo al QA. Quando i tester compiono questo raro sforzo extra, è possibile trovare nuovi difetti. Serve maggiore creatività per scoprire i flussi di lavoro degli utenti di cui gli sviluppatori non sono a conoscenza o per testare variazioni che si discostano dal percorso funzionale previsto. Ad alcuni sviluppatori possono mancare anche i requisiti.
Esempio di test esplorativi di una user story
Non è una regola: ma sempre e in ogni caso ricordarsi di usare la creatività nel testare qualsiasi applicazione. Di seguito un esempio di base relativo a un’applicazione dei test esplorativi a un programma che, a titolo immaginario, chiamiamo MyPatient.
Testare la relazione tra paziente, medico e farmaci:
- Accedere all’applicazione MyPatient come paziente membro assegnato a un certo team di medici.
- Visualizzare la pagina Dettagli per verificare che il medico elenchi un indirizzo di studio primario, che viene inserito nei moduli paziente.
- Visualizzare l’elenco dei farmaci e delle dosi precedenti e aprire e visualizzare i dettagli del paziente e assicurarsi che corrispondano.
- L’applicazione mostra che il paziente è attuale o in ritardo per una revisione del farmaco? In questo caso è necessario elaborare una revisione per il paziente sia in uno stato attuale che in modalità ritardo.
- Stampare un rapporto mensile.
- Modificare la dose del paziente, aumentando di percentuali variabili, come 10, 20 o 60.
- Stabilire un appuntamento per discutere della dose e cambiare l’appuntamento per una data non valida o ormai trascorsa.
- Controllare se gli avvisi di appuntamento si attivano per l’infermiere e il medico assegnati.
- Selezionare la visualizzazione dei risultati di laboratorio: aprire uno o più risultati.
- Verificare che il nome del paziente nel modulo dei risultati di laboratorio corrisponda al paziente selezionato.
- Verificare che i dati del risultato visualizzati corrispondano a quelli mostrati sul pannello del paziente.
- Aprire il PDF del risultato di laboratorio e verificare che sia per il paziente corretto e che i dettagli del paziente corrispondano.
- Confermare che il modulo PDF non è modificabile.
- Fare clic su ciascuna icona e sezione principale, quindi cercare una cronologia delle assegnazioni e dei farmaci del medico.
- Verificare che i risultati della ricerca siano quelli previsti in base ai parametri di ricerca e che vengano visualizzati correttamente.
- Ordinare e filtrare su ogni campo ricercabile: ad esempio, filtrare la data corrente e quindi visualizzare l’aspetto dei dati sulla pagina.
- Fare clic per aprire tutti i singoli grafici. Assicurarsi che i valori corrispondano al risultato del test di laboratorio specificato.
Cercare lacune nei dati e nei processi di back-end
Quando si progetta un test esplorativo bisogna includere l’analisi dei processi di back-end includendo le varie integrazioni degli strumenti di terze parti che completano le funzionalità dell’applicazione. È importante prestare attenzione ai feed di dati che provengono da fonti esterne come, ad esempio, le API e individuare quali azioni nell’applicazione li attivano. La maggior parte dei feed di dati sono programmati per una certa attività programmata in orari specifici. È fondamentale testare quei tempi per vedere in che modo impattano sull’applicazione.
Gli sviluppatori possono fornire informazioni su dove e come funzionano queste app di terze parti. Ad esempio, i servizi di terze parti spesso inviano e ricevono e-mail o messaggi SMS all’interno di un’applicazione.
Se l’applicazione consente ai clienti di configurare le funzionalità è fondamentale cercare i difetti nel processo. Scandagliando la configurazione in profondità si troveranno sicuramente dei difetti. Si parte a indagare le impostazioni di ciò che è regolamentato o è ad alto rischio. Nelle applicazioni mediche, ad esempio, il software supporta l’ordinazione di farmaci, i calcoli di dosaggio o la codifica di diagnosi. Bisogna identificare le aree che possono potenzialmente causare da subito il maggior danno. Certo che ruotare per ore tutti gli interruttori attraverso combinazioni casuali è noioso, ma serve a trovare i difetti e filtrare gli errori.
Cercare impostazioni che si contraddicono a vicenda
Per trovare i conflitti tra due impostazioni bisogna attivarle entrambe e stare a guardare cosa succede. Riescono ad essere attive contemporaneamente? Se è così, quale delle due ha la precedenza? È importante esaminare il modo in cui l’applicazione risponde a queste configurazioni in conflitto. Le impostazioni di configurazione dell’applicazione sono un’area di test trascurata e piena di possibili difetti. Storie di test esplorativi per processi di back-end aiutano a far emergere le aree problematiche, altrimenti irraggiungibili tramite altre forme di test in modalità black box.
Stressare alcuni test di integrazione
Un tester esperto sa dove si intersecano i flussi di lavoro dell’utente finale di un’applicazione. Quando si valutano queste connessioni, si parla di test di integrazione. È necessario creare storie per la copertura del test di integrazione, concentrandosi su:
- i flussi di lavoro delle applicazioni con ruoli utente diversi
- le variazioni nelle impostazioni di sicurezza o di accesso e via dicendo
Si prenda il caso di un test su un’applicazione sanitaria che crea automaticamente addebiti finanziari in base al farmaco e al dosaggio assegnati a ciascun paziente ogni giorno. È possibile verificare tramite test come il lato finanziario dell’applicazione gestisca le modifiche a questi valori. Le domande da farsi sono:
- Se l’utente assegna un farmaco in una dose errata, che impatto ha sul calcolo delle spese di fatturazione?
- Cosa succede se si cambia il farmaco assegnato, ma non la dose, su base giornaliera?
- Il calcolo della fatturazione rileva ogni modifica?
- L’app sa riconoscere quando i costi non corrispondono al farmaco?
La maggior parte dei software include aree funzionali integrate, come reportistica e dati finanziari. Bisogna usare la propria esperienza nei test applicativi per scoprire altre funzioni integrate da testare. La tecnica delle mappe concettuali qui torna utile, dal momento che i diagrammi possono aiutare a scoprire tutte le possibili opzioni di test esplorativi.
Separare le esigenze del cliente dalla funzionalità dell’app
È importante anche mettere alla prova i criteri o i requisiti di accettazione dell’utente per ogni storia e guardare come tutto si armonizzi rispetto ai flussi di lavoro dei clienti. I tester tendono a valutare le applicazioni utilizzando l’occhio del cliente, ma è facile perdere questa prospettiva quando ci si ritrova ad avere a che fare con cicli di sviluppo molto rapidi. Applicare questa prospettiva è un esercizio creativo utile, ma è difficile metterlo in pratica quando un tester è continuamente focalizzato a mettere alla prova le storie dei singoli utenti.
Un approccio ai test esplorativi funzionale imporrebbe di concentrarsi solo sull’impatto dell’utente. Come spiegano gli esperti, bisogna dimenticare ciò che si sa di ogni storia. È necessario pensare a come l’utente agisce o può interagire con l’applicazione. Bisogna concentrarsi sui test dei flussi di lavoro definiti dal ruolo dell’utente o dal livello di accesso. Ad esempio, la maggior parte delle applicazioni sanitarie ha workflow specifici per ogni ruolo: ad esempio, medico, paziente e infermiere. In qualsiasi momento è necessario capire quale ruolo si sta testando, dimenticando altre funzioni perché il test è basato su ciò che un determinato utente può fare nell’applicazione.
Non aver paura di osare
Con i test esplorativi non si deve aver paura di essere troppo creativi. Il presupposto di partenza è che la maggior parte degli utenti non segue mail il flusso di lavoro previsto. Gli utenti possono essere interrotti durante l’immissione dei dati o premere involontariamente una sequenza di pulsanti errata. Potrebbero annullare un’azione anziché salvarla. I test esplorativi forniscono un ciclo quasi infinito di opportunità finalizzate al controllo della qualità del software.
Durante i test esplorativi, non bisogna temere di interrompere l’applicazione, il server, il database o le connessioni sottostanti. Se nella sperimentazione riuscite a interrompere il sistema di supporto sottostante o le connessioni, infatti, è molto probabile che possano riuscirci anche gli utenti finali. Rompere tutto non è sbagliato perché aiuta a scoprire tutti i punti deboli di un’applicazione o quali aree funzionali tendono ad essere fragili. Bisogna sperimentare per sfruttare al meglio le debolezze rilevate. L’unica barriera dovrebbe essere l’accesso alla sicurezza.
La creatività è stata trascurata per anni, ma è un’abilità fondamentale per la carriera di un tester QA. Le metodologie associate ai test esplorativi dipendono dalla creatività di un tester coraggioso. Un tester esplorativo trova risposte alternative: procede nel modo sbagliato, esegue le funzioni in modo errato, torna indietro e clicca ripetutamente sui pulsanti. Idealmente, deve immedesimarsi in un utente target che, a sua volta, segue comportamenti imperscrutabili…
