Storia della questione:
Con l'aumento della complessità del software, è stato notato che alcuni bug vengono scoperti solo al di fuori dei casi di test o delle specifiche: spesso, questi bug sono i più critici per gli utenti reali. Per cercare difetti simili, i tester utilizzano tecniche speciali, combinando test standard con la propria esperienza.
Problema:
I bug nascosti, legati all'interazione tra i componenti, a una gestione errata di situazioni non evidenti o all'assenza di requisiti, sono i più difficili da individuare e documentare. Spesso i tester non sono sicuri se dovrebbero registrare un problema trovato se non è "indicato nel documento dei requisiti".
Soluzione:
Sono utilizzati metodi di testing esplorativo, test di coppia e l'esperienza con prodotti simili. È fondamentale documentare un bug in modo il più dettagliato possibile: passi, osservazioni, perché lo si considera un difetto, collegamenti a requisiti affini o logiche accettate.
Caratteristiche chiave:
È possibile non registrare o ignorare bug non descritti nei requisiti?
No, si deve sempre segnalare, anche se non c'è un riferimento preciso al requisito, altrimenti problemi critici arriveranno al cliente.
Un'inconvenienza per l'utente è un bug o un miglioramento (feature request)?
Se il comportamento è chiaramente illogico, genera confusione o rischi, registralo come bug, altrimenti come miglioramento.
Un tester dovrebbe consultarsi con il team su ogni bug non evidente?
Si consiglia di discutere in anticipo il caso controverso con un analista o uno sviluppatore, per evitare ticket inutili.
Il tester ha notato che aprendo contemporaneamente due finestre il sistema si bloccava, ma non ha registrato il bug, poiché tale scenario non era descritto nei requisiti e nei casi di test.
Vantaggi:
Svantaggi:
Il tester ha registrato un bug descrivendo i passaggi (apertura di due finestre, sequenza di azioni), ha allegato uno screenshot e spiegato perché lo considera un bug (un utente reale potrebbe trovarsi in quella situazione).
Vantaggi:
Svantaggi: