Leadership nel Test: Strumenti per l’Esecuzione dei Test

JOIN THE COMMUNITY

Upgrade your inbox with more tech leadership wisdom for delivering better software and systems.

Sign up with:

LinkedInGoogleMicrosoft

Or sign up with email:

Facebook

This field is for validation purposes and should be left unchanged.

Name*

First name Last name

Business email*

This field is hidden when viewing the form

Free Account Module

Bottom BarLanding PageFooterInlinePop UpSidebarSSO

LinkedIn profile

Seniority*

Select an optionExecutive / C-suiteVPDirectorManagerIndividual ContributorOther

Company's AI adoption maturity*

Select an optionExploring opportunitiesRunning pilotsScaling adoptionEmbedded in the business model

Cosa ottieni (e cosa no) dagli strumenti di esecuzione dei test

Che tu stia testando applicazioni desktop Windows, siti web o dispositivi mobili, i principi dell’automazione dei test, i benefici e i rischi sono simili. Gli strumenti ti offrono:

• Un robot instancabile e teoricamente privo di errori che esegue qualsiasi test scriptato tu desideri, su richiesta, tutte le volte che vuoi.
• Un confronto preciso tra l’output e/o l’esito dei test, con risultati attesi preparati, al livello di dettaglio che sei disposto a programmare nello strumento.

Quello che NON ottieni è:

• Flessibilità e risposte agili di fronte ad anomalie, errori o comportamenti dubbi.
• Gli occhi e il pensiero di un tester umano, capace di esplorare, porsi domande, sperimentare e mettere in discussione il comportamento del sistema sotto test.
• I test gratis. Devi comunque progettare i test, preparare i dati di test e i risultati attesi, per esempio.
• Sebbene gli strumenti di esecuzione dei test offrano una gamma di funzionalità, spesso non dispongono di avanzate capacità di gestione dei dati. Per una soluzione più completa, potresti voler esplorare i migliori software di gestione database disponibili.

Esploriamo il significato di questi vantaggi e di questi problemi.

Se sei un programmatore ragionevolmente competente, è semplice trasformare test procedurali eseguiti da persone in procedure automatizzate nello script dello strumento, per essere eseguite accuratamente.

Finché l’ambiente e i dati utilizzati dall’applicazione di test rimangono consistenti, puoi aspettarti che i test vengano eseguiti in modo affidabile più e più volte. Questa è la chiara promessa dell’esecuzione automatizzata dei test.

Ma i test automatizzati non simulano accuratamente ciò che fanno (i bravi) tester quando testano.

Un test eseguito da uno strumento NON equivale allo stesso test eseguito da un essere umano.

Un test, se scriptato, può indicare al tester cosa fare. Ma il tester può andare oltre il semplice confronto tra il risultato atteso e quanto visualizzato a schermo.

I tester devono raggiungere il punto in cui eseguire il test e prestare attenzione a comportamenti anomali – la risposta dei comandi; la velocità di risposta; l’aspetto della schermata; il comportamento di oggetti influenzati dai cambiamenti di stato dell’applicazione.

Il tester umano, osservando un’anomalia, può fermarsi, tornare indietro, o analizzare più nel dettaglio l’applicazione o i dati prima di concludere se l’applicazione funziona correttamente (o meno) e decidere se proseguire con il test scriptato, adeguare i dati e gli script del test, o continuare come previsto.

Gli esseri umani sono flessibili, mentre gli strumenti fanno solo esattamente ciò per cui sono programmati. In una transazione basata su schermo, lo strumento inserisce dati, clicca un pulsante e verifica un messaggio o un risultato visualizzato – e basta. Con i tester umani otteniamo molto di più, cosa che spesso diamo per scontata. 

In linea di principio, è possibile programmare uno strumento affinché esegua tutti i controlli che un essere umano compie istintivamente – ma dovrai scrivere molto codice e spendere tempo a fare il debug dei tuoi test. Anche così, non avrai la capacità umana di decidere cosa fare dopo – fermarsi, continuare, cambiare il test a metà percorso o esplorare più a fondo un'anomalia.

Da nessuna parte l'inflessibilità degli strumenti è più evidente che nella reazione alla perdita di sincronizzazione dello script con il sistema in test. Forse un risultato atteso non corrisponde, oppure il sistema va in crash, o il comportamento dell'interfaccia utente (ad esempio un diverso ordine dei campi o un campo nuovo) differisce da ciò che lo script si aspetta. Cosa fa lo strumento? Cerca di continuare ed esplode una serie di errori dello script o crash. 

Sì, puoi e dovresti includere gestori di eventi imprevisti nello script per intercettare i fallimenti del test. Perdita di sincronizzazione, incongruenze tra stato del sistema e dati di test, cambiamenti nell'ordine dei campi, campi nuovi o rimossi sono aspetti che il tester può riconoscere e affrontare senza bloccare l'esecuzione dei test. Gli strumenti non possono farlo senza un grande sforzo di programmazione da parte tua.

Ci sono anche degli svantaggi nell’utilizzare esseri umani per seguire test scriptati. I tester possono diventare ossessionati dall'obbedire allo script e dimenticare di utilizzare le proprie capacità di osservazione. Potrebbero ignorare anomalie evidenti perché concentrati sul seguire lo script. Questo approccio sub-ottimale è esattamente ciò che otteniamo dall'automazione dell'esecuzione dei test.

Un'adesione cieca agli script di test è una pessima idea per i tester umani, ma è il meglio che possiamo ottenere con l'automazione dei test.

In questo confronto fra tester che seguono script e strumenti che eseguono test, non abbiamo considerato cosa fanno i tester esplorativi. L'approccio esplorativo offre ai tester la libertà di indagare e testare dove e come vogliono. 

Chiaramente, gli strumenti non possono simulare questa attività. Ancora più importante, gli strumenti non possono definire l’ambito, dare priorità e modellare la funzionalità e i rischi di un sistema e progettare di conseguenza i test.

Le attività di analisi e progettazione dei test sono necessarie a prescindere dal fatto che il test venga eseguito da un essere umano o da uno strumento.

Ci sono ulteriori limitazioni su ciò che possono fare gli strumenti di esecuzione dei test:

• Gli strumenti di esecuzione test fanno esattamente ciò per cui li programmi – né più né meno
• Gli strumenti di solito non eseguono build e configurazione di ambienti e applicazioni, né il caricamento dei dati di test
• Gli strumenti non progettano casi o script di test, né preparano dati di test o risultati attesi
• Gli strumenti non possono prendere decisioni ponderate quando si verificano eventi imprevisti.

Per ottimizzare i tuoi processi di esecuzione dei test, integrarli con un solido software di test management può offrire flussi di lavoro più lineari e una reportistica avanzata.

Automazione dei Test dell’Interfaccia Grafica (GUI)

Sono passati più o meno venticinque anni da quando sono arrivati sul mercato gli strumenti di automazione dei test GUI, ma il numero di implementazioni fallite di questi strumenti è ancora elevato. Questo avviene soprattutto perché si hanno aspettative troppo alte sull’automazione – e strumenti utilizzati senza disciplina non saranno mai in grado di soddisfarle.

Gli strumenti di automazione dei test GUI hanno la reputazione di essere facili da usare come prodotti, ma difficili da gestire quando le applicazioni da testare (e quindi gli script di test) devono cambiare. Questi strumenti sono molto sensibili alle variazioni dell’interfaccia utente. Cambiamenti nella posizione, nell’ordine, nelle dimensioni, nell’aggiunta o rimozione di oggetti a schermo possono tutti influire sugli script. Anche modifiche più tecniche, come la rinomina di oggetti a schermo o la modifica di librerie GUI “invisibili” incorporate, creano problemi.

L’automazione dei test GUI funziona al meglio quando si applica disciplina riguardo a:

• Il processo di sviluppo e le modifiche e i rilasci vengono gestiti con attenzione. Per esempio, le modifiche vengono analizzate per il loro impatto e comunicate ai tester. 
• L’approccio allo sviluppo degli script di test. Gli ingegneri esperti di automazione dei test adottano convenzioni di denominazione sistematiche, strutture di directory, componenti modulari e riutilizzabili, tecniche di programmazione difensiva e così via.

Scrivere script di automazione dei test è un compito che richiede più che semplici basi di programmazione e, soprattutto, esperienza nell’automazione e con lo strumento utilizzato. Quando i test vengono automatizzati su larga scala, occorrono anche competenze di progettazione. 

Non importa come vengono descritti gli strumenti dai fornitori – “senza script”, “utilizzabile anche da chi non sa programmare” o “anche gli utenti possono automatizzare” – avrai comunque bisogno di una mentalità da programmatore, di capacità di progettazione e di un approccio sistematico.

Automazione dei Test di API e Servizi

Quando ci sono componenti o funzionalità distribuite come servizi, richiamate da client leggeri o mobile, i test saranno condotti tramite un'API o con chiamate ai servizi. Questo tipo di test viene eseguito utilizzando codice personalizzato scritto dagli sviluppatori oppure strumenti dedicati per il test di API o servizi. In ogni caso, l’approccio più comune è automatizzare i test in un modo o nell’altro.

Poiché l’API è "più vicina" al codice da testare, i test possono essere molto più focalizzati sulla funzionalità da verificare. Sicuramente, si possono evitare le complessità della navigazione tramite l’interfaccia utente e della verifica attraverso l’UI stessa. Per questo motivo, la regola generale è:

Se la funzionalità da testare (a livello di codice o di componente) può essere verificata tramite una chiamata di funzione, un’API o una chiamata di servizio, allora l’automazione sarà più semplice – ed è raccomandata.

Il testing tramite API offre vantaggi evidenti.

• Anche se sarà necessario usare o scrivere codice, gli stessi test saranno molto più facili da applicare (non c’è un’interfaccia utente di cui preoccuparsi).
• Una volta che una chiamata API è stata programmata, è semplicemente questione di tabulare la gamma di casi di test che si desidera applicare. Non c’è limite al numero di test che si possono eseguire.
• I test basati su API di solito vengono eseguiti molto più velocemente, rendendo questo stile di testing particolarmente adatto agli approcci di continuous delivery in cui la pipeline di deployment è altamente automatizzata e deve essere rapida nel rispondere.

La ‘piramide dell’automazione dei test’ (una ricerca su Google mostra centinaia di esempi di questa grafica) è stata adottata quasi universalmente per sottolineare che gli sforzi di automazione devono concentrarsi maggiormente su test a livello di sviluppatore o tramite API piuttosto che attraverso la GUI.

• Usa i test sull’interfaccia utente solo dove è necessario esercitare il flusso di lavoro dell’utente finale, ma in quantità ridotta perché sono costosi e possono essere lenti da eseguire.
• Usa chiamate API o di servizio laddove la funzionalità da testare può essere isolata e dove velocità e facilità d’automazione sono essenziali.

Testing di Regressione

L’uso classico degli strumenti automatici riguarda l’esecuzione dei test di regressione. Questi test vengono eseguiti una volta e considerati rappresentazioni affidabili del comportamento atteso. Quando il codice applicativo sotto test, eventuali librerie riutilizzabili o l’ambiente di test cambia, questi test offrono una certa fiducia che la funzionalità richiesta non sia stata compromessa dalla modifica.

Si può immaginare i test automatici come uno stampo in cui deve incastrarsi il sistema in test. Naturalmente, i test dovrebbero "superare" tutte le verifiche passate in precedenza. Rifacendoli, si cerca di dimostrare l’equivalenza funzionale della nuova versione del software rispetto a quella precedente. Alcuni principi semplici vanno seguiti:

• Innanzitutto, i test e le verifiche effettuati devono essere scelti per darti fiducia che non ci siano cambiamenti indesiderati nel comportamento. Questi test fungono da "fili a trappola" per rilevare differenze di comportamento.
• Quando vengono corretti bug o apportate altre modifiche software, potrebbero esserci dei comportamenti alterati (correttamente) che però, se incontrati dai tuoi test, faranno fallire una verifica. O cambi i tuoi test in anticipo oppure li lasci fallire e li correggi successivamente. Talvolta conviene eliminare completamente i test falliti e crearne di nuovi da zero per sostituirli. In ogni caso, questi test modificati devono essere poi eseguiti fino a completamento e superati.
• Se il sistema testato non è stabile, presenta molti bug o subisce numerose modifiche tra una release e l’altra, potrebbe non essere economicamente sostenibile mantenere una suite di test automatici. Anche se la funzionalità non cambia, è possibile che l’interfaccia utente sia ancora in evoluzione – una UI instabile rende più difficile l’automazione. Il costo di analisi dei fallimenti e manutenzione dei test potrebbe superare la loro utilità. Potrebbe essere saggio testare manualmente le parti meno stabili finché non si stabilizzano.

Il test tramite l’interfaccia utente può risultare a volte ingombrante, costoso e lento da eseguire. Prima di avventurarti nell’automazione di test GUI, o anche solo nell’automazione di uno script singolo, valuta se testare la funzionalità chiave non sia più facile, veloce ed economico tramite una API.

L’uso classico degli strumenti automatici riguarda l’esecuzione dei test di regressione. Per assicurarti di usare gli strumenti più efficaci per questo scopo, consulta la nostra lista dei migliori software di test

Framework di Automazione dei Test

I framework di testing sono una parte fondamentale di qualsiasi processo di test automatico di successo. Pensali come un insieme di linee guida per creare e progettare i casi di test. Il loro uso può aumentare la velocità e l’efficienza del team di test, migliorare l’accuratezza delle verifiche, abbassare i rischi e ridurre i costi di manutenzione dei test. Ora ne vedremo due tipologie.

Quando si parla di framework di automazione dei test, è importante considerare il ruolo dei QA automation tools nel definire una strategia di testing efficace.

More Articles

• La Leadership nel Testing: Definire una Strategia di Test
• Leadership nel Test: Strumenti per il Testing
• Come mi preparo e testo per i miei rilasci

Framework per Unit Test

I framework per i test unitari esistono da diversi anni e sono largamente impiegati dagli sviluppatori per testare il proprio codice. I test degli sviluppatori tendono a essere piuttosto localizzati – in genere testano un singolo componente con le interfacce verso altri componenti o database simulate (mock) o sostituite con stubs. Quindi, sebbene i test unitari richiedano operazioni di preparazione e "pulizia" prima e dopo l’esecuzione, queste attività sono di solito limitate ai test di un singolo componente. Esisteranno suite di test separate per ogni componente.

I test unitari creati dagli sviluppatori sono solitamente gestiti tramite controllo di versione e mantenuti in parallelo con il codice dei componenti. Tipicamente, gli strumenti di Integrazione Continua (CI) prendono il codice sorgente e tutti i test unitari e li eseguono dopo ogni commit di nuovo codice e/o test. Tutti gli sviluppatori visualizzano l’esito di questi test, per cui un fallimento dei test in CI diventa molto visibile. Correggere i test falliti e il codice è una priorità elevata nelle squadre che utilizzano la CI in questo modo, così che l’ultima versione del sistema superi sempre tutti i test di CI.

Framework di Automazione dei Test di Integrazione e di Sistema

Negli ultimi anni, gli strumenti di test GUI sono stati integrati con strumenti CI utilizzando dispositivi di test virtualizzati, ambienti, ed esecuzione tramite interfacce a riga di comando. Molte organizzazioni sono riuscite a integrare completamente l’esecuzione di test unitari, a livello API e GUI tramite servizi CI.

Tuttavia, molti team di test continuano a gestire i propri ambienti separati dai servizi di sviluppo o di CI. Questi team tendono a costruire i propri framework di automazione dei test perché gli strumenti CI sono troppo orientati agli sviluppatori o gli strumenti proprietari risultano inadeguati.

I test GUI tendono a implementare test end-to-end o percorsi utente utilizzando diverse applicazioni, dispositivi hardware e ambienti. Questi test devono predisporre senza soluzione di continuità ambienti di test integrati e dati di test preparati su piattaforme differenti, il che richiede procedure privilegiate e complesse e ambienti tecnici diversificati per poter funzionare. La stragrande maggioranza dei gruppi che utilizzano l’automazione dei test GUI crea il proprio framework di automazione, unico ma efficace.

I framework di automazione GUI variano in complessità: da strumenti simili ai test unitari fino a strumenti complessi e completi necessari per gestire ambienti, build applicative, enormi carichi di dati di test, messaggistica e sincronizzazione tra piattaforme e ambienti, oltre che notifiche e comunicazioni verso i membri del team.

Alcuni strumenti proprietari dispongono di utility o harness per gestire, eseguire e produrre report su suite di test automatizzati. Questi strumenti hanno valore variabile, perciò molte organizzazioni sviluppano i propri framework di automazione dei test per estenderne le funzionalità. Negli ultimi anni l’ambito dei framework di automazione è cresciuto e non esiste più una definizione unica o semplice; ora vediamo quindi cosa possono offrire questi framework ai team di sviluppo software.

Un framework di automazione dei test estende la funzionalità dei motori di esecuzione dei test.

Configurazione delle Suite di Test

Il framework integra i test automatizzati in raccolte o cluster significativi di test. Queste raccolte sono configurabili, così che i test possano essere eseguiti in una gerarchia di sequenze, gruppi, o selezioni arbitrarie. Questi strumenti possono includere funzionalità per guidare i test tramite dati predefiniti in tabelle di dati di test. Questo è il tipo di framework più semplice — gli strumenti più diffusi offrono di solito una qualche forma di configurazione delle suite di test.

Set-up e Tear-Down

Il framework gestisce tutte le attività di preparazione e pulizia (set-up e tear-down) per un singolo test, una raccolta o un’intera suite. Il set-up può prevedere la creazione da zero di ambienti di test, configurazioni complete, e il precaricamento di database di test e altre fonti dati. Il tear-down può comportare il ripristino o l’eliminazione dei dati di test o la cancellazione o il reset parziale o completo degli ambienti. Il framework potrebbe integrarsi con strumenti di orchestrazione delle pipeline o esserne controllato.

Gestione delle Eccezioni

Un fallimento in qualsiasi test – sia nel sistema in prova sia per una perdita di sincronizzazione – può essere gestito in modo coerente tramite la segnalazione dell’evento e di solito consentendo al resto dei test di quella raccolta di continuare a essere eseguiti. Il framework può essere programmato per gestire i fallimenti dei controlli di test, la perdita di sincronizzazione, i time-out di esecuzione e altri esiti selezionati dei test — ciascuno con procedure personalizzate.

Logging e Messaggistica

Il framework registra l’esecuzione e lo stato dei test in modo coerente su tutte le raccolte di test. Il framework genera report dagli strumenti che eseguono i test o fornisce un resoconto coerente di tutte le attività di set-up, esecuzione e pulizia dei test. Il framework può interagire con ChatOps bot per informare il team sulle eccezioni e permettere ai membri del gruppo di mettere in pausa, fermare, ripetere o riavviare le suite di test.

Astrazione dei Test tramite Linguaggio Specifico di Dominio

Negli ultimi anni sono emersi sul mercato due tipi distinti di framework che astraono il codice dei test in modelli, o in testo leggibile da persone/non tecnico:

• I framework a parole chiave (keyword-driven) permettono di definire i test utilizzando parole chiave. Le chiamate alle funzionalità del motore di esecuzione vengono implementate come comandi in linguaggio vicino all’inglese con segnaposto per parametri o dati. Si possono definire moduli riutilizzabili definiti dall’utente richiamabili tramite comandi in linguaggio naturale nello stesso modo. Esistono framework di questo tipo per ogni genere di interfaccia, inclusi GUI, servizi, API, interpreti da riga di comando e così via. Gli script possono esercitare funzionalità su diverse piattaforme operative e dispositivi.
• I framework Behaviour-Driven Development (BDD) permettono di raccogliere storie e scenari (esempi) che descrivono il comportamento delle funzionalità tramite un linguaggio specifico di dominio (DSL). Il linguaggio più diffuso è il cosiddetto Gherkin, che utilizza la struttura “dato … quando … allora …” per descrivere gli esempi. "Dato/Quando/Allora" rappresentano rispettivamente pre-condizioni, passi ed esiti (post-condizioni) dei casi di test. Gli strumenti BDD convertono il testo dato/quando/allora in “step call” in un linguaggio di programmazione. Lo sviluppatore (o tester) deve implementare i ‘fixture’ o il codice che effettua chiamate al motore di esecuzione dei test. In questo modo il linguaggio del requisito (la storia) può essere collegato direttamente al codice di esecuzione effettivo.

Framework basati su modelli

In questo caso, gli strumenti permettono di creare un modello del sistema sotto test. Questo può essere ricavato automaticamente da una pagina web dove lo strumento esegue la scansione dell’HTML, rileva i moduli e i campi, e costruisce un modello dal quale i percorsi attraverso i moduli possono essere generati automaticamente o selezionati dal tester. Anche le mappe oggetti per app mobile o altri dispositivi smart possono essere costruite manualmente. Utilizzando i percorsi nella mappa oggetti, le chiamate alle funzionalità del motore di esecuzione dei test vengono effettuate in modo simile agli strumenti BDD e guidati da parola chiave. In linea di principio, i test possono essere costruiti graficamente senza codice. Gli strumenti in quest’area sono relativamente nuovi e stanno migliorando rapidamente. Ci si aspetta che il loro utilizzo acceleri nel prossimo futuro.

Iscriviti alla newsletter di The QA Lead per ricevere una notifica quando le nuove parti della serie saranno pubblicate. Questi post sono estratti dal corso Leadership In Test di Paul che ti consigliamo vivamente per approfondire questo e altri argomenti. Se decidi di seguirlo, utilizza il nostro codice sconto esclusivo QALEADOFFER per ottenere $60 di sconto sul prezzo intero del corso!

Lettura correlata: 10 MIGLIORI STRUMENTI DI MONITORAGGIO DEI SERVER WEB