Una solida documentazione di test è alla base di qualsiasi pratica di ingegneria della qualità. Con Trupeer, puoi risparmiare ore nella stesura dei documenti di test partendo da modelli di documentazione gratuiti, personalizzandoli con le tue linee guida del brand e trasformando i piani di test in video dimostrativi che allineano ingegneria, prodotto e QA.

Cosa sono i modelli gratuiti di documentazione di test?

I modelli gratuiti di documentazione di test sono strutture riutilizzabili per i documenti prodotti da un'attività di testing: la strategia, il piano, i casi di test, i dati, i risultati e i report dei difetti.

La maggior parte delle ricerche in merito è in realtà incentrata su un unico documento. I casi di test sono ciò su cui i tester passano il tempo a scrivere, e un modello di caso di test è una tabella contenente dei passaggi, il che non è difficile.

I modelli non sono il problema. Ogni modello di caso di test pubblicato ha le stesse colonne: identificativo, titolo, precondizioni, passaggi, risultato atteso, risultato effettivo, stato. Questa struttura è corretta ed è rimasta stabile per decenni.

Ciò che non funziona nella maggior parte delle suite di test è il bilanciamento dell'impegno all'interno di quella struttura, e ciò produce casi di test che possono passare anche quando il sistema è in errore.

Il formato segue l'uso. Il download gratuito di un modello di casi di test in formato Excel è il formato di lavoro più comune e si adatta bene alla tabella dei casi. Un file Word per il modello di caso di test si adatta ai piani di test e alle strategie, che sono in formato testuale. Un PDF di esempio di documento di test è ciò che viene allegato a un record di rilascio come prova.

I documenti in un set di test

Sei documenti, ognuno dei quali risponde a una domanda diversa, ed è utile sapere di quali si ha effettivamente bisogno prima di adottare qualsiasi soluzione.

Strategia di test. Come questa organizzazione esegue i test, in generale. Scritta una sola volta, modificata raramente, si applica a tutti i progetti.

Piano di test. Cosa verrà testato in questa release o progetto, in quali ambienti, da chi, con quali criteri di ingresso e uscita e con quale pianificazione.

Casi di test. Le singole verifiche. Passaggi e, soprattutto, risultati attesi.

Script di test. L'equivalente automatizzato, in cui un caso è stato codificato anziché essere eseguito da una persona.

Dati di test. Con quali dati vengono eseguiti i casi, il che costituisce una documentazione a sé stante ed è spesso la parte meno controllata dell'intero set.

Risultati dei test e report dei difetti. Cosa è successo e cosa è stato segnalato. Questo è ciò che di solito si rivela essere un PDF di esempio di documento di caso di test quando se ne trova uno pubblicato, poiché i risultati sono la parte che le organizzazioni conservano.

Qualsiasi pacchetto di modelli di documentazione per il test del software dovrebbe coprire tutti e sei gli elementi, ma la maggior parte ne copre solo due. La maggior parte delle organizzazioni dispone del terzo e del sesto e improvvisa il resto. A questo si può sopravvivere. Ciò a cui non si può sopravvivere è che il terzo elemento sia scritto male, perché tutto ciò che viene dopo dipende da esso.

Come personalizzare questo modello in Trupeer

Passaggio 1: Apri la sezione Modelli

Vai alla sezione Modelli dalla navigazione principale.

Passaggio 2: Seleziona e apri un modello

Fai clic su qualsiasi modello con cui desideri lavorare per aprirlo.

Passaggio 3: Espandi la visualizzazione del modello

Se necessario, espandi la visualizzazione del modello per vedere chiaramente il layout completo e i dettagli.

Passaggio 4: Modifica il modello

Fai clic su Modifica per iniziare a modificare il modello selezionato.

All'interno dell'editor puoi:

• Aggiungere nuove sezioni

• Definire o aggiornare le regole di formattazione

• Aggiungere un logo e regolarne la posizione e le relative impostazioni

Passaggio 5: Salva il tuo modello personalizzato

Dopo aver apportato tutte le modifiche necessarie, fai clic su Salva per memorizzare il modello aggiornato come tuo.

Passaggio 6: Visualizza l'anteprima e perfeziona il modello

Quando desideri vedere come appare il tuo modello personalizzato, apri l'Anteprima.

Dalla schermata di anteprima, puoi continuare ad apportare modifiche direttamente, se necessario, assicurandoti che il modello appaia esattamente come desideri.

Con i modelli di documentazione di test puoi:

• Risparmiare ore di scrittura: Evita la pagina bianca grazie a strutture utilizzate da team di QA esperti.

• Migliorare la copertura dei test: Le sezioni integrate assicurano che non venga tralasciato nulla di importante.

• Rimanere in linea con il brand: Applica il tuo logo, i tuoi font e i tuoi colori utilizzando il kit del brand di Trupeer.

• Standardizzare tra i prodotti: Utilizza gli stessi modelli per ogni release e team.

• Essere sempre pronto per gli audit: Allineato con gli standard IEEE 829, ISO 29119 e simili.

• Raggiungere team globali: Traduci la documentazione di test in oltre 65 lingue con un solo clic.

Il risultato atteso è il caso di test

Leggi qualsiasi suite di test e guarda dove si trovano le parole.

I passaggi saranno dettagliati. Apri l'applicazione. Naviga nella schermata dei pagamenti. Seleziona la transazione. Fai clic su Rimborso. Inserisci l'importo. Conferma. Sette istruzioni precise, ognuna priva di ambiguità.

Poi guarda il risultato atteso. Dirà qualcosa del tipo: il rimborso viene elaborato con successo.

Quella riga rappresenta l'intero test. Tutto ciò che viene prima è configurazione. Ed è la riga che ha ricevuto meno riflessione, perché scrivere passaggi precisi è facile mentre definire cosa significhi "corretto" è difficile.

La conseguenza è che un tester segue sette istruzioni esatte, vede qualcosa che sembra un successo e segna "passato". Non ha fatto nulla di male. Il documento chiedeva se il rimborso fosse stato elaborato con successo, ha visto un messaggio di successo, e così è stato.

Ciò che il documento non ha mai chiesto è se fosse stato creato esattamente un solo rimborso, se il libro mastro si fosse spostato esattamente dell'importo corretto o se i sistemi a valle avessero ricevuto un duplicato.

Un caso di test il cui risultato atteso può essere soddisfatto da una lettura ottimistica dell'interfaccia è un caso di test che passerà ogni volta che il tester ha fretta, il che accade quasi sempre in prossimità di una release.

Scrivere un risultato atteso che possa fallire

Tre proprietà, facili da verificare su una suite esistente.

Nomina uno stato, non un'impressione. Non "il record si salva correttamente" ma "il record appare nell'elenco con stato Attivo e un timestamp di modifica entro l'ultimo minuto".

È verificabile al di fuori dell'elemento che ha eseguito l'azione. Questa è la proprietà che individua i difetti più costosi. Se l'azione è avvenuta nell'interfaccia utente, il risultato atteso più forte è quello verificato altrove: nel database, su un report, nel sistema a valle, su un estratto conto. Le interfacce sono brave a segnalare il successo e pessime a riferire ciò che è realmente accaduto sotto.

Potrebbe fallire senza che il sistema sembri rotto. Se l'unico modo per far fallire il test è un errore visibile, il test rileva solo gli errori che si annunciano da soli. Gli errori silenziosi sono il motivo per cui esistono i casi di test e ciò che i risultati attesi vaghi mancano regolarmente.

Un audit pratico richiede un pomeriggio su una suite di poche centinaia di casi. Leggi solo i risultati attesi, ignorando i passaggi. Conta quanti potrebbero essere soddisfatti guardando solo lo schermo e quanti usano parole come correttamente, con successo, come previsto o senza errori, che non sono affatto risultati. Nella maggior parte delle suite entrambi i conteggi sono alti.

Cosa deve contenere un modello di caso di test

Nove campi. Il modello non è il problema, le indicazioni relative a due di questi campi lo sono.

La distinzione tra bloccato e non eseguito è più importante di quanto sembri. Una suite che riporta il novanta percento di superamento potrebbe aver eseguito solo il sessanta percento dei suoi casi, e la differenza è invisibile se tutto ciò che non è superato viene registrato allo stesso modo.

Modelli gratuiti di documentazione di test: la struttura da copiare

Compilato con un esempio reale anziché con segnaposto. Il sistema è una piattaforma di elaborazione dei pagamenti.

Copia da qui.

Piano di test, in sintesi. Ambito: elaborazione dei rimborsi per la release 4.9. In ambito: rimborsi totali, rimborsi parziali, rimborsi a fronte di transazioni regolate e non regolate. Fuori ambito: chargeback, che rimangono invariati. Ambienti: staging con volumi di dati simili a quelli di produzione. Criteri di ingresso: build distribuita, smoke test superato, dati di test caricati. Criteri di uscita: tutti i casi di priorità uno superati, nessun difetto di priorità uno o due aperto, riconciliazione del libro mastro pulita su tutta l'esecuzione.

Caso di test.

Identificativo: TC-118. Titolo: Il rimborso totale a fronte di una transazione regolata crea esattamente una voce di rimborso.

Priorità: Uno.

Precondizioni: Esiste l'account commerciante M-4471 con una transazione regolata T-88210 di 240,00. Saldo del libro mastro per M-4471 registrato prima di iniziare. Il tester ha l'autorizzazione al rimborso.

Passaggi.

1. Apri la schermata dei pagamenti e cerca T-88210.

2. Seleziona la transazione e scegli Rimborso.

3. Inserisci 240,00 e conferma.

Risultato atteso. Quattro condizioni, tutte valide.

Esiste un record di rimborso a fronte di T-88210, e solo uno. Verificato nella tabella dei rimborsi, non nell'interfaccia.

Il saldo del libro mastro del commerciante per M-4471 è diminuito esattamente di 240,00 rispetto al valore iniziale registrato. Verificato sul report del libro mastro.

L'estratto conto del commerciante per il periodo mostra una singola riga di rimborso di 240,00.

Lo stato della transazione mostra Rimborsato nell'interfaccia.

Si noti che il controllo dell'interfaccia è l'ultimo ed è il più debole dei quattro. È incluso perché gli utenti lo vedono, non perché verifichi qualcosa.

Risultato effettivo: registrato al momento dell'esecuzione, con le cifre del libro mastro osservate anziché presunte.

Stato: superato, fallito, bloccato o non eseguito.

Prova: output della query dalla tabella dei rimborsi e una copia della riga del report del libro mastro.

Report del difetto, in caso di fallimento. Identificativo del caso, cosa era atteso, cosa è stato osservato, ambiente, build, dati utilizzati, passaggi per riprodurre, gravità. Il campo dei dati utilizzati è quello più spesso omesso ed è quello che più frequentemente impedisce la riproduzione.

Copia fino a qui.

Esempio di documentazione di test: trecentotrentotto superati

Brayford Payments elabora pagamenti con carta per piccoli commercianti ed impiega circa duecento persone. Ha rilasciato un flusso di rimborso revisionato.

Il modulo dei pagamenti aveva trecentoquaranta casi di test. Il test di accettazione utente (UAT) ha eseguito l'intera suite. Trecentotrentotto sono superati. Due sono falliti, sono stati corretti e testati nuovamente.

In produzione, i rimborsi superiori a un certo valore venivano applicati due volte in una particolare condizione di tempistica. Il sistema è rimasto attivo per nove giorni prima che qualcuno se ne accorgesse, producendo circa millequattrocento rimborsi duplicati per un valore di quattrocentododicimila sterline. Recuperare il denaro già pagato ai commercianti è stato lento e complicato, ed è rientrato circa il sessanta percento.

Il caso TC-118 copriva i rimborsi. Aveva sette passaggi dettagliati e un risultato atteso che recitava: il rimborso viene elaborato con successo.

Il tester ha seguito tutti e sette i passaggi, ha visto un messaggio di conferma e uno stato di Rimborsato, e ha registrato un esito positivo. Questa è stata una corretta applicazione del documento che aveva davanti.

Nessuno ha guardato il libro mastro. Nulla nel caso chiedeva di farlo. Un rimborso singolo e un rimborso doppio appaiono identici nella schermata di conferma, ed è esattamente per questo che il controllo doveva avvenire altrove.

L'audit successivo ha esaminato tutti i trecentocinquanta risultati attesi, ignorando i passaggi.

Duecentoundici potevano essere soddisfatti osservando solo l'interfaccia utente. Quarantasette non contenevano alcuna dichiarazione verificabile, utilizzando frasi come funziona come previsto, si comporta correttamente o si completa senza errori.

Il rimedio è stato di tre settimane di riscrittura, non di nuovi test. Ogni risultato atteso doveva nominare uno stato, specificare dove veniva controllato ed essere in grado di fallire senza un errore visibile. Laddove il controllo naturale era al di fuori dell'interfaccia, è lì che è stato posizionato. Alcuni casi sono stati accorpati e la suite è scesa a duecentonovanta.

Due release dopo, i difetti riscontrati durante i test di accettazione degli utenti sono passati da una media di quattro per release a diciannove.

L'aumento di quel numero è il risultato. I difetti di produzione nei sei mesi successivi sono passati da undici a due.

La suite non era troppo piccola. Aveva semplicemente posto trecentoquaranta domande a cui il sistema poteva rispondere in modo ottimistico.

Come scrivere casi di test in sei passaggi

1. Scrivi il risultato atteso prima dei passaggi. Inverte l'ordine abituale e ti costringe a decidere cosa significhi "corretto" prima di descrivere come arrivarci. I passaggi scritti successivamente sono più brevi e più pertinenti.

2. Indica dove viene controllato il risultato. Interfaccia, database, report, sistema a valle. Indicare la posizione è ciò che rende un risultato verificabile da qualcun altro.

3. Chiediti come potrebbe passare pur essendo sbagliato. Se riesci a rispondere, il risultato atteso ha bisogno di un'altra condizione.

4. Poi scrivi i passaggi, un'azione ciascuno. Sono la parte facile e dovrebbero richiedere meno tempo.

5. Registra le precondizioni, inclusi i dati. La maggior parte dei fallimenti nel riprodurre un difetto è dovuta a dati diversi anziché a passaggi diversi.

6. Assegna le priorità in modo onesto. Nessuno esegue l'intera suite prima di una release. Decidere in anticipo quali casi contano è meglio che decidere alle nove di sera del giorno precedente.

Il primo passaggio costituisce l'intero metodo. I passaggi due e tre sono quelli che rilevano i difetti che altrimenti raggiungerebbero la produzione.

Casi di test contro scenari di test

I due termini vengono usati in modo intercambiabile, ma la differenza risiede nel livello di dettaglio.

Uno scenario di test è cosa testare, descritto a un livello comprensibile da chiunque. Verificare che i rimborsi funzionino correttamente per le transazioni regolate. Si tratta di una dichiarazione di copertura.

Un caso di test è come testarlo, con dati specifici, passaggi specifici e un risultato atteso specifico. Uno scenario produce solitamente diversi casi.

La disciplina utile consiste nello scrivere prima gli scenari, concordando la copertura con persone che comprendono il business, e poi scrivere i casi sottostanti. Fare il contrario produce una suite che copre solo ciò che la persona che la scrive ha pensato in quel momento.

Uno scenario che produce un solo caso è solitamente uno scenario che non è stato analizzato adeguatamente. I rimborsi per transazioni regolate dovrebbero produrre casi per l'importo totale, un importo parziale, un importo superiore all'originale, un secondo tentativo di rimborso sulla stessa transazione e un rimborso su una transazione già rimborsata. Quattro di questi cinque casi sono i punti in cui si nascondono i difetti.

Strategia di test, piano di test e piano di QA

Tre documenti al di sopra dei casi di test, e le differenze hanno un peso pratico.

Una strategia di test è organizzativa e a lungo termine. Come testiamo, quali tipi di test utilizziamo, quali sono i nostri standard. Si applica a tutti i progetti e viene modificata raramente.

Un piano di test è specifico per una release o un progetto. Ambito, ambienti, criteri di ingresso e uscita, pianificazione, risorse, rischi. Il download gratuito di un modello di piano di test in Excel ti fornirà una pianificazione e una matrice, mentre le sezioni testuali appartengono a un documento.

Un piano di QA è più ampio di entrambi, perché l'assicurazione della qualità include tutto ciò che viene fatto per prevenire i difetti anziché per trovarli: revisione dei requisiti, definizione di "done" (completato), standard di revisione del codice, parità degli ambienti. Il modello di piano di QA copre questa distinzione, e qui è importante perché un documento intitolato piano di QA che contiene solo fasi di test è diventato silenziosamente un piano di test.

La prova pratica è la tempistica. Le attività che avvengono prima che il lavoro sia completato sono di assicurazione (assurance). Le attività che avvengono dopo sono di controllo, e il testing è controllo.

Cosa non possono risolvere i modelli gratuiti di documentazione di test

Requisiti su cui nessuno ha concordato. Un caso di test verifica il comportamento rispetto a un'aspettativa, e laddove l'aspettativa non è mai stata stabilita, i tester scrivono casi basandosi sulla propria ipotesi.

Una suite troppo grande da eseguire. Ogni organizzazione raggiunge il punto in cui l'intera suite di regressione non rientra nei tempi previsti. Stabilire le priorità deliberatamente è meglio che farlo sotto pressione, e nessun download gratuito di modelli di casi di test in Excel lo farà per te.

Un risultato atteso vago. Nessun modello di caso di test scaricabile gratuitamente e nessun layout Excel semplice lo scriverà al posto tuo, ed è l'unico campo che decide se il caso funziona.

Dati di test che non rappresentano la produzione. Il difetto di Brayford richiedeva una particolare condizione temporale e un volume di dati realistico. Nessuno dei due esisteva nell'ambiente di test, e nessun modello affronta questo problema.

Tester senza l'autorità di bloccare. I criteri di uscita che possono essere ignorati da chiunque voglia effettuare la spedizione non sono criteri.

Mostra il test invece di descriverlo

Due problemi in quest'area rappresentano in realtà lo stesso problema, ed entrambi riguardano le prove.

La prova di un test è normalmente una spunta in una colonna di stato. Qualcuno ha eseguito il caso e dice che è superato. Se in seguito compare un difetto in quell'area, non c'è modo di stabilire cosa sia stato effettivamente osservato, quindi la domanda se il caso sia stato eseguito correttamente non può trovare risposta e di solito si trasforma in una discussione.

Il secondo problema è che un nuovo tester che si unisce a un team impara cosa significa controllare correttamente osservando qualcuno, e se nessuno ha tempo, lo impara dai documenti, che è da dove proviene la lettura ottimistica.

Trupeer AI affronta entrambi. La registrazione dell'esecuzione di un test produce una guida scritta con screenshot già catturati e posizionati, insieme al video, con il branding della tua azienda. Ciò che è stato effettivamente osservato in ogni passaggio viene catturato anziché asserito, il che rappresenta la prova di cui ha bisogno un record di rilascio e il materiale da cui impara un nuovo tester.

Registralo. Personalizzalo con il tuo brand. Traducilo. Usa Trupeer.

Ne conseguono due punti. Registrare un tester esperto che esegue un caso complesso mostra i controlli che effettua al di fuori dell'interfaccia, che è esattamente l'abitudine che i casi scritti non riescono a trasmettere. E laddove i test vengono eseguiti in più sedi o da un team esternalizzato, la stessa registrazione definisce lo stesso standard di controllo anziché lasciarlo all'interpretazione.

Il materiale risiede nella tua base di conoscenza e funge anche da formazione per i nuovi tester. Se la release possa essere rilasciata o meno è una questione separata, coperta nel modello dei requisiti di release. La coerenza tra i tuoi documenti è una questione di impostazione del kit del brand una sola volta, e la configurazione è coperta nella guida alla configurazione del modello di documento.

Domande Frequenti

Esiste un modello di casi di test in Excel da scaricare gratuitamente?

Excel è il formato di lavoro standard per i casi di test ed è molto adatto ad essi, perché una suite è una tabella da filtrare per modulo, priorità e stato. Il download gratuito di un modello di casi di test in Excel ti fornirà le colonne standard ed è davvero ottimo come punto di partenza.

Vale la pena fare due aggiunte. Una colonna che registri dove viene controllato il risultato atteso (interfaccia, database, report o sistema a valle). E valori di stato separati per bloccato e non eseguito, poiché accorparli nasconde quanta parte della suite sia stata effettivamente eseguita.

Esiste una versione Excel semplice del modello di caso di test?

Sì, e la semplicità di solito è la scelta migliore. Un layout Excel semplice per il modello di caso di test con identificativo, titolo, priorità, precondizioni, passaggi, risultato atteso, risultato effettivo e stato copre quasi tutto.

Evita di aggiungere troppe colonne. I modelli di casi di test accumulano campi che sembrano utili in fase di progettazione e che poi rimangono vuoti all'atto pratico; una suite con otto colonne compilate è più utile di una con venti colonne di cui dodici vuote.

Esiste una versione Word del modello di caso di test?

Word si adatta ai documenti di contorno piuttosto che ai casi singoli. Un file Word per il modello di caso di test funziona bene per un piano di test, una strategia di test o una relazione riassuntiva, che sono tutti testi descrittivi.

Per i casi in sé, un documento è poco adatto. Non è possibile filtrarlo, non è possibile ordinarlo per priorità e aggiornare lo stato di duecento casi in una tabella di Word durante l'esecuzione di un test è così lento che le persone smettono di farlo con precisione.

Esiste un modello di caso di test scaricabile gratuitamente che valga la pena utilizzare?

Le colonne sono rimaste stabili per decenni, quindi un modello di caso di test scaricabile gratuitamente ti fa risparmiare pochissimo e ogni versione pubblicata è sostanzialmente identica.

Valutali in base a una sola domanda. La colonna del risultato atteso contiene delle linee guida o è solo una cella vuota? La cella vuota è il punto in cui la maggior parte delle suite di test fallisce, e nessun modello risolve questo problema, ma un modello che suggerisce dove controllare il risultato migliorerà ciò che vi viene scritto all'interno.

Esiste un modello di piano di test in Excel da scaricare gratuitamente?

Excel si adatta alla pianificazione, alla matrice di copertura e al piano delle risorse all'interno di un piano di test. Un modello di piano di test in Excel scaricabile gratuitamente in genere ti fornirà questi elementi.

La parte descrittiva appartiene a un documento: ambito, criteri di ingresso e uscita, ambienti, ipotesi e rischi. Questi elementi vengono letti e negoziati, e negoziare all'interno delle celle di un foglio di calcolo non funziona bene. Conserva entrambi e fai riferimento all'uno dall'altro.

Dove posso trovare un PDF di esempio di un documento di test?

I registri degli appalti del settore pubblico, i progetti universitari e alcuni enti di standardizzazione pubblicano documentazione di test reale, e un PDF di esempio di un documento di test proveniente da una di queste fonti è più istruttivo di un modello commerciale perché è stato prodotto con vincoli reali.

Leggi un PDF di esempio di documento di caso di test per i suoi risultati attesi piuttosto che per la sua struttura. La struttura si può copiare da qualsiasi parte. Come un team reale ha formulato l'aspetto corretto e se i loro controlli erano al di fuori dell'interfaccia è la parte che vale la pena imparare.

Dove posso trovare un PDF di esempio di un documento di caso di test?

Si applicano le stesse fonti, e i settori regolamentati sono i più ricchi, poiché le prove di test devono superare gli audit e di conseguenza tendono ad essere scritte in modo più preciso.

Quando leggi un PDF di esempio di un documento di caso di test, guarda se la colonna del risultato effettivo contiene osservazioni o spunte. Le spunte ti dicono che la suite è stata eseguita. Le osservazioni ti dicono cosa è stato visto, e solo la seconda opzione costituisce una prova.

Esiste un set di modelli di documentazione per il test del software?

Sì, e il set è composto da sei documenti: strategia, piano, casi, script, dati e risultati con report dei difetti. Un pacchetto di modelli di documentazione per il test del software di solito copre il piano e i casi, lasciando da parte il resto.

I dati di test sono l'elemento più comunemente mancante e quello che più spesso impedisce la riproduzione di un difetto. Documentare con quali dati viene eseguita la suite e come vengono aggiornati vale quanto altri cinquanta casi di test.