how create requirements traceability matrix
Che cos'è la matrice di tracciabilità dei requisiti (RTM) nel test del software: guida passo passo alla creazione della matrice di tracciabilità con esempi e modello di esempio
Il tutorial di oggi riguarda un importante strumento di controllo qualità, che è eccessivamente semplificato (letto trascurato) o eccessivamente enfatizzato, ovvero Matrice di tracciabilità (TM).
Molto spesso, la creazione, la revisione o la condivisione di una matrice di tracciabilità non è uno dei principali risultati del processo di QA, quindi non è maggiormente concentrata, causando così la sotto-enfasi. Al contrario, alcuni clienti si aspettano che una TM riveli sfaccettature sconvolgenti sul loro prodotto (in fase di test) e sono delusi.
'Se usata correttamente, una matrice di tracciabilità può essere il tuo GPS per il tuo viaggio QA'.
Come è prassi generale in STH , vedremo gli aspetti 'Cosa' e 'Come' di una TM in questo articolo.
Cosa imparerai:
- Qual è la matrice di tracciabilità dei requisiti?
- Copertura dei test e tracciabilità dei requisiti
- Come creare una matrice di tracciabilità dei requisiti
Qual è la matrice di tracciabilità dei requisiti?
In Requirement Traceability Matrix o RTM, abbiamo impostato un processo di documentazione dei collegamenti tra i requisiti dell'utente proposti dal cliente al sistema in costruzione. In breve, è un documento di alto livello per mappare e tracciare i requisiti degli utenti con casi di test per garantire che per ogni requisito venga raggiunto un livello di test adeguato.
Il processo per rivedere tutti i casi di test definiti per qualsiasi requisito è denominato Tracciabilità. La tracciabilità ci consente di determinare quali requisiti hanno generato il maggior numero di difetti durante il processo di test.
Il fulcro di qualsiasi impegno di test è e dovrebbe essere la massima copertura del test. Per copertura, significa semplicemente che dobbiamo testare tutto ciò che deve essere testato. Lo scopo di qualsiasi progetto di test dovrebbe essere una copertura del test al 100%.
La matrice di tracciabilità dei requisiti stabilisce un modo per assicurarsi di effettuare controlli sull'aspetto della copertura. Aiuta a creare un'istantanea per identificare le lacune di copertura. In breve, può anche essere indicato come metrica che determina il numero di casi di test eseguiti, superati, non riusciti o bloccati, ecc. Per ogni requisito.
Perché è richiesta la tracciabilità dei requisiti?
La matrice di tracciabilità dei requisiti aiuta a collegare i requisiti, Casi test e difetti accuratamente. L'intera applicazione viene testata avendo la tracciabilità dei requisiti ( Test end to end di un'applicazione è ottenuta).
differenza tra test del fumo e test di sanità mentale
La tracciabilità dei requisiti garantisce una buona 'qualità' dell'applicazione poiché tutte le funzionalità vengono testate. Controllo di qualità può essere ottenuto quando il software viene testato per scenari imprevisti con difetti minimi e tutti i requisiti funzionali e non funzionali sono soddisfatti.
La matrice di tracciabilità dei requisiti aiuta l'applicazione software a essere testata nella durata stabilita, l'ambito del progetto è ben determinato e la sua implementazione viene raggiunta secondo i requisiti e le esigenze del cliente e il costo del progetto è ben controllato.
Difetto Le perdite vengono prevenute poiché l'intera applicazione viene testata per i suoi requisiti.
Tipi di matrice di tracciabilità
Tracciabilità in avanti
In 'Forward Traceability' Requirements to the Test cases. Assicura che il progetto proceda secondo la direzione desiderata e che ogni requisito sia testato a fondo.
Tracciabilità a ritroso
I casi di test vengono mappati con i requisiti in 'Tracciabilità a ritroso'. Il suo scopo principale è garantire che il prodotto attualmente in fase di sviluppo sia sulla strada giusta. Aiuta anche a determinare che non vengono aggiunte funzionalità extra non specificate e quindi l'ambito del progetto è influenzato.
Tracciabilità bidirezionale
(Avanti + Indietro): Una matrice di buona tracciabilità contiene riferimenti dai casi di test ai requisiti e viceversa (requisiti ai casi di test). Questa è indicata come tracciabilità 'bidirezionale'. Assicura che tutti i casi di test possano essere ricondotti ai requisiti e che ogni requisito specificato abbia casi di test accurati e validi per loro.
Esempi di RTM
# 1) Requisiti aziendali
BR1 : Dovrebbe essere disponibile l'opzione di scrittura delle e-mail.
Scenario di test (specifica tecnica) per BR1
TS1 : Viene fornita l'opzione di composizione della posta.
Casi test:
Caso di test 1 (TS1.TC1) : L'opzione di composizione della posta è abilitata e funziona correttamente.
Caso di test 2 (TS1.TC2) : L'opzione di composizione della posta è disabilitata.
# 2) Difetti
Dopo aver eseguito i casi di test, se vengono rilevati difetti, anche questi possono essere elencati e mappati con i requisiti aziendali, gli scenari di test e i casi di test.
Per esempio, Se TS1.TC1 non riesce, ad esempio l'opzione Componi posta sebbene abilitata non funziona correttamente, è possibile registrare un difetto. Supponiamo che l'ID del difetto generato automaticamente o assegnato manualmente sia D01, quindi questo può essere mappato con i numeri BR1, TS1 e TS1.TC1.
Quindi tutti i requisiti possono essere rappresentati in un formato tabella.
| Requisito di business # | Scenario di prova n. | Caso di test n. | Difetti # |
|---|---|---|---|
| BR1 | TS1 | TS1.TC1 TS1.TC2 | D01 |
| BR2 | TS2 | TS2.TC1 TS2, TC2 TS2.TC3 | D02 D03 |
| BR3 | TS3 | TS1.TC1 TS2.TC1 TS3.TC1 TS3.TC2 | NULLA |
Copertura dei test e tracciabilità dei requisiti
Che cos'è la copertura del test?
Copertura del test indica quali requisiti dei clienti devono essere verificati quando inizia la fase di test. Copertura del test è un termine che determina se i casi di test sono scritti ed eseguiti per garantire di testare completamente l'applicazione software, in modo tale che vengano segnalati difetti minimi o NIL.
Come ottenere la copertura del test?
La massima copertura del test può essere raggiunta stabilendo una buona 'tracciabilità dei requisiti'.
- Mappatura di tutti i difetti interni ai casi di test progettati
- Mappatura di tutti i Customer Reported Defects (CRD) su singoli casi di test per la futura suite di test di regressione
Tipi di specifiche dei requisiti
# 1) Requisiti aziendali
I requisiti effettivi dei clienti sono elencati in un documento noto come Documento sui requisiti aziendali (BRS) . Questo BRS è un elenco di requisiti di alto livello minuziosamente derivato, dopo una breve interazione con il cliente.
Di solito è preparato da 'Analisti aziendali' o dal progetto 'Architetto' (a seconda dell'organizzazione o della struttura del progetto). Il documento 'Specifiche dei requisiti software' (SRS) è derivato da BRS.
# 2) Documento di specifica dei requisiti software (SRS)
È un documento dettagliato che contiene tutti i dettagli meticolosi di tutti i requisiti funzionali e non funzionali. Questo SRS è la base per la progettazione e lo sviluppo di applicazioni software.
# 3) Documenti dei requisiti di progetto (PRD)
Il PRD è un documento di riferimento per tutti i membri del team in un progetto per dire loro esattamente cosa dovrebbe fare un prodotto. Può essere suddiviso in sezioni come Scopo del prodotto, Caratteristiche del prodotto, Criteri di rilascio e Budget e pianificazione del progetto.
# 4) Usa il documento del caso
È il documento che aiuta nella progettazione e implementazione del software secondo le esigenze aziendali. Mappa le interazioni tra un attore e un evento con un ruolo che deve essere svolto per raggiungere un obiettivo. È una descrizione dettagliata passo passo di come un'attività deve essere eseguita.
Per esempio,
Attore: Cliente
Ruolo: Scarica il gioco
Il download del gioco è riuscito.
I casi d'uso possono anche essere una parte inclusa nel documento SRS secondo il processo di lavoro dell'organizzazione.
# 5) Documento di verifica dei difetti
È documentato contenente tutti i dettagli relativi ai difetti. Il team può mantenere un documento di 'Verifica dei difetti' per la correzione e il nuovo test dei difetti. I tester possono fare riferimento al documento 'Verifica dei difetti', quando vogliono verificare se i difetti sono corretti o meno, ritestare i difetti su diversi sistemi operativi, dispositivi, diverse configurazioni di sistema, ecc.
Il documento 'Verifica del difetto' è utile e importante quando è presente una fase di correzione e verifica dei difetti dedicata.
# 6) Storie degli utenti
La user story viene utilizzata principalmente nello sviluppo 'Agile' per descrivere una funzionalità software dal punto di vista dell'utente finale. Le storie degli utenti definiscono i tipi di utenti e in che modo e perché desiderano una determinata funzionalità. Il requisito è semplificato creando storie utente.
Attualmente, tutte le industrie del software si stanno muovendo verso l'uso di User Story e Agile Development e dei corrispondenti strumenti software per la registrazione dei requisiti.
Sfide per la raccolta dei requisiti
# 1) I Requisiti raccolti devono essere dettagliati, inequivocabili, accurati e ben specificati. Ma c'è NON misura appropriata per calcolare questi dettagli, chiarezza, accuratezza e specifiche ben definite necessarie per la raccolta dei requisiti.
#Due) L'interpretazione dell ''analista aziendale' o 'proprietario del prodotto' che fornisce le informazioni sui requisiti è fondamentale. Allo stesso modo, il team che riceve le informazioni deve sollevare opportuni chiarimenti al fine di comprendere le aspettative degli stakeholder.
La comprensione deve essere sincronizzata sia con le esigenze aziendali sia con gli sforzi effettivi richiesti per l'implementazione dell'applicazione.
# 3) Le informazioni dovrebbero anche essere ricavate dal punto di vista dell'utente finale.
# 4) Le parti interessate dichiarano requisiti contrastanti o contraddittori in momenti diversi.
# 5) Il punto di vista dell'utente finale non viene preso in considerazione per molteplici ragioni e ulteriori parti interessate pensano di comprendere 'completamente' ciò che è richiesto per un prodotto, cosa che generalmente non è il caso.
# 6) Mancanza di risorse di competenze per l'applicazione sviluppata.
# 7) Frequenti cambi di 'ambito' dell'applicazione o cambio di priorità per i moduli.
# 8) Requisiti mancati, impliciti o non documentati.
# 9) Requisiti incoerenti o vaghi determinati dai clienti.
# 10) La conclusione di tutti i fattori sopra indicati è che il 'successo' o il 'fallimento' di un progetto dipende notevolmente da un requisito.
In che modo la tracciabilità dei requisiti può aiutare
# 1) Dove viene implementato un requisito?
Per esempio,
Requisiti: Implementa la funzionalità 'Componi posta' in un'applicazione di posta.
Implementazione: Dove nella pagina principale dovrebbe essere posizionato e accessibile il pulsante 'Scrivi messaggio'.
# 2) È necessario un requisito?
Per esempio,
Requisiti: Implementa la funzionalità 'Componi posta' in un'applicazione di posta solo per determinati utenti.
Implementazione: In base ai diritti di accesso dell'utente, se la casella di posta in arrivo è 'di sola lettura', in questo caso il pulsante 'Scrivi messaggio' non sarà richiesto.
# 3) Come interpreto un requisito?
Per esempio,
Requisiti: Funzionalità 'Componi posta' in un'applicazione di posta con caratteri e allegati.
Implementazione: Quando si fa clic su 'Scrivi messaggio', quali funzionalità dovrebbero essere fornite?
- Corpo del testo per scrivere e-mail e modificare in diversi tipi di carattere e anche grassetto, corsivo, sottolineato
- Tipi di allegati (immagini, documenti, altri messaggi di posta elettronica, ecc.)
- Dimensioni degli allegati (dimensione massima consentita)
In questo modo i requisiti vengono suddivisi in sotto-requisiti.
# 4) Quali decisioni di progettazione influenzano l'implementazione di un requisito?
Per esempio,
Requisiti: Tutti gli elementi 'Posta in arrivo', 'Posta inviata', 'Bozze', 'Spam', 'Cestino' e così via devono essere chiaramente visibili.
Implementazione: Gli elementi da visualizzare dovrebbero essere visualizzati nel formato 'Albero' o 'Tab'.
# 5) Tutti i requisiti sono assegnati?
Per esempio,
Requisiti: Viene fornita l'opzione di posta 'Cestino'.
Implementazione: Se è stata fornita l'opzione 'Cestino' della posta, è necessario implementare inizialmente l'opzione 'Elimina' (requisito) e dovrebbe funzionare correttamente. Se l'opzione 'Elimina' posta funziona correttamente, solo le email eliminate verranno raccolte nel 'Cestino' e l'implementazione dell'opzione di posta 'Cestino' (requisito) avrà senso (sarà utile).
Vantaggi di RTM e copertura dei test
# 1) La build sviluppata e testata ha le funzionalità richieste che soddisfano le esigenze e le aspettative di 'Clienti' / 'Utenti'. Il cliente deve ottenere ciò che vuole. Sorprendere il cliente con un'applicazione che non fa quello che ci si aspetta non è un'esperienza soddisfacente per nessuno.
#Due) Il prodotto finale (applicazione software) sviluppato e consegnato al cliente deve comprendere solo le funzionalità necessarie e previste. Le funzionalità extra fornite nell'applicazione software possono sembrare allettanti inizialmente fino a quando non ci sarà un sovraccarico di tempo, denaro e sforzi per svilupparla.
La funzionalità extra può anche diventare una fonte di difetti, che possono causare problemi a un cliente dopo l'installazione.
# 3) Il compito iniziale dello sviluppatore viene definito chiaramente mentre lavorano prima sull'implementazione dei requisiti, che sono di alta priorità, secondo il requisito del cliente. Se i requisiti di alta priorità del cliente sono chiaramente specificati, allora quei componenti di codice possono essere sviluppati e implementati con priorità assoluta.
In questo modo si garantisce che le possibilità che il prodotto finale venga spedito al cliente sia conforme ai requisiti più elevati e nei tempi previsti.
# 4) I tester verificano prima le funzionalità più importanti implementate dagli sviluppatori. Poiché la verifica (Test) del componente software prioritario viene eseguita per prima, aiuta a determinare quando e se le prime versioni del sistema sono pronte per essere rilasciate.
# 5) Vengono scritti ed eseguiti piani di test accurati, casi di test che verificano che tutti i requisiti dell'applicazione siano implementati correttamente. La mappatura dei casi di test con i requisiti aiuta a garantire che non vengano persi difetti importanti. Aiuta inoltre a implementare un prodotto di qualità secondo le aspettative del cliente.
# 6) Nel caso in cui sia presente una 'richiesta di modifica' dal client, tutti i componenti dell'applicazione interessati dalla richiesta di modifica vengono modificati e nulla viene trascurato. Ciò migliora ulteriormente, nella valutazione, l'impatto che una richiesta di modifica ha sull'applicazione software.
# 7) Una richiesta di modifica apparentemente semplice potrebbe implicare modifiche che devono essere apportate a diverse parti dell'applicazione. È meglio trarre una conclusione su quanto impegno sarà richiesto prima di accettare di apportare la modifica.
Sfide nella copertura dei test
# 1) Buon canale di comunicazione
Se sono presenti modifiche suggerite da Stakeholder , lo stesso deve essere comunicato ai team di sviluppo e test nelle prime fasi di sviluppo. Senza questo puntuale Non è possibile garantire lo sviluppo, il test dell'applicazione e l'acquisizione / correzione dei difetti.
# 2) Dare la priorità agli scenari di test è importante
Identificare quali sono scenari di test ad alta priorità, complessi e importanti è un compito difficile. Cercando di testare tutti i file Scenari di prova è quasi un compito irraggiungibile. L'obiettivo di testare gli scenari deve essere molto chiaro dal punto di vista aziendale e dell'utente finale.
# 3) Implementazione del processo
Il processo di test deve essere chiaramente definito considerando fattori come l'infrastruttura tecnica e le implementazioni, le capacità del team, le esperienze passate, le strutture organizzative e i processi seguiti, le stime del progetto relative a costi, tempi e risorse e l'ubicazione del team secondo i fusi orari.
Un'implementazione uniforme del processo che tenga conto dei fattori menzionati garantisce che ogni individuo interessato al progetto sia sulla stessa pagina. Questo aiuta a un flusso regolare di tutti i processi relativi allo sviluppo dell'applicazione.
# 4) Disponibilità di risorse
Le risorse sono di due tipi, tester specifici del dominio esperto e strumenti di test utilizzati dai tester. Se i tester hanno una conoscenza adeguata del dominio, possono scrivere e implementare scenari di test e script efficaci. Per implementare questi scenari e script, i tester dovrebbero essere ben equipaggiati con appropriati 'strumenti di test'.
cos'è il comando grep in unix
Una buona implementazione e la consegna puntuale dell'applicazione al cliente possono essere garantite dall'unico tester esperto e da strumenti di test appropriati.
# 5) Implementazione efficace della strategia di test
' La strategia di test 'di per sé è un argomento di discussione ampio e separato. Ma qui per 'Copertura del test', un'implementazione efficace della strategia di test garantisce che ' Qualità' dell'applicazione è bene e questo è mantenuto nel periodo di tempo ovunque.
Una 'Strategia di test' efficace gioca un ruolo importante nella pianificazione in anticipo per tutti i tipi di sfide critiche, il che aiuta ulteriormente a sviluppare un'applicazione migliore.
Come creare una matrice di tracciabilità dei requisiti
Per stare con noi dobbiamo sapere esattamente cosa deve essere tracciato o tracciato.
I tester iniziano a scrivere i loro scenari / obiettivi di test e, infine, i casi di test sulla base di alcuni documenti di input - Documento dei requisiti aziendali, Documento sulle specifiche funzionali e documento di progettazione tecnica (opzionale).
Supponiamo che il seguente sia il nostro documento sui requisiti aziendali (BRD): ( Scarica questo BRD di esempio in formato Excel )
(Fare clic su qualsiasi immagine per ingrandirla)
Di seguito è riportato il nostro Documento sulle specifiche funzionali (FSD) basato sull'interpretazione del Documento sui requisiti aziendali (BRD) e sul suo adattamento alle applicazioni informatiche. Idealmente, tutti gli aspetti della FSD devono essere affrontati nella BRD. Ma per semplicità, ho utilizzato solo i punti 1 e 2.
Esempio di FSD da Above BRD: ( Scarica questo FSD di esempio in formato Excel )
Nota : BRD e FSD non sono documentati dai team di controllo qualità. Siamo semplici consumatori dei documenti insieme agli altri team di progetto.
Sulla base dei due documenti di input di cui sopra, in qualità di team QA, abbiamo elaborato l'elenco seguente di scenari di alto livello da testare.
Esempi di scenari di test dai precedenti BRD e FSD: ( Scarica questo file di scenari di test di esempio )
Una volta arrivati qui, ora sarebbe un buon momento per iniziare a creare la matrice di tracciabilità dei requisiti.
Personalmente preferisco un foglio Excel molto semplice con colonne per ogni documento che desideriamo monitorare. Poiché i requisiti aziendali e funzionali non sono numerati in modo univoco, utilizzeremo i numeri di sezione nel documento per tenere traccia.
(Puoi scegliere di tenere traccia in base ai numeri di riga o ai numeri in punti puntati ecc. A seconda di ciò che ha più senso per il tuo caso in particolare.)
Ecco come apparirebbe una semplice matrice di tracciabilità per il nostro esempio:
Il documento di cui sopra stabilisce una traccia tra la BRD e la FSD e infine gli scenari di prova. Creando un documento come questo, possiamo assicurarci che ogni aspetto dei requisiti iniziali sia stato preso in considerazione dal team di test per la creazione delle suite di test.
Puoi lasciarlo in questo modo. Tuttavia, per renderlo più leggibile, preferisco includere i nomi delle sezioni. Ciò migliorerà la comprensione quando questo documento viene condiviso con il cliente o qualsiasi altro team.
Il risultato è il seguente:
Ancora una volta, la scelta di utilizzare il formato precedente o quello successivo è tua.
Questa è la versione preliminare della tua TM ma generalmente non serve al suo scopo quando ti fermi qui. Se lo estrapoli fino ai difetti, puoi trarne i massimi benefici.
Vediamo come.
Per ogni scenario di test che hai creato, avrai almeno 1 o più casi di test. Quindi, includi un'altra colonna quando arrivi lì e scrivi gli ID del test case come mostrato di seguito:
In questa fase, la matrice di tracciabilità può essere utilizzata per trovare le lacune. Per esempio, nella matrice di tracciabilità sopra, si vede che non ci sono casi di test scritti per la sezione 1.2 di FSD.
Come regola generale, eventuali spazi vuoti nella matrice di tracciabilità sono potenziali aree di indagine. Quindi uno spazio vuoto come questo può significare una delle due cose:
- Il team di test ha in qualche modo mancato di considerare la funzionalità 'Utente esistente'.
- La funzionalità 'Utente esistente' è stata rimandata a un secondo momento o rimossa dai requisiti di funzionalità dell'applicazione. In questo caso, il TM mostra un'incongruenza nella FSD o BRD, il che significa che dovrebbe essere effettuato un aggiornamento sui documenti FSD e / o BRD.
Se è lo scenario 1, indicherà i luoghi in cui il team di test deve lavorare ancora per garantire una copertura del 100%.
Negli scenari 2, TM non solo mostra lacune, ma punta a una documentazione errata che necessita di correzione immediata.
Espandiamo ora la TM per includere lo stato di esecuzione del test case e i difetti.
La versione seguente della matrice di tracciabilità viene generalmente preparata durante o dopo l'esecuzione del test:
Scarica il modello della matrice di tracciabilità dei requisiti:
=> Modello di matrice di tracciabilità in formato Excel
Punti importanti da notare
Di seguito sono riportati i punti importanti da notare su questa versione della matrice di tracciabilità:
# 1) Viene visualizzato anche lo stato di esecuzione. Durante l'esecuzione, fornisce un'istantanea consolidata di come sta procedendo il lavoro.
# 2) Difetti: Quando questa colonna viene utilizzata per stabilire la tracciabilità a ritroso, possiamo dire che la funzionalità 'Nuovo utente' è la più difettosa. Invece di segnalare che così e così i casi di test sono falliti, TM fornisce trasparenza al requisito aziendale che presenta la maggior parte dei difetti, mostrando così la qualità in termini di ciò che il cliente desidera.
# 3) Come ulteriore passaggio, è possibile codificare a colori l'ID del difetto per rappresentarne gli stati. Per esempio, L'ID difetto in rosso può significare che è ancora aperto, in verde può significare che è chiuso. Al termine, il TM funziona come un rapporto di controllo dello stato di salute che mostra lo stato dei difetti corrispondenti a una determinata funzionalità BRD o FSD che è aperta o chiusa.
# 4) Se è presente un documento di progettazione tecnica o casi d'uso o qualsiasi altro artefatto che desideri monitorare, puoi sempre espandere il documento creato sopra per adattarlo alle tue esigenze aggiungendo colonne aggiuntive.
Per riassumere, RTM aiuta a:
- Garantire una copertura del test del 100%
- Visualizzazione delle incongruenze tra requisiti / documenti
- Visualizzazione dello stato generale di difetto / esecuzione con particolare attenzione ai requisiti aziendali.
- Se un determinato requisito aziendale e / o funzionale dovesse cambiare, un TM aiuta a stimare o analizzare l'impatto sul lavoro del team di QA in termini di revisione / rielaborazione sui casi di test.
Inoltre,
- Una matrice di tracciabilità non è uno strumento specifico per il test manuale, ma può essere utilizzata anche per progetti di automazione. Per un progetto di automazione, l'ID del test case può indicare il nome dello script del test di automazione.
- Inoltre, non è uno strumento che può essere utilizzato solo dai QA. Il team di sviluppo può utilizzare lo stesso per mappare i requisiti BRD / FSD a blocchi / unità / condizioni del codice creato per assicurarsi che tutti i requisiti siano sviluppati.
- Strumenti di gestione dei test come HP ALM venire con la funzione di tracciabilità incorporata.
Un punto importante da notare è questoil modo in cui mantieni e aggiorni la tua matrice di tracciabilità determina l'efficacia del suo utilizzo. Se non viene aggiornato spesso o aggiornato in modo errato, lo strumento è un peso anziché un aiuto e crea l'impressione che lo strumento di per sé non sia degno di essere utilizzato.
domande e risposte del server sql per esperti
Conclusione
La matrice di tracciabilità dei requisiti è il mezzo per farlo mappa e traccia tutti i requisiti del cliente con i casi di test e i difetti scoperti. È un documento unico che serve allo scopo principale che nessun caso di test venga perso e quindi ogni funzionalità dell'applicazione viene coperta e testata.
Una buona 'copertura del test', pianificata in anticipo, previene attività ripetitive nelle fasi di test e perdite di difetti. Un numero elevato di difetti indica che il test è stato eseguito correttamente e quindi la 'qualità' dell'applicazione sta aumentando. Allo stesso modo, un conteggio di difetti molto basso indica che il test non è stato eseguito fino al segno e questo ostacola la 'qualità' dell'applicazione in modo negativo.
Se la copertura del test viene eseguita in modo completo, è possibile giustificare un conteggio di difetti basso e questo conteggio di difetti può essere considerato come statistica di supporto e non come principale. La qualità di un'applicazione viene definita 'buona' o 'soddisfacente' quando la copertura del test è massimizzata e il conteggio dei difetti è ridotto al minimo.
Circa l'autore: Urmila P., membro del team STH, è un esperto QA Professional con alta qualità capacità di test e monitoraggio dei problemi.
Hai creato una matrice di tracciabilità dei requisiti nei tuoi progetti? Quanto è simile o diverso da quello che abbiamo creato in questo articolo? Per favore condividi le tue esperienze, commenti, pensieri e feedback su questo articolo attraverso i tuoi commenti.
Lettura consigliata
- Esempio di modello di piano di test del software con formato e contenuto
- Come scrivere un rapporto di riepilogo del test efficace (Download del rapporto di esempio)
- Modello di test case di esempio con esempi di test case (Download)
- Modello di esempio per rapporto del test di accettazione con esempi
- Come scrivere un documento di strategia di test (con modello di strategia di test di esempio)
- Come testare la specifica dei requisiti software (SRS)?
- I 20 migliori strumenti di gestione dei requisiti (l'elenco completo)
- Elenchi di controllo per il test del software QA (elenchi di controllo di esempio inclusi)