Test manualeQA Engineer

Quali approcci e tecniche possono aiutare un tester manuale a identificare difetti nascosti o poco evidenti che non sono documentati nei requisiti e non sono coperti dai casi di test? Come documentarli correttamente?

Supera i colloqui con l'assistente IA Hintsage

Risposta

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:

  • Necessità di iniziativa e pensiero critico.
  • È importante argomentare perché questo è un difetto.
  • In alcuni casi, è necessario partecipare a discussioni con analisti/PO.

Domande insidiose.

È 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.

Errori tipici e anti-pattern

  • Ignorare difetti evidenti per gli utenti non documentati nei requisiti.
  • Documentazione scarsa/incompleta dei bug nascosti.
  • Mancanza di argomentazione per il bug report.

Esempio dalla vita reale

Caso negativo

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:

  • Non ha aggiunto un "bug superfluo" e ha liberato i programmatori per altre attività.

Svantaggi:

  • Il sistema è stato rilasciato con una vulnerabilità critica e i clienti ne hanno sofferto.

Caso positivo

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:

  • Il bug è stato prontamente risolto e gli utenti finali non hanno incontrato il problema.

Svantaggi:

  • È stato necessario del tempo per discutere lo scenario con gli analisti.