ORACOLO DEL TEST
perché il gruppo di test non ha trovato questo bug?
Immagina la situazione, è appena stata rilasciato un nuovo tool in produzione e dopo pochi minuti viene rilevato un bug significativo, mentre sei in ufficio arriva l'invito ad riunione dove si affronta il tema "perché il gruppo di test non ha rilevato questo bug?"
E durante la riunione si cerca il "colpevole" spesso con toni anche accesi in cui si pone il focus sul danno che l'azienda sta subendo in quel preciso momento per quel bug e si comincia con tutta una serie di domande tra cui:
- Chi ha testato quella parte?
- È un Junior o un senior?
- Perché non ha visto quel bug? In produzione è talmente evidente che è stato scoperto immediatamente
Ecco dal mio punto di vista quando capita questo ci si focalizza sul dito e non si nota la luna che vi è dietro.
E devono nascere 2 filoni paralleli di discussione:
Filone 1 - analisi di processo
Si perché spesso il bug è una manifestazione di qualcosa che che può essere migliorato nella gestione dell'intero processo di sviluppo e per essere efficace è bene che in questa analisi sia coinvolto tutto il team di progetto dal marketing allo sviluppatore.
Partiamo dal primo concetto fondamentale, non esiste software privo di bug! Possiamo solo fare del nostro meglio per trovare i più gravi il prima possibile, e per farlo adottiamo tutte le tecniche note tra cui ad esempio:
- La classificazione dell'importanza delle funzionalità sia a livello di business che a livello tecnico, magari a video è solo un tasto colorato da premere, mentre dietro c'è tutta una serie di chiamate a servizi che sono particolarmente complicati, sulla base di questa classificazione si deciderà quanti e quali test andare ad eseguire.
- Creazione di base di dati che riescano a coprire tutte le varie casistiche
Oltre a questo la domanda da farsi è "abbiamo mai fatto una retrospettiva? " ci siamo mai fermati a parlarci per evidenziare le cose che non vanno? Trovo davvero molto importante applicare il "ciclo di Deming" - Pianificare - fare - Verificare - agire- dove non solo di identificano le aree critiche ma si mettono in pista dei passi operativi per andare effettivamente
Filone 2 - analisi tecnica
Analisi che parte dalla frase "In produzione è talmente evidente che è stato scoperto immediatamente"
- in cosa differiscono l'ambiente di produzione dall' ambiente dove è stato testato il tool?
- Le condizioni che hanno portato alla manifestazione del bug sono replicabili in ambiente di test?
- La funzionalità toccata dal bug come era stata classificata? Livello di importanza Alta o invece bassa?
- per questo prima di iniziare si identificano le aree che possono essere "Critiche"( sia dal punto di vista del business che punto di vista strettamente tecnologico)
In conclusione:
Arrabbiarsi per un bug grave in produzione è abbastanza inutile, è come arrabbiarsi perché ti è caduta la bottiglia di vino pregiato che avevi appoggiato su una superfice inclinata. Prova ad appoggiarla in piano e magari lo degusterai invece di doverlo raccogliere da terra.
