Una volta trovato un difetto, ritengo che la cosa più importante da fare sia registrarlo con le informazioni chiave: un titolo o un riepilogo, i dettagli sul difetto o sul problema, su cosa succede effettivamente e cosa si aspetta che accada , i passaggi necessari per riprodurlo e l'ambiente in cui è stato trovato (ad esempio il sistema operativo, il browser Web, la versione del software in prova, ecc.). A seconda del processo, la persona che invia il rapporto sui difetti può anche assegnare priorità e / o gravità.
Dal punto di vista della QA, di solito stai guardando un software che è ancora in fase di sviluppo o, nel migliore dei casi, un candidato al rilascio. Sebbene il team di sviluppo debba eseguire l'unità, l'integrazione e alcuni test di sistema prima di arrivarci, i loro test non sono perfetti e si troveranno i problemi che il team di sviluppo deve esaminare prima di andare a rilasciare. Alla fine, spetta a qualcuno dell'organizzazione stabilire la priorità dei problemi identificati e decidere se qualcosa verrà risolto in questo ciclo di rilascio o in un ciclo di rilascio successivo.
Durante tutto il ciclo di sviluppo, sia il team di sviluppo che il team addetto al QA dovrebbero cambiare i loro test. Potrebbe esserci una test di regressione che viene sempre eseguita, ma sospetterei che il test sia più completo e focalizzato su funzionalità o parti del software che sono cambiate. I difetti potrebbero essere esposti per qualsiasi numero di motivi. Un cambiamento potrebbe aver introdotto un difetto. Un cambiamento avrebbe potuto rendere il difetto più ovvio, più facile da innescare o più comune. I nuovi casi di test potrebbero aver trovato un difetto che è stato latente nel software per un lungo periodo di tempo. Indipendentemente dal motivo per cui il difetto è stato rilevato dal test non è così importante in questo momento - la prima priorità dovrebbe essere quella di correggere il difetto.
In alcuni ambienti, come il software self-host del cliente o dove c'è l'obbligo di supportare o mantenere più versioni, potrebbe essere necessario testare più versioni del software per determinare quando il difetto è stato introdotto per consentire ai clienti di essere notificato, specialmente se si tratta di un difetto significativo. In ambienti come questi, mi aspetto che il team addetto al controllo della qualità assuma un peso maggiore nell'individuare le versioni interessate tra quelle attualmente supportate e per capire perché il problema è sfuggito a più livelli e cicli di test. / p>
Tuttavia, in ambienti in cui è supportata solo una versione del software, non sono sicuro che sia veramente importante quale versione ha iniziato il difetto. Se il difetto stava interessando gli utenti e disponevano di un meccanismo per segnalare problemi, allora lo segnalerà come un problema. Tuttavia, dal punto di vista della qualità, è importante comprendere i problemi noti con il software. Dal punto di vista della gestione del progetto, la quantità di problemi aperti può essere utilizzata per determinare se il software è pronto per essere rilasciato o per pianificare il lavoro per un ciclo di sviluppo futuro. Anche se non è programmato per essere risolto prima della fine del ciclo di sviluppo corrente, potrebbe riflettersi nella documentazione rivolta all'utente, insieme con soluzioni alternative, fino a quando non può essere risolto.
Alla fine, dopo che il difetto è stato corretto, puoi scegliere di eseguire qualche tipo di analisi delle cause principali determinare quando il difetto è stato iniettato (nell'attuale ciclo di sviluppo), perché il difetto non è stato scoperto nei precedenti cicli di sviluppo e controllo qualità (se non è stato introdotto di recente) e quali tipi di test devono essere creati, eseguiti e gestiti per evitare che questo difetto ritorni in futuro.
Per inciso, vorrei sottolineare che ci sono più idee su cosa debba essere responsabile per l'organizzazione di un QA del software. In alcune organizzazioni, il QA del software è essenzialmente un team di test che rappresenta l'ultima linea di difesa per le versioni del software per garantire che soddisfi i requisiti e non abbia problemi significativi. In altre organizzazioni, il QA del software non è solo responsabile della qualità del prodotto, ma anche della qualità del processo e può essere coinvolto in ogni fase del processo di sviluppo per garantire che tutti i prodotti di lavoro (dai requisiti ai supporti di distribuzione) siano completi e corretti per standard. Ci sono anche altre aspettative. Questa risposta si concentra maggiormente sul controllo qualità del software responsabile della qualità del prodotto.