Come scrivere casi di test: la guida definitiva con esempi

how write test cases

In questo tutorial pratico approfondito su Come scrivere casi di test, ho coperto i dettagli di cosa sia un caso di test, la sua definizione standard e le tecniche di progettazione di casi di test.

Cos'è un test case?

Un test case ha componenti che descrivono l'input, l'azione e una risposta attesa, al fine di determinare se una funzionalità di un'applicazione funziona correttamente.

Un test case è un insieme di istruzioni su 'COME' per convalidare un particolare obiettivo / target di test, che quando seguito ci dirà se il comportamento previsto del sistema è soddisfatto o meno.

Elenco dei tutorial trattati in questa serie di scrittura di casi di test:

Come scrivere:

Tutorial n. 1: Che cos'è un test case e come scrivere test case (questo tutorial)
Tutorial n. 2: Modello di test case di esempio con esempi (Download) (devi leggere)
Tutorial n. 3: Scrittura di casi di test dal documento SRS
Tutorial n. 4: Come scrivere casi di test per un determinato scenario
Tutorial n. 5: Come prepararsi per la scrittura di casi di test
Tutorial # 6: Come scrivere casi di test negativi

Esempi:

Tutorial # 7: Più di 180 casi di test di esempio per applicazioni Web e desktop
Tutorial n. 8: 100+ scenari di test pronti per l'esecuzione (elenco di controllo)

Tecniche di scrittura:

Tutorial n. 9: Causa ed effetto grafico - Tecnica di scrittura di casi di test dinamici
Tutorial n.10: Tecnica di test di transizione di stato
Tutorial n. 11: Tecnica di test con array ortogonali
Tutorial n. 12: Tecnica di indovinare l'errore
Tutorial n.13: Tecnica di progettazione del test della tabella di convalida sul campo (FVT)

Scenario di test vs scenari di test:

Tutorial n. 14: Scenari di test vs scenari di test
Tutorial # 15: Differenza tra piano di test, strategia di test e scenario di test

Automazione:

Tutorial n. 16: Come selezionare i casi di test corretti per i test di automazione
Tutorial n. 17: Come tradurre casi di test manuali in script di automazione

Strumenti di gestione dei test:

Tutorial n. 18: I migliori strumenti di gestione dei test
Tutorial n. 19: TestLink per Test case Management
Tutorial n. 20: Creazione e gestione di casi di test utilizzando HP Quality Center
Tutorial n. 21: Esecuzione di casi di test utilizzando ALM / QC

Casi specifici del dominio:

Tutorial n. 22: Casi di test per l'applicazione ERP
Tutorial n. 23: Casi di test dell'applicazione JAVA
Tutorial n. 24: Analisi dei valori limite e partizionamento delle equivalenze

Continuiamo con il primo tutorial di questa serie.

Strumenti consigliati:

Prima di continuare con il processo di scrittura dello scenario di test, ti consigliamo di scaricare questo strumento di gestione dello scenario di test. Ciò faciliterà il processo di scrittura dei casi di test menzionato in questo tutorial:

# 1) TestRail

=> Scarica TestRail Test Case Management Tool

# 2) TestMonitor

Gestione dei test online di primo livello. Facile rivoluzionario.

TestMonitor è uno strumento di gestione dei test end-to-end per ogni organizzazione. Un approccio semplice e intuitivo al test. Sia che tu stia implementando software aziendale, necessiti di QA, crei un'app di qualità o semplicemente hai bisogno di una mano nel tuo progetto di test, TestMonitor ti copre.

=> Visita il sito web di TestMonitor

Cosa imparerai:

• Che cos'è un test case e come scrivere test case?
  • Perché scriviamo test?
  • Come scrivere casi di test?
  • Formato di base della dichiarazione del caso di test
• Suggerimenti per la scrittura di test
  • • # 1) Sii semplice ma non troppo semplice; rendilo complesso ma non troppo complesso:
    • # 2) Dopo aver documentato i casi di test, rivedere una volta come Tester:
    • # 3) Limita e facilita i tester:
    • # 4) Sii un collaboratore:
    • # 5) Non dimenticare mai l'utente finale:
• Come ottenere l'eccellenza nella documentazione del caso di test
  • Suggerimenti e trucchi utili
    • # 1) Il tuo documento di prova è in buone condizioni?
    • # 2) Non dimenticare di coprire i casi negativi
    • # 3) Avere passaggi del test atomico
    • # 4) Dai la priorità ai test
    • # 5) La sequenza è importante
    • # 6) Aggiungi il timestamp e il nome del tester ai commenti
    • # 7) Includi i dettagli del browser
    • # 8) Conserva due fogli separati: 'Bug' e 'Riepilogo' nel documento
• Come NON scrivere test
  • 3 Problemi più comuni nei casi di test
    • # 1) Passaggi compositi
    • # 2) Il comportamento dell'applicazione viene considerato come un comportamento previsto
    • # 3) Condizioni multiple in un caso
• Come migliorare l'efficienza del test case
  • Raccolta di documenti per la scrittura di test
  • Esempio reale
  • Documento del caso di test
  • Test di raccolta dati
• Importanza della standardizzazione dei casi di test
  • Motivi per riutilizzare i casi di test
  • Che cos'è un test standard nel test Web?
  • Conclusione
  • Lettura consigliata

Che cos'è un test case e come scrivere test case?

Scrivere casi efficaci è un'abilità. E puoi impararlo dall'esperienza e dalla conoscenza dell'applicazione in prova.

Per le istruzioni di base su come scrivere i test, guarda il seguente video:

Le risorse di cui sopra dovrebbero fornirci le basi del processo di scrittura del test.

Livelli del processo di scrittura del test:

• Livello 1: In questo livello, scriverai il file casi di base dalla specifica disponibile e documentazione per l'utente.
• Livello 2: Questo è il fase pratica in cui i casi di scrittura dipendono dall'effettivo flusso funzionale e di sistema dell'applicazione.
• Livello 3: Questa è la fase in cui raggrupperai alcuni casi e scrivere una procedura di prova . La procedura del test non è altro che un gruppo di piccoli casi, forse un massimo di 10.
• Livello 4: Automazione del progetto. Ciò ridurrà al minimo l'interazione umana con il sistema e quindi il QA può concentrarsi sulle funzionalità attualmente aggiornate da testare piuttosto che rimanere impegnato con i test di regressione.

Perché scriviamo test?

L'obiettivo fondamentale della scrittura di casi è per convalidare la copertura di prova di un'applicazione.

Se lavori in qualsiasi organizzazione CMMi, gli standard di test vengono seguiti più da vicino. La scrittura di casi porta una sorta di standardizzazione e riduce al minimo l'approccio ad hoc nei test.

Come scrivere casi di test?

Campi:

• ID caso di test
• Unità da testare: Cosa verificare?
• Presupposti
• Dati di test: Variabili e loro valori
• Passaggi da eseguire
• Risultato atteso
• Risultato attuale
• Superato / Fallito
• Commenti

Formato di base della dichiarazione del caso di test

Verificare
Utilizzando (nome strumento, nome tag, finestra di dialogo, ecc.)
Con (condizioni)
Per (cosa viene restituito, mostrato, dimostrato)

Verificare: Usato come prima parola della dichiarazione di prova.
Utilizzando: Per identificare ciò che viene testato. È possibile utilizzare 'inserimento' o 'selezione' qui invece di utilizzare a seconda della situazione.

Per qualsiasi applicazione, è necessario coprire tutti i tipi di test come:

• Casi funzionali
• Casi negativi
• Valori limite

Mentre scrivi questi tutti i tuoi file I TC dovrebbero essere semplici e facili da capire .

************************************************

Suggerimenti per la scrittura di test

Una delle attività più frequenti e principali di un Software Tester (persona SQA / SQC) è scrivere scenari e casi di test.

Ci sono alcuni fattori importanti e critici che sono legati a questa importante attività. Diamo prima una visione d'insieme di questi fattori.

Fattori importanti coinvolti nel processo di scrittura:

a) I TC sono soggetti a revisioni e aggiornamenti regolari:

Viviamo in un mondo in continua evoluzione e lo stesso vale anche per il software. La modifica dei requisiti software influisce direttamente sui casi. Ogni volta che i requisiti vengono modificati, i TC devono essere aggiornati.

Tuttavia, non è solo il cambiamento nel requisito che può causare la revisione e l'aggiornamento dei TC. Durante l'esecuzione dei TC, molte idee sorgono nella mente e possono essere identificate molte sotto-condizioni di un singolo TC. Tutto ciò causa un aggiornamento dei TC e talvolta porta anche all'aggiunta di nuovi TC.

Inoltre, durante i test di regressione, diverse correzioni e / o increspature richiedono TC rivisti o nuovi.

b) I TC sono inclini alla distribuzione tra i tester che eseguiranno questi:

Naturalmente, difficilmente esiste una situazione del genere in cui un singolo tester esegue tutti i TC. Normalmente, ci sono diversi tester che testano diversi moduli di una singola applicazione. Quindi i TC sono divisi tra i tester in base alle aree di loro proprietà dell'applicazione sotto test.

Alcuni TC relativi all'integrazione dell'applicazione possono essere eseguiti da più tester mentre gli altri TC possono essere eseguiti solo da un singolo tester.

c) I TC sono inclini al clustering e al batch:

È normale e comune che i TC appartenenti a un singolo scenario di test richiedano solitamente la loro esecuzione in una sequenza specifica o sotto forma di un gruppo. Potrebbero esserci alcuni prerequisiti di un TC che richiedono l'esecuzione di altri TC prima di eseguire se stesso.

Allo stesso modo, secondo la logica di business dell'AUT, un singolo TC può contribuire a diverse condizioni di test e una singola condizione di test può essere costituito da più TC.

d) I TC hanno una tendenza all'interdipendenza:

Questo è anche un comportamento interessante e importante dei TC che denotano che possono essere interdipendenti l'uno dall'altro. Dalle applicazioni medio-grandi con una logica di business complessa, questa tendenza è più visibile.

L'area più chiara di qualsiasi applicazione in cui questo comportamento può essere sicuramente osservato è l'interoperabilità tra diversi moduli della stessa o anche diverse applicazioni. In parole semplici, ovunque i diversi moduli di una singola applicazione o più applicazioni siano interdipendenti, lo stesso comportamento si riflette anche nei TC.

e) I TC sono inclini alla distribuzione tra gli sviluppatori (specialmente in ambienti di sviluppo basati su test):

Un fatto importante sui TC è che questi non devono essere utilizzati solo dai tester. Nel caso normale, quando un bug è in fase di correzione da parte degli sviluppatori, utilizzano indirettamente il TC per risolvere il problema. Allo stesso modo, se viene seguito lo sviluppo basato sui test, i TC vengono utilizzati direttamente dagli sviluppatori per costruire la loro logica e coprire tutti gli scenari nel loro codice che vengono affrontati dai TC.

Suggerimenti per scrivere test efficaci:

Tenendo presenti i 5 fattori di cui sopra, ecco alcuni suggerimenti per scrivere TC efficaci.

Iniziamo!!!

# 1) Sii semplice ma non troppo semplice; rendilo complesso ma non troppo complesso:

Questa affermazione sembra un paradosso. Ma prometto che non è così. Mantieni tutti i passaggi dei TC atomici e precisi. Indica i passaggi con la sequenza corretta e la mappatura corretta ai risultati attesi. Il test case dovrebbe essere autoesplicativo e di facile comprensione. Questo è ciò che intendo per renderlo semplice.

Ora, renderlo un mezzo complesso per renderlo integrato con il piano di test e altri TC. Fare riferimento agli altri TC, agli artefatti rilevanti, alle GUI ecc. Dove e quando richiesto. Ma fallo in modo equilibrato. Non fare in modo che un tester si muova avanti e indietro nella pila di documenti per completare un singolo scenario di test.

D'altra parte, non lasciare nemmeno al tester di documentare questi TC in modo molto compatto. Mentre scrivi i TC, ricorda sempre che tu o qualcun altro dovrete rivederli e aggiornarli.

come eseguire un attacco ddos ​​a un ip

# 2) Dopo aver documentato i casi di test, rivedere una volta come Tester:

Non pensare mai che il lavoro sia finito una volta che hai scritto l'ultimo TC dello scenario di test. Vai all'inizio e rivedi tutti i TC una volta, ma non con la mentalità di uno scrittore di TC o di un pianificatore di test. Esamina tutti i TC con la mente di un tester. Pensa in modo razionale e prova a far funzionare a secco i tuoi TC.

Valuta tutti i passaggi e vedi se li hai menzionati chiaramente in modo comprensibile e i risultati attesi sono in armonia con quei passaggi.

Assicurati che il file dati di test specificato nei TC è fattibile non solo per i tester effettivi, ma anche in base all'ambiente in tempo reale. Assicurati che non vi siano conflitti di dipendenza tra i TC e verifica che tutti i riferimenti ad altri TC / artefatti / GUI siano accurati. Altrimenti, i tester potrebbero trovarsi in grossi guai.

# 3) Limita e facilita i tester:

Non lasciare i dati del test sui tester. Fornisci loro una gamma di input, specialmente dove devono essere eseguiti i calcoli o il comportamento dell'applicazione dipende dagli input. Puoi lasciare che decidano i valori degli elementi di dati di prova, ma non dare mai loro la libertà di scegliere gli elementi di dati di prova stessi.

Perché, intenzionalmente o meno, possono utilizzare gli stessi dati di test ancora e ancora e alcuni dati di test importanti possono essere ignorati durante l'esecuzione dei TC.

Mantieni i tester a proprio agio organizzando i TC in base alle categorie di test e alle aree correlate di un'applicazione. Chiaramente, istruisci e menziona quali TC sono interdipendenti e / o raggruppati. Allo stesso modo, indica esplicitamente quali TC sono indipendenti e isolati in modo che il tester possa gestire la sua attività complessiva di conseguenza.

A questo punto, potresti essere interessato a leggere sull'analisi del valore limite, che è una strategia di progettazione del caso di test utilizzata nei test della scatola nera. Clic Qui per saperne di più.

# 4) Sii un collaboratore:

Non accettare mai la FS o il documento di progettazione così com'è. Il tuo lavoro non è solo quello di passare attraverso il FS e identificare gli scenari di test. Essendo una risorsa per il controllo qualità, non esitare mai a contribuire al business e dare suggerimenti se ritieni che qualcosa possa essere migliorato nell'applicazione.

Suggeriscilo anche agli sviluppatori, specialmente in un ambiente di sviluppo basato su TC. Suggerire gli elenchi a discesa, i controlli del calendario, l'elenco di selezione, i pulsanti di opzione di gruppo, i messaggi più significativi, le precauzioni, i prompt, i miglioramenti relativi all'usabilità, ecc.

Essendo un QA, non solo testare ma fare la differenza!

# 5) Non dimenticare mai l'utente finale:

Lo stakeholder più importante è l ''utente finale' che alla fine utilizzerà l'applicazione. Quindi, non dimenticarlo mai in nessuna fase della scrittura dei TC. In effetti, l'utente finale non dovrebbe essere ignorato in nessuna fase dell'SDLC. Tuttavia, la mia enfasi finora è solo legata al mio argomento.

Quindi, durante l'identificazione degli scenari di test, non trascurare mai quei casi che saranno maggiormente utilizzati dall'utente o quelli che sono business critical anche se utilizzati meno frequentemente. Mantieniti nei panni dell'utente finale, quindi esamina tutti i TC e giudica il valore pratico dell'esecuzione di tutti i tuoi TC documentati.

************************************************

Come ottenere l'eccellenza nella documentazione del caso di test

Essendo un tester di software, sarai sicuramente d'accordo con me sul fatto che elaborare un documento di prova perfetto è davvero un compito impegnativo.

Lasciamo sempre un margine di miglioramento nel nostro Documentazione del caso di test . A volte, non siamo in grado di fornire una copertura del test del 100% attraverso i TC e, a volte, il modello di test non è all'altezza, o ci manca nel fornire una buona leggibilità e chiarezza ai nostri test.

In qualità di tester, ogni volta che ti viene chiesto di scrivere documentazione di test, non iniziare semplicemente in modo ad hoc. È molto importante comprendere bene lo scopo di scrivere casi di test prima di lavorare sul processo di documentazione.

I test dovrebbero essere sempre chiari e lucidi. Devono essere scritti in un modo che offra al tester la facilità di condurre il test completo seguendo i passaggi definiti in ciascuno dei test.

Inoltre, il documento del test case dovrebbe contenere tutti i casi necessari per fornire complete copertura di prova . Per esempio , dovresti provare a coprire il test per tutti i possibili scenari che possono verificarsi all'interno della tua applicazione software.

Tenendo a mente i punti di cui sopra, lasciate che ora vi guidi attraverso un tour su Come raggiungere l'eccellenza nella documentazione dei test.

Suggerimenti e trucchi utili

Qui, ti fornirò alcune linee guida utili che possono darti un vantaggio nella tua documentazione di test rispetto agli altri.

# 1) Il tuo documento di prova è in buone condizioni?

Il modo migliore e più semplice per organizzare il documento di prova è suddividerlo in molte singole sezioni utili. Dividi l'intero test in più scenari di test. Quindi dividi ogni scenario in più test. Infine, dividi ogni caso in più passaggi del test.

Se stai usando Excel, documenta ogni test case su un foglio separato della cartella di lavoro in cui ogni test case descrive un flusso di test completo.

# 2) Non dimenticare di coprire i casi negativi

Come tester di software, devi pensare fuori dagli schemi e delineare tutte le possibilità che la tua applicazione incontra. Noi, in qualità di tester, dobbiamo verificare che se qualsiasi tentativo non autentico di entrare nel software o qualsiasi dato non valido che scorre attraverso l'applicazione debba essere interrotto e segnalato.

Pertanto, un caso negativo è importante quanto uno positivo. Assicurati che per ogni scenario che hai due casi di test: uno positivo e uno negativo . Quello positivo dovrebbe coprire il flusso previsto o normale e quello negativo dovrebbe coprire il flusso non intenzionale o eccezionale.

# 3) Avere passaggi del test atomico

Ogni fase del test dovrebbe essere atomica. Non dovrebbero esserci ulteriori passaggi secondari. Più semplice e chiaro è un passaggio del test, più facile sarebbe procedere con il test.

# 4) Dai la priorità ai test

Spesso abbiamo scadenze rigorose per completare il test di un'applicazione. In questo caso, potremmo perdere il test di alcune delle funzionalità e degli aspetti importanti del software. Per evitare ciò, dovresti contrassegnare una priorità con ogni test mentre lo documenti.

È possibile utilizzare qualsiasi codifica per definire la priorità di un test. In genere è meglio utilizzare uno qualsiasi dei 3 livelli, alto, medio e basso , o 1, 50 e 100. Quindi, quando si dispone di una tempistica rigida, è necessario completare prima tutti i test ad alta priorità e poi passare ai test a priorità media e bassa.

Per esempio - per un sito web di shopping, la verifica del diniego di accesso per un tentativo non valido di accedere all'app può essere un caso ad alta priorità, la verifica della visualizzazione dei prodotti rilevanti sullo schermo dell'utente può essere un caso di priorità media e la verifica del colore del testo visualizzato su i pulsanti dello schermo possono essere un test a bassa priorità.

# 5) La sequenza è importante

Confermare se la sequenza delle fasi del test è assolutamente corretta. Una sequenza errata di passaggi può creare confusione. Preferibilmente, i passaggi dovrebbero anche definire l'intera sequenza dall'accesso all'app fino all'uscita dall'app per uno scenario particolare che viene testato.

# 6) Aggiungi il timestamp e il nome del tester ai commenti

Potrebbe esserci un caso in cui stai testando un'applicazione, qualcuno sta apportando modifiche in parallelo alla stessa app o qualcuno potrebbe aggiornare l'app al termine del test. Ciò porta a una situazione in cui i risultati del test possono variare nel tempo.

Quindi, è sempre meglio aggiungere un timestamp con il nome del tester nei commenti del test in modo che un risultato del test (superato o non superato) possa essere attribuito allo stato di un'applicazione in quel particolare momento. In alternativa, puoi avere un ' Data di esecuzione 'Aggiunta separatamente al test case che identificherà esplicitamente il timestamp del test.

# 7) Includi i dettagli del browser

Come saprai, se si tratta di un'applicazione web, i risultati del test possono differire in base al browser su cui viene eseguito il test. Per la facilità di altri tester, sviluppatori o chiunque stia esaminando il documento di prova, è necessario aggiungere il nome del browser e la versione al case in modo che il difetto possa essere replicato facilmente.

# 8) Conserva due fogli separati: 'Bug' e 'Riepilogo' nel documento

Se stai documentando in un Excel, i primi due fogli della cartella di lavoro dovrebbero essere Riepilogo e Bug. Il foglio Riepilogo dovrebbe riepilogare lo scenario del test e il foglio Bug dovrebbe elencare tutti i problemi riscontrati durante il test. L'importanza dell'aggiunta di questi due fogli è che darà una chiara comprensione del test al lettore / utente del documento.

Quindi, quando il tempo è limitato, questi due fogli possono rivelarsi molto utili per fornire una panoramica del test.

Il documento del test dovrebbe fornire la migliore copertura possibile del test, un'eccellente leggibilità e dovrebbe seguire un formato standard in tutto.

Possiamo raggiungere l'eccellenza nella documentazione dei test tenendo a mente solo alcuni suggerimenti essenziali come l'organizzazione del documento del caso di test, dando la priorità ai TC, avendo tutto nella sequenza corretta, inclusi tutti i dettagli obbligatori per eseguire un TC e fornendo passaggi di test chiari e lucidi, ecc. come discusso sopra.

************************************************

Come NON scrivere test

Passiamo la maggior parte del nostro tempo a scrivere, rivedere, eseguire o mantenere questi. È piuttosto un peccato che i test siano anche i più soggetti a errori. Le differenze di comprensione, pratiche di test dell'organizzazione, mancanza di tempo ecc. Sono alcuni dei motivi per cui spesso vediamo test che lasciano molto a desiderare.

Ci sono molti articoli sul nostro sito su questo argomento, ma qui vedremo Come NON scrivere casi di test: alcuni suggerimenti che saranno fondamentali nella creazione di test distintivi, di qualità ed efficaci.

Continuiamo a leggere e tieni presente che questi suggerimenti sono sia per i tester nuovi che per quelli esperti.

3 Problemi più comuni nei casi di test

1. Passaggi compositi
2. Il comportamento dell'applicazione viene considerato come un comportamento previsto
3. Molteplici condizioni in un unico caso

Questi tre devono essere nella mia lista dei primi 3 problemi comuni nel processo di scrittura del test.

La cosa interessante è che questi si verificano con tester sia nuovi che esperti e continuiamo a seguire gli stessi processi imperfetti senza mai renderci conto che alcune semplici misure possono risolvere facilmente le cose.

Vediamolo e discutiamone in dettaglio:

# 1) Passaggi compositi

Prima di tutto, cos'è un passaggio composito?

Ad esempio, stai dando indicazioni dal punto A al punto B: se dici che 'Vai al posto XYZ e poi all'ABC' questo non ha molto senso, perché qui ci troviamo a pensare: 'Come faccio arrivare a XYZ in primo luogo '- invece iniziando con' gira a sinistra da qui e prosegui per 1 miglio, quindi gira a destra in Rd. no 11 per arrivare a XYZ ”potrebbe ottenere risultati migliori.

Le stesse identiche regole si applicano anche ai test e ai relativi passaggi.

Per esempio Sto scrivendo un test per Amazon.com: effettua un ordine per qualsiasi prodotto.

Di seguito sono riportati i passaggi del test (Nota: sto solo scrivendo i passaggi e non tutte le altre parti del test come il risultato atteso ecc.)

per . Avvia Amazon.com
b . Cerca un prodotto inserendo la parola chiave / nome del prodotto nel campo 'Cerca' nella parte superiore dello schermo.
c . Dai risultati della ricerca visualizzati, scegli il primo.
d . Fare clic su Aggiungi al carrello nella pagina dei dettagli del prodotto.
e . Checkout e paga.
f . Controlla la pagina di conferma dell'ordine.

Adesso, puoi identificare quale di questi è un passaggio composito? Passo destro (e)

Ricorda, i test riguardano sempre il 'Come' eseguire il test, quindi è importante scrivere i passaggi esatti di 'Come effettuare il check-out e pagare' nel test.

Pertanto, il caso di cui sopra è più efficace se scritto come di seguito:

per . Avvia Amazon.com
b . Cerca un prodotto inserendo la parola chiave / nome del prodotto nel campo 'Cerca' nella parte superiore dello schermo.
c . Dai risultati della ricerca visualizzati, scegli il primo.
d . Fare clic su Aggiungi al carrello nella pagina dei dettagli del prodotto.
e . Fare clic su Checkout nella pagina del carrello.
f . Immettere le informazioni CC, le informazioni di spedizione e di fatturazione.
g . Fare clic su Checkout.
h . Controlla la pagina di conferma dell'ordine.

Pertanto, un passaggio composito è quello che può essere suddiviso in più passaggi singoli. La prossima volta che scriviamo dei test, prestiamo tutti attenzione a questa parte e sono sicuro che sarete d'accordo con me sul fatto che lo facciamo più spesso di quanto pensiamo.

# 2) Il comportamento dell'applicazione viene considerato come un comportamento previsto

Sempre più progetti devono affrontare questa situazione in questi giorni.

Mancanza di documentazione, programmazione estrema, cicli di sviluppo rapidi sono alcuni dei motivi che ci costringono a fare affidamento sull'applicazione (una versione precedente o giù di lì) per scrivere i test o su cui basare il test stesso. Come sempre, questa è una comprovata cattiva pratica, non sempre davvero.

È innocuo fintanto che si mantiene una mente aperta e si mantiene l'aspettativa che - 'AUT potrebbe essere difettoso'. È solo quando non pensi che lo sia, le cose funzionano male. Come sempre, lasceremo parlare gli esempi.

Se la seguente è la pagina per la quale stai scrivendo / progettando i passaggi del test:

Caso 1:

Se i passaggi del mio caso di test sono i seguenti:

1. Avvia il sito di acquisto.
2. Fare clic su Spedizione e reso - Risultato previsto: viene visualizzata la pagina di spedizione e restituzione con 'Inserisci qui le tue informazioni' e un pulsante 'Continua'.

Quindi, questo non è corretto.

Caso 2:

1. Avvia il sito di acquisto.
2. Fare clic su Spedizione e reso.
3. Nella casella di testo 'Inserisci il numero dell'ordine' presente in questa schermata, inserisci il numero dell'ordine.
4. Fare clic su Continua - Risultato previsto: vengono visualizzati i dettagli dell'ordine relativi alla spedizione e ai resi.

Il caso 2 è un test case migliore perché anche se l'applicazione di riferimento si comporta in modo errato, lo prendiamo solo come linea guida, facciamo ulteriori ricerche e scriviamo il comportamento previsto secondo la funzionalità corretta prevista.

Linea di fondo: L'applicazione come riferimento è una scorciatoia rapida, ma comporta i suoi rischi. Finché siamo attenti e critici, produce risultati sorprendenti.

# 3) Condizioni multiple in un caso

Ancora una volta, impariamo da Esempio .

Dai un'occhiata ai passaggi del test seguenti: I seguenti sono i passaggi del test all'interno di un test per una funzione di accesso.

un. Immettere dettagli validi e fare clic su Invia.
b. Lascia vuoto il campo Nome utente. Fare clic su Invia.
c. Lascia vuoto il campo della password e fai clic su Invia.
d. Scegli un nome utente / password già registrato e fai clic su Invia.

Quelli che dovevano essere 4 casi diversi vengono combinati in uno solo. Potresti pensare: cosa c'è di sbagliato in questo? Risparmia molta documentazione e quello che posso fare in 4, lo sto facendo in 1- non è fantastico? Beh, non proprio. Motivi?

Continuare a leggere:

• E se una delle condizioni fallisse, dobbiamo contrassegnare l'intero test come 'fallito'. Se contrassegniamo l'intero caso come 'fallito', significa che tutte e 4 le condizioni non funzionano, il che non è realmente vero.
• I test devono avere un flusso. Dal presupposto al passaggio 1 e tutti i passaggi. Se seguo questo caso, al punto (a), se va a buon fine, verrò loggato alla pagina, dove l'opzione “login” non è più disponibile. Quindi, quando arrivo al passaggio (b), dove il tester inserirà il nome utente? Vedi, il flusso è interrotto.

Quindi, scrivere test modulari . Sembra un sacco di lavoro, ma tutto ciò che serve per te è separare le cose e usare i nostri migliori amici Ctrl + C e Ctrl + V per lavorare per noi. :)

************************************************

Come migliorare l'efficienza del test case

I tester del software dovrebbero scrivere i loro test dalla fase precedente del ciclo di vita di sviluppo del software, meglio durante la fase dei requisiti del software.

Il responsabile del test o un responsabile QA dovrebbe raccogliere e preparare il maggior numero possibile di documenti secondo l'elenco seguente.

Raccolta di documenti per la scrittura di test

# 1) Documento sui requisiti dell'utente

È un documento che elenca il processo aziendale, i profili utente, l'ambiente utente, l'interazione con altri sistemi, la sostituzione di sistemi esistenti, requisiti funzionali, requisiti non funzionali, requisiti di licenza e installazione, requisiti di prestazioni, requisiti di sicurezza, usabilità e requisiti concorrenti ecc. .,

# 2) Documento di caso d'uso aziendale

Questo documento descrive in dettaglio il caso d'uso scenario dei requisiti funzionali dal punto di vista aziendale. Questo documento copre gli attori aziendali (o il sistema), gli obiettivi, le pre-condizioni, le post-condizioni, il flusso di base, il flusso alternativo, le opzioni, le eccezioni di ogni flusso aziendale del sistema in base ai requisiti.

# 3) Documento sui requisiti funzionali

Questo documento descrive i requisiti funzionali di ciascuna funzionalità per il sistema in requisiti.

Normalmente, il documento sui requisiti funzionali funge da archivio comune sia per il team di sviluppo e test che per gli stakeholder del progetto, inclusi i clienti per i requisiti impegnati (a volte congelati), che dovrebbero essere trattati come il documento più importante per qualsiasi sviluppo software.

# 4) Piano di progetto software (facoltativo)

Un documento che descrive i dettagli del progetto, obiettivi, priorità, pietre miliari, attività, struttura organizzativa, strategia, monitoraggio dei progressi, analisi dei rischi, ipotesi, dipendenze, vincoli, requisiti di formazione, responsabilità del cliente, programma del progetto ecc.,

# 5) QA / Piano di test

Questo documento descrive in dettaglio il sistema di gestione della qualità, gli standard di documentazione, il meccanismo di controllo delle modifiche, i moduli critici e le funzionalità, il sistema di gestione della configurazione, i piani di test, il monitoraggio dei difetti, i criteri di accettazione, ecc.

Il piano di prova documento viene utilizzato per identificare le funzionalità da testare, le funzionalità da non testare, le allocazioni del team di test e la loro interfaccia, i requisiti delle risorse, la pianificazione del test, la scrittura del test, la copertura del test, i risultati del test, i prerequisiti per l'esecuzione del test, la segnalazione e il monitoraggio dei bug meccanismo, metriche di test ecc.,

Esempio reale

Vediamo come scrivere in modo efficiente casi di test per una schermata di 'Accesso' familiare e semplice come mostrato nella figura seguente. Il approccio di test sarà quasi lo stesso anche per schermi complessi con più informazioni e caratteristiche critiche.

# 1) Il primo approccio per qualsiasi processo di test case sarà quello di ottenere un prototipo di schermo (o wireframe) come sopra, se disponibile. Questo potrebbe non essere disponibile per alcune delle funzionalità e dipende dalla criticità della progettazione di un prototipo nelle prime fasi di sviluppo.

Ma se un file SRS Documento (Specifiche dei requisiti software) è disponibile per il progetto, la maggior parte dei prototipi di schermo sono sviluppati dal team di progetto. Questo tipo di schermo semplifica il lavoro del tester e aumenta l'efficienza dei test.

#Due) Successivamente, il specifiche dei requisiti funzionali . Dipende dal processo organizzativo, sarà disponibile in una suite di più documenti.

Quindi, decidi il documento migliore per scrivere casi, che possa essere un documento dei requisiti dell'utente o una specifica dei requisiti funzionali (o anche un documento SRS se può essere facilmente comprensibile dal team di test) che fornirà un flusso funzionale completo del selezionato caratteristica da testare.

# 3) Una volta che il prototipo dello schermo e le specifiche funzionali sono a posto, il tester dovrebbe iniziare a scrivere i casi con il seguente approccio e criteri.

• Test dell'interfaccia utente :I controlli / campi visibili all'utente. Sono disponibili controlli statici e dinamici per la funzione da testare. Per esempio, nella schermata di accesso in alto, i testi 'Nome utente e password' sono campi statici che non richiedono interazione da parte dell'utente, solo per la visualizzazione del solo testo.

• Casi funzionali :D'altra parte, il pulsante di accesso e i collegamenti ipertestuali (password dimenticata? E registrazione) sono campi dinamici che richiedono l'interazione dell'utente facendo clic sui controlli, che eseguiranno alcune azioni in seguito.

• Casi di database :Una volta che l'utente ha inserito il nome utente e la password, è possibile scrivere i test per controllare il database correlato, se il nome utente e la password sono controllati nel database e nella tabella corretti e inoltre l'utente ha il permesso di accedere all'applicazione sottoposta a test.
  

• Test di processo :Ciò è correlato al processo (non alle azioni associate ai controlli visibili disponibili sullo schermo) associato alla caratteristica e alla funzionalità. Per esempio, Facendo clic sul collegamento Password dimenticata nella schermata di esempio sopra è possibile inviare un'e-mail all'utente. Quindi, forse un'e-mail deve essere testata per il corretto processo e conferma.

4) Infine, mantieni ' Mantra BAOE ', si intende i) Flusso di base ii) Flusso alternativo iii) Opzioni e iv) Eccezioni per la copertura completa del flusso funzionale e delle caratteristiche da testare. Ogni concetto dovrebbe essere applicato a test positivi e negativi.

Per esempio, vediamo il semplice approccio BAOE per la schermata di login di esempio sopra.

• Flusso di base: Immettere il percorso dell'URL del login in qualsiasi browser e immettere le informazioni richieste e accedere all'applicazione.
• Flusso alternativo: Installa l'applicazione su un dispositivo mobile e inserisci le informazioni richieste e accedi all'applicazione.
• Opzioni: Quali sono le opzioni disponibili per accedere alla stessa schermata di accesso? Per esempio, dopo aver effettuato l'accesso all'applicazione, facendo clic su 'Logout' è possibile visualizzare la stessa schermata oppure, se il timeout della sessione o la sessione è scaduta, l'utente può accedere alla schermata di accesso.
• Eccezioni: Quali sono le eccezioni se i miei test sono negativi? Per esempio, se vengono inserite credenziali errate nella schermata di accesso, se l'utente riceverà un messaggio di errore o nessuna azione associata.

Con tutte queste informazioni in mano, iniziamo a scrivere i TC per la schermata di accesso, in un formato con la copertura completa e la tracciabilità e con informazioni dettagliate. La sequenza logica e la numerazione per identificare il ‘ ID caso di test ' sarà molto utile per una rapida identificazione della cronologia di esecuzione dei casi di test.

Leggi anche=> Più di 180 casi di test pronti all'uso per applicazioni web e desktop.

Documento del caso di test

Nota : Le colonne di test non sono limitate al documento di test di esempio riportato di seguito, che può essere mantenuto in un foglio Excel per avere tutte le colonne necessarie per una matrice di tracciabilità completa, ovvero priorità, scopo del test, tipo di test, posizione dello screenshot di errore eccetera.,

Leggi anche=> Esempio di modello di test case con esempi.

Per la facilità di semplicità e leggibilità di questo documento, scriviamo i passaggi per riprodurre, il comportamento previsto ed effettivo dei test per la schermata di accesso in dettaglio di seguito.

Nota : Aggiungi la colonna Actual Behavior alla fine di questo modello.

Test di raccolta dati

Quando il test case viene scritto, il compito più importante per qualsiasi tester è raccogliere i dati del test. Questa attività viene saltata e trascurata da molti tester con il presupposto che i casi di test possano essere eseguiti con alcuni dati campione o dati fittizi e possano essere inseriti quando i dati sono realmente necessari. Questo è un malinteso critico che alimenta dati di esempio o immetti dati dalla memoria mentale al momento dell'esecuzione dei casi di test.

Se i dati non vengono raccolti e aggiornati nel documento di test al momento della scrittura dei test, il tester impiegherebbe più tempo in modo anomalo per raccogliere i dati al momento dell'esecuzione del test. I dati del test dovrebbero essere raccolti sia per i casi positivi che per quelli negativi da tutta la prospettiva del flusso funzionale della caratteristica. Il documento del caso d'uso aziendale è molto utile in questa situazione.

Trova un documento di dati di test di esempio per i test scritti sopra, che a sua volta sarà utile su quanto efficacemente possiamo raccogliere i dati che faciliteranno il nostro lavoro al momento dell'esecuzione del test.

************************************************

Importanza della standardizzazione dei casi di test

In questo mondo frenetico, nessuno può fare cose ripetitive giorno dopo giorno con lo stesso livello di interesse ed energia. Soprattutto, non sono appassionato di fare lo stesso compito ancora e ancora al lavoro. Mi piace gestire le cose e risparmiare tempo. Chiunque in IT dovrebbe esserlo.

Tutte le società IT eseguono diversi tipi di progetti. Questi progetti possono essere basati sul prodotto o sul servizio. Di questi progetti, la maggior parte di essi lavora su siti Web e test del sito web . La buona notizia è che tutti i siti web hanno molte somiglianze. E, se i siti web sono per lo stesso dominio, hanno anche diverse caratteristiche comuni.

La domanda che mi sconcerta sempre è questa: 'Se la maggior parte delle applicazioni sono simili, ad esempio: come i siti di vendita al dettaglio, che sono stati testati migliaia di volte in precedenza,' Perché dobbiamo scrivere casi di prova per un altro sito di vendita al dettaglio da zero? ' Non farà risparmiare un sacco di tempo estraendo gli script di test esistenti che sono stati utilizzati per testare un precedente sito di vendita al dettaglio?

Certo, potrebbero esserci alcune piccole modifiche che potremmo dover fare, ma nel complesso è più facile, efficiente, fa anche risparmiare tempo e denaro e quindi aiuta sempre a mantenere alti i livelli di interesse dei tester. A chi piace scrivere, rivedere e mantenere gli stessi casi di test ripetutamente, giusto? Riutilizzare i test esistenti può risolvere questo problema in larga misura e anche i tuoi clienti lo troveranno intelligente e logico.

Quindi, logicamente, ho iniziato a estrarre gli script esistenti da progetti simili basati sul Web, apportato modifiche e ne ho fatto una rapida revisione. Ho anche usato la codifica a colori per mostrare le modifiche che sono state apportate, in modo che il revisore possa concentrarsi solo sulla parte che è stata modificata.

Motivi per riutilizzare i casi di test

# 1) La maggior parte delle aree funzionali di un sito web sono quasi: accesso, registrazione, aggiungi al carrello, lista dei desideri, checkout, opzioni di spedizione, opzioni di pagamento, contenuto della pagina del prodotto, visti di recente, prodotti pertinenti, codici promozionali ecc.

#Due) La maggior parte dei progetti sono solo miglioramenti o modifiche alle funzionalità esistenti.

# 3) Anche i sistemi di gestione dei contenuti che definiscono gli slot per il caricamento delle immagini con modalità statiche e dinamiche sono comuni a tutti i siti web.

# 4) I siti web di vendita al dettaglio hanno CSR Anche il sistema (Servizio clienti).

# 5) Il sistema di backend e l'applicazione di magazzino che utilizzano JDA vengono utilizzati anche da tutti i siti Web.

# 6) Anche il concetto di cookie, timeout e sicurezza sono comuni.

# 7) I progetti basati sul Web sono spesso soggetti a modifiche dei requisiti.

# 8) Il tipi di test necessari sono comuni come il browser test di compatibilità , test delle prestazioni , test di sicurezza

Vedi, ci sono molte cose comuni e simili.

Detto questo, la riusabilità è la strada da percorrere, a volte le modifiche stesse possono richiedere o meno più o meno tempo. A volte si può sentire che è meglio ricominciare da capo che modificare così tanto.

Questo può essere facilmente gestito creando una serie di casi di test standard per ciascuna delle funzionalità comuni.

Che cos'è un test standard nel test Web?

• Creare casi di test completi: passaggi, dati, variabili, ecc. Ciò garantirà che i dati / variabili non simili possano essere semplicemente sostituiti quando è richiesto un caso di test simile.
• I criteri di ingresso e di uscita dovrebbero essere adeguatamente definiti.
• I passaggi modificabili o l'istruzione nei passaggi devono essere evidenziati in un colore diverso per una rapida ricerca e sostituzione.
• Il linguaggio utilizzato per la creazione dello scenario di test standard dovrebbe essere generico.
• Tutte le funzionalità di ogni sito web dovrebbero essere coperte nei casi di test.
• Il nome degli scenari di test dovrebbe essere il nome della funzionalità o della caratteristica che copre lo scenario di test. Ciò renderà molto più semplice la ricerca del test case dal set.
• Se è presente un campione di base o standard o un file GUI o uno screenshot della funzione, dovrebbe essere allegato con i passaggi pertinenti.

Utilizzando i suggerimenti di cui sopra è possibile creare una serie di script standard e utilizzarli con modifiche minime o necessarie per diversi siti Web.

Anche questi casi di test standard possono essere automatizzati, ma ancora una volta concentrarsi sulla riusabilità è sempre un vantaggio. Inoltre, se automazione è basato su una GUI, riutilizzare gli script su più URL o siti è qualcosa che personalmente non ho mai trovato efficace.

L'utilizzo di un set standard di casi di test manuali per diversi siti Web con piccole modifiche è il modo migliore per eseguire il test di un sito Web. Tutto ciò di cui abbiamo bisogno è creare e mantenere i casi di test con standard e utilizzo adeguati.

Conclusione

Migliorare l'efficienza del test case non è un termine semplicemente definito, ma è un esercizio e può essere raggiunto attraverso un processo maturo e una pratica regolare.

Il team di test non dovrebbe stancarsi di essere coinvolto nel miglioramento di tali attività in quanto è lo strumento migliore per maggiori risultati nel mondo della qualità, questo è dimostrato in molte delle organizzazioni di test in tutto il mondo su progetti mission-critical e applicazioni complesse.

Spero che tu abbia acquisito una conoscenza immensa sul concetto di test case. Guarda la nostra serie di tutorial per saperne di più sui casi di test e sentiti libero di esprimere i tuoi pensieri nella sezione commenti qui sotto!

Tutorial successivo

Lettura consigliata

• Test funzionale vs test non funzionale
• Guida ai test di portabilità con esempi pratici
• Tipi di test del software: diversi tipi di test con dettagli
• Migliori strumenti di test del software 2021 (Strumenti di automazione del test QA)
• Alpha test e beta test (una guida completa)
• Che cos'è il test di sistema: una guida definitiva per principianti
• Documenti di domande campione di certificazione di test ISTQB con risposte
• Come scrivere un rapporto sullo stato settimanale del test del software