Usa questo modello
Una documentazione di test solida è alla base di qualsiasi pratica di ingegneria della qualità. Con Trupeer, puoi risparmiare ore nella stesura dei documenti di test partendo da modelli gratuiti di documentazione di test, personalizzandoli con le tue linee guida del brand e trasformando i piani di test in video walkthrough 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 le segnalazioni di difetti.
La maggior parte delle ricerche in merito riguarda in realtà un solo documento. I casi di test sono ciò che i tester passano il tempo a scrivere, e un modello di caso di test è una tabella contenente passaggi, il che non è difficile.
I modelli non sono il problema. Ogni modello di caso di test pubblicato presenta le stesse colonne: identificativo, titolo, precondizioni, passaggi, risultato atteso, risultato effettivo, stato. Questa struttura è corretta ed è rimasta invariata per decenni.
Ciò che non va nella maggior parte delle suite di test è l'equilibrio dell'impegno all'interno di quella struttura, producendo casi di test che possono risultare superati anche mentre il sistema è compromesso.
Il formato segue l'uso. Il download gratuito di un modello di casi di test in Excel è il formato di lavoro più comune ed è ideale per la tabella dei casi. Un file Word come modello per casi di test è adatto a piani di test e strategie, che sono testi discorsivi. Un PDF di esempio di documento di test è ciò che viene allegato a un record di rilascio come evidenza.
I documenti in un set di test
Sei documenti, ognuno dei quali risponde a una domanda diversa, ed è opportuno sapere di quali hai effettivamente bisogno prima di adottarne alcuno.
Strategia di test. Come questa organizzazione esegue i test, in generale. Scritta una sola volta, aggiornata raramente, valida per tutti i progetti.
Piano di test. Cosa verrà testato su questo rilascio o progetto, in quali ambienti, da chi, con quali criteri di ingresso e di uscita e con quale pianificazione.
Casi di test. Le verifiche individuali. I passaggi e, cosa fondamentale, i risultati attesi.
Script di test. L'equivalente automatizzato, in cui un caso è stato codificato anziché essere eseguito da una persona.
Dati di test. I dati su cui vengono eseguiti i casi, che costituiscono documentazione a sé stante e sono spesso la parte meno controllata dell'intero set.
Risultati dei test e segnalazioni di difetti. Cosa è accaduto e cosa è stato segnalato. Questo è ciò che di solito si rivela essere un PDF di esempio di un documento di casi di test quando ne trovi uno pubblicato, poiché i risultati sono la parte conservata dalle organizzazioni.
Qualsiasi pacchetto di modelli per la documentazione del software testing dovrebbe coprirli tutti e sei, ma la maggior parte ne copre 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 sia scritto male, perché tutto ciò che si trova a valle dipende da esso.
Come personalizzare questo modello in Trupeer
Passaggio 1: Apri la sezione Modelli
Vai alla sezione Modelli dalla barra di 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 personalizzare 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 tra i tuoi.
Passaggio 6: Visualizza l'anteprima e perfeziona il modello
Quando vuoi vedere l'aspetto del 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 con strutture utilizzate da team di QA esperti.
Migliorare la copertura dei test: Le sezioni integrate garantiscono che nulla di importante venga tralasciato.
Mantenere l'identità del brand: Applica logo, font e colori utilizzando il brand kit di Trupeer.
Standardizzare tra i prodotti: Usa gli stessi modelli per ogni rilascio e per ogni team.
Rimanere pronti per gli audit: Allineato con IEEE 829, ISO 29119 e standard 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 osserva dove sono posizionate le parole.
I passaggi saranno dettagliati. Apri l'applicazione. Vai alla schermata dei pagamenti. Seleziona la transazione. Fai clic su Rimborsa. Inserisci l'importo. Conferma. Sette istruzioni precise, ciascuna inequivocabile.
Poi guarda il risultato atteso. Dirà qualcosa come: il rimborso è elaborato con successo.
Quella riga è l'intero test. Tutto ciò che precede è configurazione. Ed è la riga a cui è stata dedicata meno attenzione, 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 spunta "passato". Non ha fatto nulla di sbagliato. Il documento chiedeva se il rimborso fosse stato elaborato con successo, ha visto un messaggio di successo, ed è andata così.
Ciò che il documento non ha mai chiesto è se fosse stato creato esattamente un rimborso, se il registro contabile si fosse spostato esattamente dell'importo giusto o se un sistema a valle avesse 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 un rilascio.
Scrivere un risultato atteso che può fallire
Tre proprietà, e sono facili da verificare su una suite esistente.
Nomina uno stato, non un'impressione. Non "il record si salva correttamente", ma "il record compare nell'elenco con stato Attivo e un timestamp di modifica entro l'ultimo minuto".
È verificabile all'esterno dell'elemento che ha eseguito l'azione. Questa è la proprietà che intercetta i difetti costosi. Se l'azione è avvenuta nell'interfaccia utente, il risultato atteso più forte è quello verificato altrove: nel database, in un report, nel sistema a valle, su un estratto conto. Le interfacce sono brave a segnalare il successo e poco efficaci nel riportare ciò che è realmente accaduto sotto il cofano.
Potrebbe fallire senza che il sistema appaia guasto. Se l'unico modo per fallire il test è un errore visibile, il test rileva solo gli errori che si manifestano palesemente. I problemi silenziosi sono ciò per cui i casi di test esistono e ciò che i risultati attesi vaghi mancano costantemente.
Una verifica pratica, che 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 elevati.
Cosa deve contenere un modello di caso di test
Nove campi. Il modello non è il problema; la guida relativa a due di questi campi lo è.
Campo | A cosa serve |
|---|---|
Identificativo | Stabile, mai riutilizzato, affinché i casi possano essere referenziati nelle segnalazioni di difetti e nelle discussioni sulla copertura. |
Titolo | Cosa viene testato, in una frase che qualcuno potrebbe cercare. |
Priorità | Perché nessuno esegue mai l'intera suite e, se non scegli tu, lo farà chiunque sia sotto pressione. |
Precondizioni | Stato, dati e accessi richiesti prima del primo passaggio. |
Passaggi | Un'azione ciascuno. La parte facile. |
Risultato atteso | Cosa deve essere vero, dove verificarlo e formulato in modo che possa fallire. L'intero test. |
Risultato effettivo | Cosa è stato osservato, compilato durante l'esecuzione, non una semplice spunta. |
Stato | Superato, fallito, bloccato, non eseguito. Bloccato e non eseguito sono diversi e raggrupparli nasconde lacune nella copertura. |
Evidenza | Screenshot, output di query, riferimento. Qualsiasi cosa mostri il risultato effettivo invece di limitarsi ad affermarlo. |
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 pagamenti.
Copia da qui.
Piano di test, in sintesi. Ambito: elaborazione rimborsi per la versione 4.9. In ambito: rimborsi completi, rimborsi parziali, rimborsi a fronte di transazioni contabilizzate e non contabilizzate. Fuori ambito: chargeback, che restano invariati. Ambienti: staging con volumi di dati simili alla 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 contabile corretta sull'intera esecuzione.
Caso di test.
Identificativo: TC-118. Titolo: Il rimborso completo su una transazione contabilizzata crea esattamente una voce di rimborso.
Priorità: Uno.
Precondizioni: L'account esercente M-4471 esiste con una transazione contabilizzata T-88210 di 240,00. Saldo contabile per M-4471 registrato prima dell'inizio. Il tester dispone dei permessi di rimborso.
Passaggi.
Apri la schermata dei pagamenti e cerca T-88210.
Seleziona la transazione e scegli Rimborsa.
Inserisci 240,00 e conferma.
Risultato atteso. Quattro condizioni, tutte valide.
Esiste un record di rimborso per T-88210, e solo uno. Verificato nella tabella dei rimborsi, non nell'interfaccia.
Il saldo del registro contabile dell'esercente per M-4471 è diminuito esattamente di 240,00 rispetto al valore iniziale registrato. Verificato nel report di mastro.
L'estratto conto dell'esercente per il periodo mostra una singola riga di rimborso pari a 240,00.
Lo stato della transazione mostra Rimborsato nell'interfaccia.
Nota che il controllo sull'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 contabili osservate anziché presunte.
Stato: superato, fallito, bloccato o non eseguito.
Evidenza: output della query dalla tabella dei rimborsi e copia della riga del report contabile.
Segnalazione difetto, in caso di fallimento. Identificativo del caso, cosa era previsto, cosa è stato osservato, ambiente, build, dati utilizzati, passaggi per riprodurre, gravità. Il campo dei dati utilizzati è quello omesso più di frequente e quello che più spesso impedisce la riproduzione.
Copia fino a qui.
Esempio di documentazione di test: trecentotrentotto test superati
Brayford Payments elabora pagamenti con carta per piccoli esercenti e conta circa duecento dipendenti. Ha rilasciato un flusso di rimborso rinnovato.
Il modulo dei pagamenti contava trecentoquaranta casi di test. Il test di accettazione utente ha eseguito l'intera suite. Trecentotrentotto sono risultati superati. Due sono falliti, sono stati corretti e sono stati testati nuovamente.
In produzione, i rimborsi superiori a un certo valore sono stati applicati due volte in una specifica condizione temporale (timing). È andata avanti per nove giorni prima che qualcuno se ne accorgesse, producendo circa millequattrocento rimborsi duplicati per un valore di quattrocentododicimila sterline. Recuperare il denaro già versato agli esercenti è stato lento e difficoltoso, e ne è stato recuperato all'incirca il sessanta percento.
Il caso TC-118 riguardava i rimborsi. Aveva sette passaggi dettagliati e un risultato atteso che recitava: il rimborso è 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 il caso come superato. È stata una corretta applicazione del documento che aveva davanti.
Nessuno ha guardato il registro contabile. Nulla nel caso chiedeva di farlo. Un singolo rimborso e un doppio rimborso appaiono identici nella schermata di conferma, ed è esattamente il motivo per cui il controllo doveva avvenire altrove.
L'audit successivo ha esaminato tutti i trecentoquaranta risultati attesi, ignorando i passaggi.
Duecentoundici potevano essere soddisfatti osservando la sola interfaccia utente. Quarantasette non contenevano alcuna dichiarazione verificabile, usando espressioni come funziona come previsto, si comporta correttamente o si completa senza errori.
La soluzione è stata costituita da 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. Dove il controllo naturale era al di fuori dell'interfaccia, è lì che è stato posizionato. Alcuni casi sono stati unificati e la suite è scesa a duecentonovanta.
Due versioni dopo, i difetti riscontrati durante i test di accettazione utente sono passati da una media di quattro per rilascio a diciannove.
L'aumento di quel numero è il vero risultato. I difetti in produzione nei sei mesi successivi sono scesi da undici a due.
La suite non era troppo piccola. Poneva semplicemente trecentoquaranta domande a cui il sistema poteva rispondere con ottimismo.
Come scrivere i casi di test in sei passaggi
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.
Indica dove viene verificato il risultato. Interfaccia, database, report, sistema a valle. Nominare la posizione è ciò che rende un risultato verificabile da qualcun altro.
Chiediti come questo potrebbe passare pur essendo errato. Se riesci a dare una risposta, il risultato atteso necessita di un'altra condizione.
Poi scrivi i passaggi, un'azione ciascuno. Sono la parte facile e dovrebbero richiedere meno tempo.
Registra le precondizioni, compresi i dati. La maggior parte dei mancati tentativi di riproduzione di un difetto dipende da dati diversi piuttosto che da passaggi diversi.
Definisci le priorità in modo onesto. Nessuno esegue l'intera suite prima di un rilascio. Decidere in anticipo quali casi contano è meglio che farlo alle nove di sera del giorno precedente.
Il passaggio uno rappresenta l'intero metodo. I passaggi due e tre sono quelli che intercettano i difetti prima che raggiungano la produzione.
Casi di test contro scenari di test
I due termini vengono usati in modo intercambiabile, ma la differenza sta nel livello di dettaglio.
Uno scenario di test è cosa testare, descritto a un livello accessibile a chiunque. Verificare che i rimborsi funzionino correttamente per le transazioni contabilizzate. È 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 pratica utile consiste nello scrivere prima gli scenari, concordando la copertura su di essi con chi comprende il business, per poi scrivere i casi sottostanti. Fare il contrario produce una suite che copre semplicemente ciò che è venuto in mente a chi la scriveva.
Uno scenario che produce un solo caso è di solito uno scenario non ponderato a sufficienza. I rimborsi per transazioni contabilizzate 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. In quattro di questi cinque casi si nascondono i difetti.
Strategia di test, piano di test e piano QA
Tre documenti a monte dei casi di test, e le differenze hanno un impatto 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 aggiornata raramente.
Un piano di test è specifico per una versione 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 fornirà una pianificazione e una matrice, mentre le sezioni discorsive devono stare in un documento.
Un piano QA è più ampio di entrambi, poiché l'assicurazione della qualità comprende tutto ciò che viene fatto per prevenire i difetti piuttosto che per trovarli: revisione dei requisiti, definition of done, standard di code review, parità tra gli ambienti. Il modello di piano QA copre questa distinzione, ed è importante in questo contesto perché un documento intitolato piano QA che contiene solo fasi di test si è trasformato silenziosamente in un piano di test.
La prova pratica è la tempistica. Le attività che si svolgono prima che il lavoro sia completato sono di assurance (garanzia). Le attività svolte successivamente sono di controllo, e il testing è controllo.
Il software regolamentato aggiunge un ulteriore livello di convalida. La documentazione di convalida dei sistemi informatici inizia solitamente con un piano di convalida, i requisiti e una valutazione dei rischi. Il testing viene quindi registrato come documentazione IQ OQ PQ, che copre installazione, funzionamento e prestazioni. La convalida CSA, l'approccio basato sul rischio della FDA, mantiene la stessa struttura ma adatta i test e le evidenze al rischio di ciascuna funzione.
Cosa non possono risolvere i modelli gratuiti di documentazione di test
Requisiti che nessuno ha approvato. Un caso di test verifica il comportamento rispetto a un'aspettativa; laddove l'aspettativa non è mai stata stabilita, i tester scrivono i casi in base alle proprie supposizioni.
Una suite troppo grande da eseguire. Ogni organizzazione raggiunge il punto in cui l'intera suite di regressione non rientra nella finestra temporale disponibile. Assegnare le priorità in modo ragionato è preferibile a farlo sotto pressione, e nessun download gratuito di modelli di casi di test in Excel lo farà al posto tuo.
Un risultato atteso vago. Nessun download gratuito di modello di casi di test e nessun layout semplice di modello di casi di test in Excel lo scriverà al posto tuo, ed è l'unico campo che determina l'efficacia del caso.
Dati di test non rappresentativi della produzione. Il difetto di Brayford richiedeva una condizione temporale particolare e un volume di dati realistico. Nessuno dei due elementi era presente nell'ambiente di test, e nessun modello può sopperire a questo.
Tester senza l'autorità di bloccare il rilascio. Criteri di uscita a cui può derogare chiunque desideri effettuare il rilascio non sono criteri.
Mostra il test invece di descriverlo
Due problemi in questo ambito sono in realtà la stessa criticità, ed entrambi riguardano le evidenze.
L'evidenza di test è normalmente una spunta in una colonna di stato. Qualcuno ha eseguito il caso e dichiara che è superato. Se in seguito compare un difetto in quell'area, non c'è modo di stabilire cosa sia stato effettivamente osservato; di conseguenza, non si può verificare se il caso sia stato eseguito correttamente e la questione si trasforma solitamente in una discussione.
Il secondo problema è che un nuovo tester inserito in un team impara a effettuare le verifiche guardando qualcun altro; se nessuno ha tempo, impara dai documenti, da cui ha origine la lettura ottimistica.
L'IA di Trupeer risolve entrambi i problemi. Registrare l'esecuzione di un test produce una guida dettagliata scritta, con screenshot già catturati e posizionati, insieme al video, nel rispetto del tuo brand. Ciò che è stato effettivamente osservato a ogni passaggio viene registrato anziché semplicemente asserito: è questa l'evidenza richiesta da un record di rilascio e il materiale formativo su cui un nuovo tester impara.
Registralo. Personalizzalo con il tuo brand. Traducilo. Usa Trupeer.
Ne conseguono due aspetti. Registrare un tester esperto mentre esegue un caso complesso mostra i controlli svolti all'esterno dell'interfaccia, esattamente l'abitudine che i casi scritti non riescono a trasmettere. Inoltre, quando il testing viene eseguito su più sedi o da un team in outsourcing, la stessa registrazione definisce il medesimo standard di verifica invece di lasciarlo all'interpretazione.
Il materiale confluisce nella tua knowledge base e funge anche da formazione per i nuovi tester. Stabilire se il rilascio possa essere distribuito è una questione a parte, trattata nel modello dei requisiti di rilascio. La coerenza tra i tuoi documenti richiede solo di impostare il brand kit una volta, e la configurazione è spiegata nella guida alla configurazione dei modelli di documento.
Domande frequenti
È disponibile il download gratuito di un modello di casi di test in Excel?
Excel è il formato di lavoro standard per i casi di test ed è perfetto per questo scopo, poiché una suite è una tabella che puoi filtrare per modulo, priorità e stato. Il download gratuito di un modello di casi di test in Excel ti fornirà le colonne standard ed è una valida base di partenza.
Vale la pena apportare due integrazioni: una colonna che registri dove viene verificato il risultato atteso (interfaccia, database, report o sistema a valle) e valori di stato separati per "bloccato" e "non eseguito", poiché raggrupparli nasconde la porzione di suite effettivamente eseguita.
Esiste una versione semplice di modello per casi di test in Excel?
Sì, e la semplicità di solito è la scelta corretta. Un layout semplice per modello di casi di test in Excel 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 finiscono per essere lasciati vuoti nella pratica; una suite con otto colonne compilate è più utile di una con venti colonne di cui dodici vuote.
Esiste una versione in formato Word del modello di casi di test?
Word è più adatto ai documenti accessori che ai casi veri e propri. Un file Word per modelli di casi di test funziona bene per un piano di test, una strategia di test o un report riassuntivo, che sono testi discorsivi.
Per i casi in sé, un documento di testo è inadatto. Non è possibile filtrarlo, non si può ordinare per priorità e aggiornare lo stato di duecento casi in una tabella Word durante un'esecuzione di test è un'operazione talmente lenta che si finisce per non farlo accuratamente.
Vale la pena utilizzare il download gratuito di un modello per casi di test?
Le colonne sono le stesse da decenni, quindi il download gratuito di un modello di casi di test fa risparmiare poco tempo e ogni versione pubblicata è sostanzialmente equivalente.
Valutali in base a una sola domanda: la colonna del risultato atteso include indicazioni o è solo una cella vuota? La cella vuota è il punto in cui fallisce la maggior parte delle suite di test e nessun modello risolve il problema da solo, ma un modello che solleciti a specificare dove viene controllato il risultato migliorerà ciò che vi verrà scritto.
È disponibile il download gratuito di un modello di piano di test in Excel?
Excel si adatta bene alla pianificazione delle tempistiche, alla matrice di copertura e al piano delle risorse all'interno di un piano di test. Un download gratuito di un modello di piano di test in Excel solitamente include questi elementi.
La parte descrittiva appartiene a un documento: ambito, criteri di ingresso e uscita, ambienti, presupposti e rischi. Queste sezioni devono essere lette e concordate, e negoziare all'interno delle celle di un foglio di calcolo non funziona. Mantieni entrambi i formati e crea riferimenti incrociati.
Dove posso trovare un documento di test di esempio in PDF?
Gli atti di appalto del settore pubblico, i progetti universitari e alcuni enti di standardizzazione pubblicano documentazione di test reale; un documento di test di esempio in PDF proveniente da una di queste fonti è più istruttivo di un modello commerciale perché è stato prodotto sotto vincoli reali.
Leggi un PDF di esempio di documento di casi di test prestando attenzione ai risultati attesi piuttosto che alla struttura. La struttura è universale. Il modo in cui un team reale ha descritto l'esito corretto e se i controlli siano stati eseguiti all'esterno dell'interfaccia sono gli aspetti che vale la pena apprendere.
Dove posso trovare un PDF di esempio di un documento di casi di test?
Si applicano le stesse fonti, e i settori regolamentati sono i più ricchi di materiale, poiché le evidenze dei test devono superare gli audit e tendono, di conseguenza, a essere redatte con maggiore precisione.
Quando esamini un documento di casi di test di esempio in PDF, osserva se la colonna del risultato effettivo contiene osservazioni o semplici spunte. Le spunte indicano solo che la suite è stata eseguita. Le osservazioni indicano cosa è stato visto, e solo queste ultime costituiscono vera evidenza.
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 segnalazioni di difetti. Un pacchetto di modelli per la documentazione di software testing copre solitamente il piano e i casi, tralasciando il resto.
I dati di test sono l'elemento più comunemente assente e quello che più spesso impedisce la riproduzione di un difetto. Documentare su quali dati viene eseguita la suite e come vengono aggiornati vale quanto altri cinquanta casi di test.
