Quanto dovrebbe essere dettagliato il QA?

Dire "QA" come ruolo professionale è come dire "operatore sanitario". Hai infermieri, assistenti infermieri, medici, assistenti medici, infermieri, chirurghi, ostetriche, ecc ...

Cercare di rispondere "fino a che punto il QA dovrebbe andare" è come cercare di rispondere "cosa fa un operatore sanitario?" - dipende dalla descrizione del lavoro per il quale è stata assunta la persona e dalle sue capacità.

Ho visto il QA essere persone che dovrebbero solo fare clic e verificare. Ho visto il QA dove i suoi programmatori stanno scrivendo test automatici. Ho visto il controllo di qualità in cui devono mettere il proprio marchio di approvazione su ogni versione (o non esce). Ho visto il QA che ha cercato di fare il meno possibile e non rivendicare alcuna responsabilità per il prodotto finale. Ho visto il QA dove prendono molto seriamente la parte A del processo e sono coinvolti nel processo di garanzia della qualità (assicurandosi che le revisioni del codice siano fatte, approfondendo in ISO 9000).

Quindi cosa dovrebbe fare il vostro dipartimento di QA? Di cosa hanno bisogno. Questo dipende completamente da ciò che ti serve e da ciò che sono stati assunti e quali sono le loro responsabilità. Questa è probabilmente una discussione che dovresti avere con la tua catena di gestione, se necessario. Molti programmatori scopriranno di aver avuto discussioni simili sulla necessità di raccogliere i requisiti, scrivere documentazione, preformare i test stessi - lo stesso deve essere fatto e detto del QA.

Per i problemi relativi alla descrizione dettagliata di un bug che il QA dovrebbe fornire, si tratta di un problema di qualità rispetto alla quantità. Se stanno trovando un bug in un ciclo e la suite di test richiede meno di un ciclo, allora hanno l'opportunità (dato che hanno il set di abilità appropriato - perché assumono impiegati e pagano in modo competitivo) possono quindi scrivere un bug sufficientemente dettagliato segnala che i programmatori possono lavorare da loro più facilmente.

D'altra parte, se ci si aspetta che facciano 7 giorni di test in 5, non c'è modo di poter fare un'analisi completa delle cause (RCA) sui bug che trovano - essendo sotto pressione per finire il suite di regressione.

Se il QA sta scoprendo che ogni ciclo contiene un numero sufficiente di bug che, al termine dei test, non possono eseguire un RCA su ciascuno di essi, è probabile che la qualità dei report dei bug varia notevolmente. Ciò diventa particolarmente diffuso quando non ci sono test automatici eseguiti dai programmatori: ogni volta che viene eseguita una nuova build, il QA si trova a dover assicurarsi che ogni bit di funzionalità sia sempre lo stesso. A seconda delle dimensioni dell'applicazione, ciò può significare lotti di test.

Lettura correlata:

• Qa Is not Qc e Qualità L'assicurazione non è controllo di qualità
• Garanzia della qualità del software

^{_{Minor rant - lavoriamo in un settore in cui le persone scelgono "code ninja" o "java wizard" come titolo di lavoro e così via e poi cercano di dire al "QA" le persone che dovrebbero o non dovrebbe fare qualcosa a causa del titolo di lavoro? Leggi la descrizione del lavoro. Fai ciò che è necessario. Se la descrizione del lavoro deve cambiare, cambiarla. Se qualcosa deve essere fatto, fallo.}}

In termini di "quanto profondo dovrebbe andare il QA", dipende in realtà dalle persone coinvolte e dal tipo di squadre che hai, oltre al codice base del progetto. Al mio attuale lavoro, non ci piace più il termine QA perché riteniamo che siamo tutti responsabili di garantire la qualità. I nostri sviluppatori praticano TDD e test unitari il più possibile della base di codice (oltre all'integrazione e praticamente qualsiasi altro test automatizzato che possiamo costruire). Abbiamo quindi un piccolo team di tester, questi ragazzi hanno utilizzato i prodotti praticamente dal primo giorno e lo conoscono dentro e fuori (dal punto di vista dell'utente).

Quando trovano un bug che è sfuggito al test automatico, ce lo segnalano con tutti i dettagli che possono raccogliere da una vista utente. Cercano efficacemente di bloccare il problema il più rapidamente possibile nei passaggi di ricreazione e questi passaggi diventano quindi i criteri di accettazione. Cioè: "se x y e z non causano più j e k, allora il bug è risolto."

Per quanto riguarda il compito di chi trova la causa principale, diciamo che chiunque trovi il bug dovrebbe tentare di fornire quanti più dettagli possibile a chiunque lavori su una correzione. Questo risolve il problema il più velocemente possibile e conoscere l'estensione del problema in anticipo contribuirà solo a velocizzare questo processo.

Se i tuoi tester che agiscono da una vista utente non tenteranno di ricreare il bug in un numero di modi diversi per ottenere più informazioni per risolvere le cose più velocemente, allora direi che hai una separazione malsana di team in corso sopra. Sviluppo e QA vanno di pari passo, la rivalità amichevole è grande e benefica, ma quando una squadra inizia a diventare imbarazzante per le cose, allora hai un problema. Frasi come "bene i criteri di accettazione sono tecnicamente soddisfatti" o "Ho trovato il bug, non è il mio lavoro suggerire una correzione", penso che tu debba guardare come i tuoi team stanno lavorando insieme per ottenere alta qualità piuttosto che interrogare chi dovrebbe fare ciò che specificamente.

"Prevedo che il QA non troverà nulla [...] Il QA dovrebbe chiedersi perché esistano" - Uncle Bob.