Costruire casi di test che non fanno schifo (e come evitare errori comuni)

Il test del software è una componente cruciale del ciclo di vita dello sviluppo del software. Senza di esso, si potrebbero perdere problemi di funzionalità o grossi difetti di usabilità che finiscono per frustrare gli utenti finali. Ma tutti i casi di test non sono creati uguali. Scrivere casi di test efficaci e di alta qualità è importante quanto testare le applicazioni. Infatti, casi di test scadenti possono risultare in un processo di test che è poco più efficace del non fare alcun test.

Quindi, cosa hanno in comune i casi di test scritti male? Come possono i professionisti del test del software scrivere casi di test di qualità evitando gli errori comuni? Per scoprirlo, abbiamo cercato sul web i migliori consigli per scrivere casi di test efficaci e abbiamo contattato un gruppo di professionisti dello sviluppo e tester del software chiedendo loro di pesare su questa domanda:

“Cosa hanno in comune i casi di test mal costruiti (e come possono gli sviluppatori evitare questi errori)?”

Incontra il nostro gruppo di esperti di test del software:

Scopri cosa hanno detto i nostri professionisti leggendo le loro risposte qui sotto.

Avaneesh Dubey

@qsometests

Avaneesh Dubey è il CEO di Qsome Tech. La sua carriera è costellata da una forte serie di innovazioni in diversi aspetti del business: Persone, processi e tecnologia. Ora, sta costruendo Qsome Tech come un innovatore all’avanguardia nell’area della Qualità del Software.

“Ci sono alcune cose che molti casi di test mal costruiti hanno in comune…”

1. Troppo specifici – eseguono solo una specifica condizione di test.

I test case devono considerare una varietà di condizioni che il software dovrà gestire. Il test case deve essere in grado di testare in modo completo il modulo software con quasi tutte le possibili combinazioni di condizioni principali. Per essere in grado di testare esaustivamente tutte le combinazioni di condizioni, l’autore deve trovare un modo per presentare queste condizioni in modo che sia facile per gli altri rivedere.

2. Coprire una piccola parte di funzionalità – hanno bisogno di testare una parte più grande del sistema.

I casi di test spesso si concentrano su una funzione specifica. Spesso questa funzione è determinata dalla progettazione tecnica interna del software. Invece, i casi di test devono riflettere i modelli e i flussi di utilizzo. Ogni caso di test dovrebbe cercare di coprire quanto più possibile il flusso – andando oltre i confini tecnici dell’applicazione sottostante.

3. Test secondo un ruolo utente specifico.

Abbiamo spesso visto casi di test scritti per un ruolo utente specifico. Questo li limita nella loro portata e quindi compromette significativamente la loro efficacia. I casi di test più efficaci riflettono i modelli di utilizzo. Un’applicazione di business, per esempio, dovrebbe essere testata con casi di test progettati per testare l’intero processo di business – coprendo tutti i ruoli utente e tutti i sistemi che potrebbero essere coinvolti nel processo di business.

4. Scritti per provare che i casi d’uso più comuni sono coperti bene nell’applicazione.

Questo, a mio parere, è uno dei problemi più comuni ed è il risultato di quello che io chiamo un approccio “pigro” alla progettazione dei test. Il progettista di test ripete semplicemente il documento dei requisiti nei casi di test. Il progettista di test dovrebbe invece cercare i “casi d’angolo” o le “condizioni limite”. La maggior parte degli sviluppatori sono facilmente in grado di scrivere codice per i casi d’uso più comuni. I problemi emergono nel momento in cui c’è una condizione del caso d’uso più comune. Un test case ben progettato li cattura facilmente.

5. Qualsiasi caso di test può diventare completamente inutile se non catalogato sistematicamente e tenuto a disposizione per l’uso.

Immaginate una biblioteca con libri non catalogati e non tenuti sistematicamente sugli scaffali. Sarebbe impossibile usare i libri se non si possono trovare con facilità quando servono.

Spesso centinaia di casi di test vengono scritti con molto sforzo e poi scaricati in una struttura di cartelle condivisa. Mentre questo può funzionare se si hanno pochi casi di test, questo crolla nel momento in cui il numero di casi di test aumenta. Perciò, abbiamo bisogno di un tag e di una catalogazione sistematica dei casi di test. Poi un sistema di gestione dei test dovrebbe essere in grado di “tirare fuori” i casi di test quando hanno bisogno di essere eseguiti. Creare e mantenere versioni multiple dei casi di test è cruciale.

Wes Higbee

@g0t4

Wes Higbee è il presidente della Full City Tech Company.

“Il codice di test che è stato forzato è di solito senza valore…”

Forse c’è una regola che deve esserci il 100% di copertura del codice, o che non si può aggiungere codice senza almeno un test. Così la gente scrive solo abbastanza codice di test per soddisfare quella regola. È un lavoro d’ufficio glorificato, rapporti TPS (Office Space).

Le persone imparano imitando ciò che osservano. Quindi, se si richiede il test senza aiutare le persone a capire il valore del test, allora tendono a vederlo come un cerimoniale e cercano solo di copiare i test esistenti e inserire il loro caso d’uso.

Il test non è un fine in sé. I test, quando sono utili, danno fiducia, possono far risparmiare tempo e possono salvaguardare i cambiamenti futuri. Quindi se le persone che hanno sperimentato questi benefici possono trasmetterli ai colleghi, allora altre persone cercheranno questi benefici e questo spesso porta a test produttivi.

Le persone che hanno sperimentato i benefici dei test dovrebbero cercare di esaltare questi benefici, non i test stessi. Per esempio, se si prende del codice complicato in un sistema software reale che in passato è stato pieno di bug, e si mettono alcuni semplici test intorno ad esso e non si hanno più quei bug – allora la fiducia salirà, le persone non saranno così spaventate, e se ne ricorderanno e porteranno i test al tavolo quando si sentiranno incerti.

Non c’è bisogno di imporre dei test se le persone hanno sperimentato i benefici in prima persona.

Bernard Perlas

@MyCorporation

Bernard Perlas è un Quality Assurance Manager di MyCorporation che ha studiato alla DeVry University. Esegue i test per i prodotti esistenti e gli aggiornamenti dei prodotti e dei sistemi interni. Lavora alla progettazione di test di automazione dell’interfaccia utente e di test grey-box del sito per garantire che le informazioni siano corrette.

“I casi di test mal costruiti hanno in comune dei passi di test vaghi…”

Per evitare questi errori, è necessario essere specifici riguardo a ciò che si sta testando ed essere chiari sui passi da seguire. Più si è specifici, più si è in grado di replicare i problemi e identificare le aree di miglioramento e agire di conseguenza.

Benjamin Waldher

@wildebeest_dev

Benjamin Waldher è il Lead Dev Ops Engineer di Wildebeest.

“I casi di test scadenti sono spesso molto dipendenti da…”

Il funzionamento interno del codice da testare, il che può significare che se i dettagli interni di una funzione vengono cambiati, allora il caso di test si rompe – anche se la funzione funziona già correttamente. Se vi sembra di fare questo errore, potrebbe essere perché le funzioni che state testando sono troppo lunghe, o potreste aver bisogno di esercitare una maggiore separazione delle preoccupazioni.

Matt MacPherson

@itsMattMac

Matt MacPherson è il fondatore di Edabit.

“Ci sono alcune cose che i test case mal costruiti hanno in comune…”

1. Testare cose irrilevanti

Testare senza un vero scopo è inutile. Sono un grande fan del principio della singola responsabilità. Ogni test unitario dovrebbe testare una cosa e basta.

2. Testare subito

Probabilmente mi beccherò un sacco di critiche per questo, ma non faccio mai test unitari finché le mie decisioni di design non si sono consolidate. Questo perché so che sono destinato a fare cambiamenti piuttosto grandi e questi cambiamenti probabilmente romperanno molti dei miei test. Questo significa che in pratica o finirò per scrivere meno test o non farò grandi cambiamenti nel design. Entrambe le cose non vanno bene, e aspettare la chiarezza del design risolve il dilemma.

3. Test di integrazione vs. unit testing

Vedo molti sviluppatori fare test di integrazione quando in realtà stanno cercando di fare test unitari (e viceversa). Quando si testa l’applicazione nel suo insieme per i bug, è considerato un test di integrazione. Il test unitario si occupa di una specifica unità di comportamento del codice, mentre il test di integrazione si occupa del comportamento dell’applicazione nel suo complesso.

Manu Singh

@ClrMobile

Manu Singh è un Mobile Architect presso Clearbridge Mobile con esperienza nella progettazione, sviluppo e test Android. In Clearbridge, Manu gestisce le risorse di progetto per un team di sviluppatori che costruiscono applicazioni di livello mondiale per clienti aziendali.

“Ci sono diversi punti in comune tra i casi di test mal costruiti…”

In primo luogo, i casi di test potrebbero essere troppo semplici, nel senso che testano solo la funzione principale senza testare troppi casi estremi. Per evitare questo, uno sviluppatore dovrebbe coprire quanti più casi limite possibili. Se si sta sviluppando un’interfaccia che richiede un input che non è banale, allora è importante testare per input cattivi o vuoti.

In secondo luogo, casi di test mal costruiti non riflettono come un utente percepirà e userà la funzionalità. Creare casi di test per questo è più difficile da fare, poiché dovete entrare nella mentalità di un altro utente. Considerate di segmentare i vostri utenti e di identificare i loro casi d’uso. Poi identificate i percorsi più rapidi per completare un percorso utente, poiché un utente cercherà di ridurre il numero di passi che deve inserire per completare un determinato percorso. È importante qualificare i diversi casi d’uso, con i designer e i project manager per identificare ulteriormente questi tipi di casi di test.

E infine, un caso di test mal costruito non testa gli aspetti di un’app che potrebbero causare un avvio parallelo o successivo. Molto spesso i casi di test test testano solo una specifica caratteristica di un’app senza vedere le ramificazioni di più caratteristiche abilitate e interfacciate. Considerare casi di test interfunzionali è importante, specialmente se ci sono vincoli di performance. Due funzioni apparentemente separate possono consumare le stesse risorse, causando così dei deadlock.

Rick Rampton

@QASource

Rick Rampton è Head of Client Success alla QASource, e si occupa di marketing, vendite e gestione dei clienti. È stato determinante nella costruzione di QASource, con una comprovata esperienza nella costruzione, gestione e mantenimento di team di ingegneri offshore ad alte prestazioni. Con sede a Pleasanton, in California, QASource è uno dei principali fornitori di software QA al mondo.

“Ci sono molteplici identificatori con cui possiamo riconoscere un test case mal costruito…”

1. Molte volte, un riassunto dei test case scadenti non evidenzia l’obiettivo del test case, o ciò che deve essere raggiunto.
2. I prerequisiti per l’esecuzione del test case non sono chiaramente definiti o mancano, il che può causare confusione allo sviluppatore/tester su quali dati o condizioni di test sono richiesti prima di eseguire il test case.
3. Se ci sono passi mancanti nei test case, allora lascia delle lacune allo sviluppatore/tester, facendogli fare delle supposizioni durante l’esecuzione dei test case. Questo può causare un’esecuzione imprecisa dei test case e la perdita di scenari importanti.
4. L’assenza del giusto ambiente per l’esecuzione dei test case è un altro indicatore di test case mal costruiti.
5. Se il risultato atteso non è chiaramente descritto nel test case, allora il tester non sarà sicuro dei risultati che deve verificare con quel test case.

Rachel Honoway

@rachelhonoway

Rachel è una dirigente esperta specializzata in startup Internet e aziende in crescita. La sua carriera è stata trascorsa lavorando in prima persona con gli imprenditori per costruire e far crescere prodotti SaaS e servizi correlati.

“La sequenza degli eventi è spesso troppo semplificata, portando ad un test case mal costruito…”

Gli sviluppatori tendono a supporre un percorso dritto e logico dall’inizio alla fine. In realtà, però, gli utenti finali prenderanno un numero esponenziale di percorsi, molti dei quali illogici. Quando gli sviluppatori non si prendono il tempo di considerare tutte le variabili che possono influenzare l’utente nel momento in cui si trova di fronte alla caratteristica/pagina/funzione, lasciano molto spazio per test falsi positivi.

In definitiva, gli sviluppatori dovrebbero osservare diversi utenti mentre interagiscono con la piattaforma, e poi spendere un po’ di tempo chiedendo ai sostenitori dei clienti interni (supporto clienti, product manager, agenti di vendita) di capire meglio l’utente. Gli agenti di vendita possono aiutare a definire chi è l’utente e descrivere il bisogno che l’applicazione sta soddisfacendo. I rappresentanti dell’assistenza clienti possono identificare i punti critici comuni per la base di utenti, come le password perse o i comuni detrattori dell’attenzione come le pubblicità sulla pagina. I product manager possono fornire informazioni su come l’utente interagisce con l’applicazione e come questa interazione si inserisce all’interno del flusso di lavoro o della routine quotidiana dell’utente, descrivendo le distrazioni che si verificano al di fuori dell’applicazione stessa (gestione di più schermi contemporaneamente, utenti mobili che ricevono notifiche mentre guidano, ecc).

Capire cosa può portare l’utente finale lontano dal percorso logico e dritto aiuterà gli sviluppatori a testare queste variabili e garantire un’esperienza di successo nonostante le distrazioni, i percorsi illogici e la perdita di concentrazione.

Anthony Breen

@BreenAnthony77

Anthony Breen è il co-fondatore e CEO di The Feasty Eats app. Feasty Eats è una piattaforma SaaS integrata che aiuta i ristoranti a guidare il traffico durante i loro periodi di basso volume.

“Quando si considerano i casi di test…”

È importante per gli sviluppatori tornare ad alcuni degli aspetti più semplici, ma più importanti, del processo di indagine. Proprio come in un esperimento scientifico, ci sono due fattori che devono essere in primo piano nella mente di ogni sviluppatore per facilitare un test efficace e significativo: chiarezza e controllo. Più specificamente, ipotesi chiaramente delineate e un’attenta attenzione agli indicatori chiave di performance devono essere comunicati prima dell’inizio del test. Inoltre, è essenziale che tutte le variabili non solo siano identificate, ma anche accuratamente controllate. I bias devono essere eliminati dalle popolazioni dei test e le potenziali variabili di confondimento devono essere identificate in modo che gli sviluppatori possano acquisire dati perspicaci e accurati. Uno scopo ben definito e chiaramente articolato, quando accoppiato con un ambiente di test meticolosamente controllato, non solo produrrà risultati preziosi ma, cosa più importante, stimolerà nuove domande e ipotesi che porteranno a un’indagine più ampia.

Devlin Fenton

@devfen

Devlin Fenton è il CEO di Go99. Devlin guida un piccolo team specializzato di ingegneri e programmatori che si dedicano a risolvere i problemi dell’industria, per l’industria. Questo team ha recentemente lanciato una piattaforma digitale di corrispondenza dei carichi destinata a sconvolgere l’industria dei trasporti del Nord America (700 miliardi di dollari). Devlin crede che costruire un team di esperti e lasciarli prosperare.

“I peggiori casi di test sono quelli che non esistono…”

Di gran lunga, il problema maggiore è che non ce ne sono abbastanza e il sistema non può essere ritestato in modo affidabile e automatizzato. Manca la considerazione della priorità. Una volta che gli sviluppatori iniziano a scrivere casi di test, spesso sviluppano molti di quelli facili, che testano codice banale, statico e a basso rischio. Lo sforzo dovrebbe essere fatto per indirizzare il codice complesso e rischioso e per questo, a volte il caso d’uso è anche più complesso e più difficile da sviluppare.

La convinzione è che se non è un test unitario non dovrebbe essere fatto. I test di integrazione, i test dei dati, i test delle prestazioni, gli stress test e così via dovrebbero essere tutti parte della suite di test.

La mancanza di attenzione in termini di obiettivo è un altro problema. Per esempio, si tratta di un test unitario, di integrazione, di performance o di un altro tipo? Mischiare queste priorità rende i casi d’uso più fragili e più difficili da risolvere. Hanno bisogno di avere un focus e di essere annotati di conseguenza in modo che la suite di test possa essere eseguita in modo mirato.

Inoltre, alcuni casi di test mancano di completezza coprendo solo un percorso felice e non abbastanza dei flussi alternativi e di eccezione. In effetti, il caso d’uso segue lo standard make-it-work dello sviluppatore, invece dello standard make-it-fail del testing.

Un altro problema sono i casi di test che non sono mantenuti, il che li farebbe fallire se fossero eseguiti, o sono commentati del tutto. Nella fretta, gli sviluppatori spesso cambiano il codice e bypassano la correzione dei casi di test.

Casi di test mal costruiti possono anche mancare di chiarezza su cosa viene testato, incluso l’oggetto, il metodo o lo scenario. I casi di test dovrebbero seguire una convenzione (denominazione, commenti, ecc.) che rende facile identificare lo scopo del test.

Buoni casi di test evitano una rete di dipendenze. Le dipendenze tra i casi di test dovrebbero essere evitate; altrimenti, un singolo fallimento può mostrare molti test che falliscono, rendendo più difficile identificare la causa. Se c’è una logica comune per impostare le precondizioni o valutare i risultati, tale logica dovrebbe essere astratta e condivisa invece di impilare i casi di test.

Rohit Keserwani

@EquifaxInsights

Rohit Keserwani è un consulente BI e Sr. Business Analyst per Equifax.

“Ho osservato le seguenti caratteristiche comunemente presenti nei cattivi casi di test…”

1. Analisi dell’impatto non documentata. Quando un analista di test non documenta l’impatto, supponiamo che non conosca l’impatto. Il risultato? POOF…!

2. La pre-condizione del test non è definita o è poco articolata.

3. Trascurare il background dell’utente e supporre le cose. Se non capite il livello di conoscenza della persona che sta per testare, non assumete nulla. Documentate tutto nei minimi dettagli. In caso contrario, potreste finire per assumere alcune conoscenze che gli mancano, il che può indurre l’utente a testare in modo diverso dal previsto.

4. Criteri di passaggio e tolleranza non chiaramente definiti. Se per qualsiasi motivo i criteri di passaggio non sono articolati, la persona che fa il test è lasciata alla sua fantasia per decidere se un particolare test è passato o fallito. Se non si ha uno scenario di passaggio chiaramente definito, il tester non avrà un punto di riferimento con cui confrontarsi. Questo creerebbe ambiguità e alla fine metterebbe in gioco l’intero sforzo di test.

Pete Van Horn

@PraxentSoftware

Pete Van Horn è un Business Technology Analyst per Praxent.

“Ho molta esperienza con casi di test mal costruiti, e probabilmente sono anche colpevole di averli scritti di tanto in tanto…”

Molte volte, un caso di test non è facilmente eseguibile. Se sono uno sviluppatore, dovrei essere in grado di avere abbastanza informazioni ed essere posizionato in modo da poter eseguire il mio test case per determinare un risultato. Penso che una cosa sui casi di test è che non devono necessariamente portare al risultato desiderato, ma devono sempre essere eseguibili dall’inizio alla fine. Anche se si ottiene un risultato negativo, è meglio che rimanere bloccati. Un test case mal costruito non permette a chi sta facendo il test di eseguirlo completamente.

In termini di errori degli sviluppatori, forse ci sto pensando troppo, ma tipicamente gli sviluppatori non scrivono il test case. Potrebbero scrivere test unitari, ma un test case di solito è scritto da un analista di business o da un architetto di soluzioni. Sono incaricati di creare quello che dovrebbe essere il risultato atteso. Direi che avere casi di test ben scritti trova la sua genesi nell’avere requisiti davvero ben scritti. Avere buoni requisiti ti permette di creare un buon test case. E un buon test case è in grado di essere eseguito dall’inizio alla fine, senza interruzioni.

Hans Buwalda

@logigear

A Stackify, sappiamo quanto sia cruciale il test del software nel ciclo di vita dello sviluppo, quindi è un argomento che discutiamo regolarmente. Sapevi che puoi integrare APM nella tua strategia di testing? Scopri come qui.

Per altri consigli di esperti sulla scrittura di casi di test di qualità (e perché è come il metodo scientifico), controlla questo post, o visita questo articolo per una lista di 101 suggerimenti di esperti di test del software e consigli per ottenere il massimo dal tuo processo di test. Per uno sguardo più approfondito sui tipi di test delle prestazioni e di test del software, sui passi del test delle prestazioni e sulle migliori pratiche, visitate questa guida.