Oh my bug!

Questo blog parla di problemi di Vista e quindi, inevitabilmente, di bug. Ora tutti diamo per scontato il concetto di bug, ma leggendo alcuni commenti emerge che forse il concetto non e' cosi' chiaro e darlo per scontato e' un errore.

Provero' a definire cosa sia un bug e le categorie con le quali lo si puo' catalogare.

In generale un bug di un modulo/funzione software e' un mancato funzionamento o
meglio un funzionamento diverso da quanto atteso.

I bug non sono tutti uguali, ne esistono di diversi tipi e una prima categoria e' quella della frequenza di come si manifestano: un bug puo' ad esempio manifestarsi tutte le volte che si utilizza una specifica funzione a prescindere dall'input o da altre condizioni, oppure si puo' manifestare solo per alcuni input e quindi rendere la funzione inutilizzabile solo parzialmente, oppure puo' succedere che si manifesti in modo non consistente per un determinato input e quindi "colpisca" solo saltuariamente.

• nel primo caso si tratta di una funzione che e' del tutto compromessa e di questi bachi nei prodotti finali se ne trovano pochi per non dire nessuno, essendo facilmente identificabili e risolvibili.
• nel secondo caso si tratta di funzioni che funzionano correttamente nella maggior parte dei casi ma che in certe condizioni (ad esempio per certi valori di input) non danno l'output corretto. Questi bachi sono molto piu' frequenti di quelli del primo caso e possono essere piu' o meno facilmente identificabili a seconda che le condizioni che li causano siano facilmente replicabili.
• nel terzo caso si tratta di bachi che tipicamente emergono nell'interazione tra due o piu' componenti ed emergono solo se sono verificate particolari condizioni di sincronizzazione o di mancanza di sincronizzazione tra questi componenti, oppure si manifestano solo in seguito a una sequenza determinata di operazioni precedenti, vedi ad esempio una precisa sequenza di input. Sono quindi bachi che si manifestano in base ad un particolare stato che deve venir replicato esattamente (le cosidette condizioni al contorno). Replicare questi bachi puo' essere estremamente difficoltoso e a volte sono richiesti particolari vincoli hardware affinche' possano essere replicati. Sono bachi molto diffusi perche' difficilmente identificabili in fase di test.
  

Un'altra categoria e' quella della severita' del baco. Non tutti i bachi rendono una funzionalita' inutilizzabile allo stesso livello.

• il baco puo' essere di bassa severita' perche' l'impatto generale che ha e' trascurabile, ad esempio un baco di UI che causa il posizionamento di un pulsante in un punto leggermente diverso da quello atteso potrebbe essere sgradevole a vedersi ma non impedire in alcun modo di utilizzare il pulsante stesso.
• altri bachi possono avere una severita' maggiore nel senso che causano un malfunzionamento ma in modo non totale, ovvero che puo' essere in qualche modo aggirato e quindi non bloccano completamente la funzionalita'. Un baco di questa categoria potrebbe ad esempio generare un errore che costringe l'utente a ripetere l'ultima operazione. In un editor potrebbe essere che selezionando il testo e applicando uno stile lo stile non viene applicato al primo tentativo ma solo al secondo.
• i bachi di massima severita' causano il completo malfunzionamento del componente, non sono aggirabili e che quindi rendono del tutto inutilizzabile la funzionalita' quando si manifestano.
• esistono poi dei bachi che sono persino piu' gravi di quelli appena definiti: i bachi che causano perdita di dati. Questi ultimi sono in assoluto i peggiori e quelli che nessun produttore di software vorrebbe mai vedere. La perdita di dati puo' avvenire sia a seguito di un crash dell'applicazione o del sistema, oppure in modo silente, sovrascrivendo o cancellando erroneamente dati senza che questo comporti o sia causato da un crash.

Abbiamo quindi visto per ora 2 categorie: la frequenza e la gravita'. Non ci sono vincoli sull'appartenenza alle categorie, quindi bachi di una certa severita' possono appartenere a diverse categorie di gravita'.

Una terza categoria e' l'area di appartenenza: in un prodotto software si identificano diverse aree come ad esempio l'interfaccia utente (se presente) o l'installer e via dicendo.

L'area di appartenenza serve insieme alla altre due categorie a definire una quarta categoria: la priorita'.
La priorita' di un baco ci da un'idea di che impatto abbia sull'utente finale e quindi definisce anche una scala di importanza tra i bachi, questo e' molto utile per chi sviluppa software perche' e' uno strumento fondamentale per definire su quali bachi ci si debba mettere prima al lavoro per eliminarli.

Diciamo subito che tutti i bachi che causano data-loss (perdita di dati) sono automaticamente bachi a priorita' massima, a prescindere dalla categoria di frequenza a cui appartengono.

Ci sono bachi di massima severita' che possono avere una priorita' bassa perche' ad esempio la loro fequenza e' quasi nulla, ad esempio potrebbero richiedere all'utente una sequenza di azioni altamente improbabile come cliccare qualche migliaio di volte su uno stesso pulsante nell'arco di poche decine di secondi.

Cosi' come ci sono bachi di bassima severita' (non limitano in alcun modo l'utilizzo da parte dell'utente) ma di priorita' massima, vedasi ad esempio un errore di ortografia: ve lo immaginate se Vista venisse rilasciato con la schermata iniziale che dice "Winzozz Vista" ;-)

Un'altra categoria e' quella della causa del baco. La cosa non e' cosi' scontata, non sempre il baco e' causato da un errore del programmatore. Se lo e' si parla di code defect, ma spesso la causa e' ben piu' complessa e puo' essere di natura architetturale o dovuta a componenti invocate dal codice che poi manifesta il baco vero e proprio.

Questa categoria serve a capire che impatto possa avere la sua sistemazione, spesso infatti per sistemare un baco si finisce per avere un impatto o dover effetturare modifiche su altre componenti e questo porta inevitabilmente al rischio di introdurne di nuovi, e quindi questo tipo di informazione e' importante per sapere quali test vadano effettuati per garantire che la fix non vada a causare nuovi problemi.

Quindi per riassumere, i bachi sono un universo piuttosto complesso, e' importante riuscire a determinare quali siano i passi per poterli riprodurre in quanto i bachi solitamente non sono sempre riproducibili su un generico sistema, ma richiedono tutta una serie di condizioni particolari. Poi e' importante capire quale impatto abbia il baco da un punto di vista delle limitazioni all'utente e infine e' importante sapere che impatto abbia la sua sistemazione.

Ci sarebbe poi da parlare di come si fa per garantire che un software abbia il minor numero di bachi possibile, dato per scontato che software bug-free non esiste per definizione e che non si puo' certo fare affidamento sulla bravura dei programmatori, che per quanto possano essere bravi sono esseri umani e quindi sempre proni all'errore.