Tecniche e tool di classificazione dei difetti nel testing software

Tecniche e tool di classificazione dei difetti nel testing software

Classificazione dei difetti

La classificazione dei difetti, è un processo che segue la fase di rilevamento dei difetti.

Più in generale questo discorso di come i difetti vengono classificati, tracciati e quali attributi vengono usati, può essere indipendente dalle due fasi della Defect Management. Infatti, per classificare tali difetti, si fa uso di tecniche specifiche che poco hanno a che fare con la Detection e la Prevention.

Classificare i difetti assegnando attributi è un passo essenziale per avere un quadro chiaro della qualità dello sviluppo di un sistema, perché consente di individuare le aree di processo che richiedono particolare attenzione.

Le tecniche per la classificazione dei difetti sono varie, in particolare due sono quelle che andremo a vedere ovvero:

  1. Tecnica ODC (Orthogonal Defect Classification)
  2. Modello HP

La tecnica di classificazione ortogonale, è la tecnica più popolare. Essa raggruppa i difetti in classi, piuttosto che considerarli singolarmente.

Il modello HP è anche chiamato defect origin, types and modes; il modello unisce insieme il tipo di difetto, l’origine del difetto e la modalità in cui il difetto è apparso.

Tecniche e tool di classificazione dei difetti nel testing software

Tecniche e tool di Issue Tracking

Nell’ambito del testing software, le tecniche di classificazione dei difetti ODC ed HP, sono però tecniche che molte aziende non utilizzano, sia per i costi ma soprattutto perché sono tecniche troppo complesse. Per trovare un giusto compromesso, vengono utilizzati diffusamente attributi che riescono ad essere efficaci nella classificazione dei difetti senza però dover sostenere costi elevati (ad esempio il training, per comprendere come assegnare correttamente gli attributi ai difetti); tra gli attributi più usati troviamo: Severity e Priority.

La Severity (gravità) ci dice in che misura un difetto può influenzare il software. In altre parole, essa definisce l’impatto che il difetto ha sul sistema.

In generale i livelli di Severity in ordine di gravità sono:

  1. Critical: Se il difetto porta ad un crash del software, blocco del sistema, perdita di dati
  2. Major: Se una funzionalità importante del sistema crolla.
  3. Moderate: Se il sistema produce risultati non corretti, incompleti o inconsistenti.
  4. Minor: Se il difetto causa una piccola perdita di funzionalità che consente comunque di proseguire nel lavoro.
  5. Cosmetic: Se il difetto è legato al miglioramento del sistema i cui cambiamenti sono collegati al look e al campo di applicazione, sono difetti

La Priority (priorità) ci dà invece un’indicazione sull’ordine in cui deve essere risolto il problema; ovvero, se il particolare difetto deve essere risolto nell’immediato oppure può attendere.

In generale i livelli di Priority in ordine di priorità decrescente sono:

  1. High: Il difetto deve essere risolto al più presto, in quanto il difetto interessando l’applicazione in modo grave, al punto che il sistema non può essere utilizzato fino alla riparazione del difetto.
  2. Medium: Il difetto dovrebbe essere risolto nel normale corso delle attività di sviluppo. Si può aspettare fino a quando si crea una nuova build o versione.
  3. Low: Il difetto è irritante e deve essere riparato, ma è possibile attendere in modo da risolvere prima problemi più gravi.

Ci sono diverse scale di valori che possono essere assegnate a questi due attributi, che rispecchiano grossomodo quelle riportate sopra.

Questi ed altri attributi vengono adottati da strumenti che sono a supporto della gestione dei difetti; tali strumenti offrono le funzionalità di issue-tracking o bug-tracking e sono detti appunto tool di issue-tracking.

Esistono numerosi tool di issue-tracking, i più conosciuti sono: ManitsBT, Bugzilla, Jira, Bugzero, HP ALM, TrackStudio, ecc. Tali tool sono usati dagli sviluppatori o dai team di testing per tracciare i bug introdotti nel software e successivamente rilevati in modo da avere una visione chiara di tutte le richieste di correzione e sviluppo, e del loro stato. Le richieste a cui si fa riferimento possono essere sia segnalazioni di bug sia richieste di inserimento di nuove funzionalità.

Pubblicato da Vito Lavecchia

Lavecchia Vito Ingegnere Informatico (Politecnico di Bari) Email: [email protected] Sito Web: https://vitolavecchia.altervista.org

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *