7 Suggerimenti per la scrittura di test case per migliorare il processo di test del software ERP

I test case sono molto importanti per garantire la qualità nel processo di test del software ERP. Sono i primi passi di un ciclo di test e se i casi di test non sono di qualità sufficiente, l’intero progetto sarà “gravato”. Scrivere casi di test “grandi” è un’abilità che ottiene forma semplicemente facendolo. Ma è molto utile avere alcune intuizioni che potrebbero aiutarti. Con questo articolo voglio entrare in contatto con voi e dare suggerimenti per rendere più facile, più divertente e migliore. I suggerimenti che verranno forniti riguarderanno in particolare i casi di test al test di accettazione dei sistemi ERP.

Quali sono i casi di test?

Nel mondo dei test del software, ci sono molte definizioni di casi di test. Per questo motivo è importante nominare la nostra definizione. Nella nostra filosofia i casi di test sono (basati su IEEE610): “Un insieme di input di test, condizioni di esecuzione e risultati attesi sviluppati per un particolare obiettivo.”Sapere come scrivere buoni casi di test è estremamente utile per chiunque voglia testare. Che si tratti di un test funzionale, un test di accettazione dell’utente, testare un’applicazione web o un modulo di un sistema ERP. In tutte le situazioni sopra descritte i casi di test determinano a cosa estendere i risultati danno un verdetto sugli obiettivi prestabiliti.

Perché scrivere casi di test è così difficile?

Come descritto nella definizione, i test case aiutano a guidare i tester attraverso una sequenza di istruzioni di test per determinare se il software soddisfa o meno i requisiti predefiniti. L’esecuzione di casi di test ci aiuta a raccogliere e scoprire informazioni per realizzare quell’obiettivo o un obiettivo specifico. Il primo problema che incontriamo direttamente è la diversità dei possibili obiettivi. E poiché ci sono diversi tipi di test e obiettivi, ci sono diversi tipi di casi di test corrispondenti.

Un secondo problema è legato al contenuto dell’istruzione o dei passaggi di prova effettivi. Il livello di queste istruzioni dipende dal tipo di tester che deve interpretare queste informazioni e dare un parere. Un tester professionale avrà bisogno di istruzioni diverse rispetto a un utente finale coinvolto nel test di accettazione di un sistema ERP

Suggerimento 1: Determina il tuo obiettivo e ciò che vuoi segnalare

Pensa a ciò che vuoi segnalare, in modo da poter determinare il tuo obiettivo derivato. Usandolo come base, hai in vista il contorno del caso di test. Ci sono molti obiettivi diversi, dove dobbiamo sempre chiederci cosa stiamo cercando di imparare o raggiungere quando stiamo per eseguire il test. Ecco alcuni esempi:

• Trovare difetti: questo è lo scopo classico del test. Viene eseguito un test per esporre i difetti.
• Massimizza il numero di bug: La distinzione tra “massimizzare il numero di bug” e “trovare difetti” è che il numero totale di bug è più importante della copertura.
• Blocca i rilasci prematuri del prodotto: L’obiettivo di questo test è trovare prematuramente tanti difetti gravi (showstoppers) in modo che nessuno porti il prodotto in produzione.
• Supporta i manager con le loro decisioni go/no-go: i manager prendono decisioni basate sui rischi. Indicazioni di rischio come copertura dei test, impatto dei problemi riscontrati, ecc. Dare loro uno sfondo migliore su cui basare le loro decisioni.
• Valutare la conformità in base alle specifiche: le presunte specifiche vengono controllate per il loro funzionamento. Tutte le questioni che non sono associate alle specifiche vengono ignorate.
• Valutare la qualità: questo è un obiettivo difficile, perché la qualità è multidimensionale. La natura della qualità dipende dalla natura del prodotto. Per valutare la qualità occorre definire criteri chiari, definiti in modo da renderli effettivamente misurabili.

I risultati del test ottenuti dai casi di test forniscono informazioni dirette sull’obiettivo.

Suggerimento 2: riserva tempo di progettazione sufficiente

Riserva tempo sufficiente per progettare i test case, in modo che corrispondano ai tuoi obiettivi. Casi di test poveri ti perseguiteranno durante l’intero processo di test. Confronto dei risultati dei test, reporting su diversi turni di prova, ecc. Sono essenzialmente determinati dalla qualità dei casi di test.

Se si sta già esaurendo il tempo per la progettazione, ma si desidera comunque iniziare il test, assicurarsi di aver almeno definito i rischi principali. Se 10 tester devono esaminare 5 casi di test con 1 fase di test, questo si tradurrà in 50 risultati del test. Non importa ciò che questi 50 risultati danno maggiori informazioni sulla qualità quindi non fare nulla. Questo probabilmente non sarà esaustivo, ma è un primo passo. Da ciò, è possibile determinare il livello di dettaglio di alcune parti.

Preferiamo che tu pensi con largo anticipo su come dovrebbe essere progettato il test e che i risultati del test diano una risposta reale all’obiettivo. Ma in realtà questo a volte è indisciplinato.

Suggerimento 3: Nome test case

Nominare i test case è importante. In un test ERP medio si hanno facilmente più di 500 casi di test. Capirai che una struttura logica del nome migliora la reperibilità. Nella letteratura viene spesso indicato come un nome completo possibile, in cui il processo da testare, modulo, oggetto ecc. Sono tutti inclusi nel nome. Puoi immaginare che fornire 500 casi di test con un titolo così completo dia un’amministrazione caotica. Con un semplice foglio Excel, si perde facilmente panoramica. Gli strumenti di gestione dei test forniscono una struttura a cui è possibile collegare i casi di test agli oggetti riutilizzabili, senza che questi “inquinino” il nome. Hai anche strumenti di registrazione di prova che organizzano queste relazioni in un modo diverso.

All’interno di TestMonitor ad esempio abbiamo inventato una soluzione diversa. Nello strumento è possibile definire etichette o tag che è quindi possibile collegare ai casi di test. All’interno di TestMonitor i casi di test sono collegati a una o più etichette di processi aziendali, rischi, requisiti o applicazioni. Ciò consente di raggruppare e recuperare i casi di test da diverse prospettive.

Per il nome di un test case all’interno di TestMonitor è sufficiente una chiara descrizione dello scopo del test case. Per semplificare descrivi un’attività con un’aspettativa implicita.

Esempio nome del caso di prova:
“Terminazione di locazione-casa indipendente”
” Crea cliente “”Ricevuta di prenotazione provvisoria”
ecc.

Esempio di test case “Provvisorie di prenotazione ricevuta” che è legata a diverse etichette:

• business del processo di Ricezione della merce’
• requisito requisito Contrattuale’
• rischio “rischio Operativo’
• applicazione ERP’

È importante descrivere il risultato atteso al banco di prova. Il tester quindi sa in quale direzione deve essere la “risposta” e ottiene direttamente un framework di test esplicito.

Suggerimento 4: Test step description

Come descritto nella definizione i test case sono una raccolta di istruzioni di test che ci aiutano a scoprire le informazioni per raggiungere un particolare obiettivo.

Un test case deve avere un inizio e una fine chiari per determinare se il test case è passato o non è riuscito. Inoltre, un caso di test è composto da una o più istruzioni di test o passaggi, in cui sono possibili più percorsi per ottenere il risultato desiderato. Solo testare il percorso del successo è spesso insufficiente. In certe situazioni seguire percorsi di non successo può solo fare la differenza.

È importante definire i passaggi del test nel modo più chiaro possibile in modo che l’utente finale per un test di accettazione dell’utente sappia esattamente cosa deve fare. Naturalmente, ci sono pre-condizioni per venire con, come tester di livello funzionale, conoscenza del nuovo sistema, conoscenza dei possibili processi di business regolati, ecc. Ma in sostanza tutti dovrebbero capire tutti i passaggi del test.

Supponiamo di descrivere ulteriormente il test case “Terminazione locazione-casa indipendente” per un semplice percorso di successo:

1. Selezionare un’unità e avviare la risoluzione del contratto di locazione. Controllare se ci sono prerequisiti tra i quali la risoluzione del contratto di locazione può/non essere accettata e creare un record di questo.
2. Fissare un appuntamento per l’ispezione finale.
3. Riempire i dati nella risoluzione schermo di locazione. Ricontrolla i dati del tenant nella scheda di terminazione del leasing.
4. Registrare la risoluzione del contratto di locazione e inviare una lettera conformazionale. Controlla se la lettera di conferma è arrivata nell’archivio digitale.
5. Controlla nel registro dei contratti dall’unità che il contratto corrente è risolto, che il contratto risolto è collegato alla risoluzione del contratto di locazione e che esiste un nuovo contratto di lavoro vacante.
6. Controlla il nuovo contratto (vacante) in base alla politica di noleggio e ai modelli di elementi.

Cosa noti?

• Ogni fase del test inizia con un verbo
• Seguito da un argomento
• Che termina con dettagli e possibilmente domande di controllo. È possibile scegliere di inserire le domande di controllo in fasi di test separate, ma la pratica mostra che la domanda di controllo è un perfezionamento dell’azione e quindi, logicamente, verrà annotata come fase di test.

Nell’esempio sopra menzionato, si presume che uno specialista di un particolare campo valuterà la fase di test. E poiché lui o lei è uno specialista, non vengono date condizioni di input o delineate aspettative esplicite, perché lo specialista ha ancora i suoi casi di studio nella manica e le sue aspettative sono cristalline.

Se al momento non si dispone di uno specialista, è possibile espandere i passaggi di test con condizioni di input e aspettative esplicite.

Per esempio fase di prova 1 al caso di prova “Cessazione del contratto di locazione-casa indipendente” con maggiori dettagli.

1. Selezionare l’unità “Fleet street 677” e avviare la risoluzione del contratto di locazione. Le condizioni assicurano che questa unità non possa essere terminata prima che gli arretrati siano stati pagati.
2. ecc.

Suggerimento 5: Non più di 10 istruzioni di test in 1 test case

Ci imbattiamo regolarmente in progetti di test in cui > 50 test step sono assegnati a un test case. Questo è troppo per alcuni motivi:

• Tutti i passaggi del test devono essere presi separatamente (o passati esplicitamente) prima che un caso di test ottenga un verdetto.
• La valutazione finale di un test case è determinata dal punteggio “peggiore”. Quindi potrebbe essere che 49 passaggi di test saranno valutati come ” buoni “e uno come” sbagliato “ciò che si traduce in un caso di test” sbagliato”. La misurazione delle fasi di prova deve essere simile. Con ciò intendo dire che praticamente ogni fase del test deve essere uguale all’effetto della valutazione. Se si dispone di 10 passaggi di test da seguire, tra cui 2 piccoli passaggi di test che sono sproporzionati rispetto agli altri 8 passaggi di test, è necessario riformulare. Lo stesso vale il contrario con una fase di test difficile.
• Il tester si perde rapidamente con troppi passaggi di prova all’interno di un test case. Non abbiamo fatto uno studio scientifico su di esso, ma la pratica dimostra che un caso di test non dovrebbe includere più di 10 passaggi di test. Si può pensare a molte eccezioni (controlli di conversione, ecc.), ma in pratica per un test di accettazione dell’utente di un sistema ERP funziona meglio.
• È difficile per gli sviluppatori riprodurre l’errore trovato. Con molti passaggi di test lo sviluppatore perderà molto tempo cercando di rievocare la situazione.
• Le repliche o il nuovo test di casi di test di grandi dimensioni richiedono troppo tempo. Quando un guasto viene rilevato da un tester, il caso di test corrispondente dovrà essere nuovamente testato. Un nuovo test richiede che lo stesso passo venga rivalutato, si desidera evitare ovviamente errori di regressione. Prendendo troppi passaggi di test, molto probabilmente stai testando troppo. In questo modo il processo di test richiede più tempo e può eventualmente sovraccaricare i tester.

Oltre a ciò hai anche strumenti di registrazione dei test che possono presentare i casi di test in varie forme al tester. TestMonitor ad esempio ha due viste diverse. TestMonitor ha un display che mostra tutti i passaggi di test separatamente per pagina e un display in cui vengono presentati i casi di test per pagina compresi tutti i passaggi di test.Il vantaggio del primo display è che ogni tester può ottenere maggiori informazioni per ogni fase di test. Lo svantaggio nel caso in cui il tester sia più esperto, deve fare clic su” avanti ” ogni volta che vuole passare alla fase successiva del test. Nell’altra vista per ogni caso di test i vantaggi e gli svantaggi sono viceversa.

Suggerimento 6: Recensione da parte di un non progettista/fornitore

In pratica, vediamo regolarmente script di test preparati dai programmatori del fornitore di software. Quando si esaminano questi script di test da parte degli eventuali tester, di solito ci sono più domande che risposte. Al contrario, questo funziona allo stesso modo per gli script di test preparati dal proprio dipendente. Dà un vero valore aggiunto rivedendo questi dal fornitore di software. Guardano gli script di test completati con occhi diversi e presentano sempre aggiunte o modifiche significative.

Con un po ‘ di brainstorming con gli specialisti del fornitore di software e l’organizzazione del cliente, ti concentri rapidamente sull’essenza di ciò che deve essere testato. Quindi prenditi il tempo di considerare i casi di test, gli scenari di non successo e vedrai che il tuo modello di test diventa rapidamente più esteso e dettagliato. Oltre a ciò, ottieni maggiori informazioni sulla qualità che ritieni possibile.

Suggerimento 7: TestMonitor

Oltre a utilizzare una piattaforma di test professionale e rendere la qualità davvero perspicace. Richiedi una prova gratuita di TestMonitor oggi e vedere e sperimentare la differenza per te.

Se sei un nuovo arrivato nel mondo dei test, puoi facilmente essere sopraffatto da tutta la terminologia dei test che viene gettata in giro. In questo articolo, cercheremo di spiegare alcuni del gergo che potresti incontrare nella tua vita quotidiana di test, solo per rendere il tutto un po ‘ più comprensibile.

Inizia il test con TestMonitor

Non sei ancora un utente TestMonitor? Buona e facile testing è la priorità chiave per i responsabili di garanzia della qualità, testmanagers, IT-manager, test manager e il release manager. TestMonitor rende il test facile e divertente anche per gli utenti di test.

Quindi cerchiamo di iniziare. Si potrebbe desiderare di controllare il nostro video o scaricare la brochure del prodotto. Ma, naturalmente, con una prova gratuita si può davvero sperimentare la facilità d’uso di TestMonitor te stesso.

Rimanere in contatto? Segui TestMonitor su Twitter e LinkedIn.