Importanti metriche e misure di test del software - Spiegate con esempi e grafici

Nei progetti software è molto importante misurare la qualità, il costo e l'efficacia del progetto e dei processi. Senza queste misurazioni, un progetto non può essere completato con successo.

Nell'articolo di oggi impareremo con esempi e grafici - Metriche e misure di test del software e come utilizzarli nel processo di test del software.

C'è una famosa affermazione: "Non possiamo controllare cose che non possiamo misurare".

In questo caso, controllare i progetti significa capire come un project manager/leader possa identificare le deviazioni dal piano di test il prima possibile, in modo da reagire nel modo più opportuno. La generazione di metriche di test basate sulle esigenze del progetto è molto importante per ottenere la qualità del software da testare.

Che cos'è la metrica di collaudo del software?

Una metrica è una misura quantitativa del grado in cui un sistema, un componente del sistema o un processo possiede un determinato attributo.

Le metriche possono essere definite come "STANDARD DI MISURA ".

Le metriche del software sono utilizzate per misurare la qualità del progetto. Semplicemente, una metrica è un'unità utilizzata per descrivere un attributo. La metrica è una scala di misurazione.

Supponiamo che, in generale, "chilogrammo" sia una metrica per misurare l'attributo "peso". Allo stesso modo, nel software, "Quanti problemi si trovano in mille righe di codice?", h ere Il numero di problemi è una misura; il numero di linee di codice è un'altra misura. La metrica è definita da queste due misure. .

Esempio di metrica di test:

  • Quanti difetti esistono nel modulo?
  • Quanti casi di test vengono eseguiti per persona?
  • Che cos'è la % di copertura dei test?

Che cos'è la misurazione dei test del software?

La misura è il indicazione quantitativa dell'estensione, della quantità, della dimensione, della capacità o della grandezza di qualche attributo di un prodotto o di un processo.

Esempio di misura di prova: Numero totale di difetti.

Per una chiara comprensione della differenza tra misurazioni e metriche, consultare il diagramma seguente.

Perché testare le metriche?

La generazione di metriche di test del software è la responsabilità più importante del responsabile del test del software.

Le metriche di prova vengono utilizzate per,

  1. Prendere le decisioni per la fase successiva delle attività, come ad esempio la stima dei costi e la programmazione dei progetti futuri.
  2. Comprendere il tipo di miglioramento richiesto per il successo del progetto
  3. Prendere una decisione sul processo o sulla tecnologia da modificare, ecc.

Importanza delle metriche di test del software:

Come spiegato in precedenza, le metriche di test sono le più importanti per misurare la qualità del software.

Ora, Come possiamo misurare la qualità del software utilizzando le metriche? ?

Se un progetto non ha metriche, come si può misurare la qualità del lavoro svolto da un analista di test?

Ad esempio, Un analista di test deve,

  1. Progettare i casi di test per 5 requisiti
  2. Esecuzione dei casi di test progettati
  3. Registrare i difetti e i campi; fallire i relativi casi di test.
  4. Dopo aver risolto il difetto, è necessario testare nuovamente il campione difettoso; rieseguire il corrispondente caso di test fallito.

Nello scenario sopra descritto, se non si seguono le metriche, il lavoro completato dall'analista di test sarà soggettivo, cioè il Test Report non avrà le informazioni corrette per conoscere lo stato del suo lavoro/progetto.

Se i metrici sono coinvolti nel progetto, è possibile pubblicare lo stato esatto del suo lavoro con numeri/dati adeguati.

cioè nel Rapporto di prova, possiamo pubblicare:

  1. Quanti casi di test sono stati progettati per ogni requisito?
  2. Quanti casi di test devono ancora essere progettati?
  3. Quanti casi di test vengono eseguiti?
  4. Quanti casi di test sono stati superati/falliti/bloccati?
  5. Quanti casi di test non sono ancora stati eseguiti?
  6. Quanti difetti vengono identificati e qual è la loro gravità?
  7. Quanti casi di test sono falliti a causa di un particolare difetto, ecc.

In base alle esigenze del progetto, possiamo avere più metriche rispetto all'elenco di cui sopra, per conoscere lo stato del progetto in dettaglio.

Sulla base delle metriche di cui sopra, il Test Lead/Manager comprenderà i seguenti punti chiave.

  • % di lavoro completato
  • % di lavori ancora da completare
  • Tempo per completare il lavoro rimanente
  • Se il progetto sta procedendo secondo la tabella di marcia o se è in ritardo, ecc.

In base alle metriche, se il progetto non verrà completato secondo la tabella di marcia, il manager darà l'allarme al cliente e agli altri stakeholder fornendo le ragioni del ritardo per evitare sorprese dell'ultimo minuto.

Ciclo di vita delle metriche

Tipi di metriche di test manuali

Le metriche di test si dividono principalmente in due categorie.

  1. Metriche di base
  2. Metriche calcolate

Metriche di base: Le metriche di base sono quelle derivate dai dati raccolti dall'analista di test durante lo sviluppo e l'esecuzione dei casi di test.

Questi dati saranno tracciati durante tutto il ciclo di vita del test, cioè raccogliendo dati come il numero totale di casi di test sviluppati per un progetto (o) il numero di casi di test da eseguire (o) il numero di casi di test superati/falliti/bloccati ecc.

Metriche calcolate: Le metriche calcolate derivano dai dati raccolti nelle metriche di base. Queste metriche sono generalmente monitorate dal responsabile/manager del test ai fini della rendicontazione del test.

Esempi di metriche di test del software

Facciamo un esempio per calcolare le varie metriche di test utilizzate nei rapporti di test del software:

Di seguito è riportato il formato della tabella per i dati recuperati dall'analista di test che è effettivamente coinvolto nei test:

Definizioni e formule per il calcolo delle metriche:

#1) %ge Casi di test eseguiti Questa metrica viene utilizzata per ottenere lo stato di esecuzione dei casi di test in termini di %ge.

%ge Casi di test eseguiti = ( N. di casi di prova eseguiti / N. totale di casi di prova scritti) * 100.

Quindi, dai dati sopra riportati,

%ge Casi di test eseguiti = (65 / 100) * 100 = 65%

#2) %ge Casi di test non eseguiti Questa metrica viene utilizzata per ottenere lo stato di esecuzione in sospeso dei casi di test in termini di %ge.

%ge Casi di test non eseguiti = ( N. di casi di test non eseguiti / N. totale di casi di test scritti) * 100.

Quindi, dai dati sopra riportati,

%ge Casi di test bloccati = (35 / 100) * 100 = 35%

#3) %ge Casi di test superati Questa metrica viene utilizzata per ottenere la percentuale di superamento dei casi di test eseguiti.

%ge Casi di test superati = ( N. di casi di test superati / N. totale di casi di test eseguiti) * 100.

Quindi, dai dati sopra riportati,

%ge Casi di test superati = (30 / 65) * 100 = 46%

#4) %ge Casi di test falliti Questa metrica viene utilizzata per ottenere la percentuale di fallimento dei casi di test eseguiti.

%ge Casi di test falliti = ( N. di casi di test falliti / N. totale di casi di test eseguiti) * 100.

Quindi, dai dati sopra riportati,

%ge Casi di test superati = (26 / 65) * 100 = 40%

#5) %ge Casi di test bloccati Questa metrica viene utilizzata per ottenere la percentuale di blocco dei casi di test eseguiti. È possibile inviare un rapporto dettagliato specificando il motivo effettivo del blocco dei casi di test.

%ge Casi di test bloccati = ( N. di casi di test bloccati / N. totale di casi di test eseguiti) * 100.

Quindi, dai dati sopra riportati,

%ge Casi di test bloccati = (9 / 65) * 100 = 14%

#6) Densità dei difetti = Numero di difetti identificati / dimensione

( In questo caso la "dimensione" è considerata un requisito, quindi la densità dei difetti viene calcolata come numero di difetti identificati per requisito. Analogamente, la densità dei difetti può essere calcolata come numero di difetti identificati per 100 linee di codice [OPPURE] numero di difetti identificati per modulo, ecc. )

Quindi, dai dati sopra riportati,

Densità dei difetti = (30 / 5) = 6

#7) Efficienza di rimozione dei difetti (DRE) = ( N. di difetti riscontrati durante il test QA / (N. di difetti riscontrati durante il test QA + N. di difetti riscontrati dall'utente finale)) * 100

La DRE viene utilizzata per identificare l'efficacia del test del sistema.

Supponiamo che durante lo sviluppo e il test QA abbiamo identificato 100 difetti.

Dopo il test QA, durante i test Alpha e Beta, l'utente finale/cliente ha individuato 40 difetti che avrebbero potuto essere identificati durante la fase di test QA.

Ora, la DRE sarà calcolata come,

DRE = [100 / (100 + 40)] * 100 = [100 /140] * 100 = 71%

#8) Perdita di difetti : Il Defect Leakage è la metrica utilizzata per identificare l'efficienza del test QA, ovvero quanti difetti vengono mancati/sciolti durante il test QA.

Difetto Perdita = ( Numero di difetti riscontrati in UAT / Numero di difetti riscontrati nei test QA) * 100

Supponiamo che durante lo sviluppo e il test QA abbiamo identificato 100 difetti.

Dopo il test QA, durante i test Alpha e Beta, l'utente finale/cliente ha individuato 40 difetti che avrebbero potuto essere identificati durante la fase di test QA.

Perdita per difetto = (40 /100) * 100 = 40%

#9) Difetti per priorità Questa metrica viene utilizzata per identificare il numero di difetti identificati in base alla gravità/priorità del difetto, che viene utilizzato per decidere la qualità del software.

%ge Difetti critici = N. di Difetti critici identificati / N. totale di Difetti identificati * 100

Dai dati disponibili nella tabella precedente,

%ge Difetti critici = 6/ 30 * 100 = 20%

%ge Difetti elevati = N. di Difetti elevati identificati / N. totale di Difetti identificati * 100

Dai dati disponibili nella tabella precedente,

%ge Difetti elevati = 10/ 30 * 100 = 33,33%

%ge Difetti medi = N. di Difetti medi identificati / N. totale di Difetti identificati * 100

Dai dati disponibili nella tabella precedente,

%ge Difetti medi = 6/ 30 * 100 = 20%

%ge Difetti bassi = N. di Difetti bassi identificati / N. totale di Difetti identificati * 100

Dai dati disponibili nella tabella precedente,

%ge Difetti bassi = 8/ 30 * 100 = 27%

Conclusione

Le metriche fornite in questo articolo sono utilizzate principalmente per generare un rapporto di stato giornaliero/settimanale con dati accurati durante la fase di sviluppo/esecuzione dei casi di test e sono utili anche per monitorare lo stato del progetto e la qualità del software.

L'autore Questo è un post di Anuradha K. Ha più di 7 anni di esperienza nel test del software e attualmente lavora come consulente per una multinazionale. Ha anche una buona conoscenza dei test di automazione mobile.

Quali altre metriche di test utilizzate nei vostri progetti? Come sempre, fateci sapere le vostre opinioni/domande nei commenti qui sotto.

Letture consigliate

    Scorri verso l'alto