Chi è responsabile per i difetti riscontrati durante lo sviluppo?

Come molte cose, dipende. Come altri hanno sottolineato, assegnare la colpa è un buon modo per scoraggiare qualcuno ed è un modo rapido per far sì che qualcuno lasci la tua organizzazione. Alla maggior parte delle persone non piace essere biasimati per le cose tutte le volte e quando si scrive codice ed è più o meno inevitabile che alcuni errori, errori e altri errori casuali scivolino nel codice nel tempo.

Tuttavia, anche fissare un nome per quei bug, errori e altri errori casuali può essere difficile, poiché non tutto è dovuto al codice che scrivi, se hai un'API bacata (rara, ma succede) è la colpa degli sviluppatori o della società che ha scritto l'errore dell'API? Allo stesso modo, se si verifica un errore hardware casuale e qualcosa non viene salvato correttamente, è anche colpa di qualcuno per cominciare?

Generalmente, la responsabilità di correggere il problema ricade sugli sviluppatori e talvolta sui responsabili dell'interfaccia con i clienti per la progettazione, ma la responsabilità di correggere il problema non è la stessa che viene incolpata per questo. In generale, se qualcuno fa uno sforzo in buona fede per fare qualcosa in modo corretto, non ho intenzione di incolparli per aver incasinato qualcosa, anche se potrebbe essere un'esperienza di apprendimento per loro. Allo stesso modo, se qualcosa supera il QA e viene distribuito, è colpa di QA per non aver individuato il problema in anticipo?

In termini di ruolo del QA: dovrebbero collaborare con gli sviluppatori e gli altri membri del loro team per garantire che il prodotto finale sia il più stabile e corretto possibile.

Le organizzazioni funzionano bene quando QA e Dev hanno obiettivi condivisi e responsabilità condivisa (compresa la responsabilità finanziaria per il benessere dell'azienda) per eventuali errori che entrano in produzione.

Nella mia esperienza, le situazioni in cui Dev e QA sono misurate indipendentemente e c'è rivalità fanno male alla società nel lungo periodo.

Gli errori accadono, è vero. Alcuni bug possono essere prevenuti (ad es. Con un migliore test dell'unità).

Una situazione in cui uno sviluppatore può essere facile testare perché "il controllo qualità rileva errori" è rischioso. Il lavoro di QA è quello di trovare le cose che come sviluppatore non potresti trovare con la tua due diligence.

La responsabilità del controllo qualità consiste nel trovare errori e segnalarli in un modo che consenta agli sviluppatori di riprodurli e eseguirne il debug in modo semplice e chiaro.

Ho visto luoghi in cui il QA non è apprezzato e gli sviluppatori sentono che "Sono fuori per averli". Di solito è un problema di comunicazione. Ma trovare errori è il lavoro di tutti - non gli eventuali utenti finali.

Per produrre codice di qualità, è necessario concentrarsi sulla qualità del codice e non su chi siano i bug. Basta correggerli.

L'obiettivo del QA non dovrebbe essere quello di trovare bug, dovrebbe essere quello di verificare che non ce ne siano. Cambiando questo obiettivo ricompensando i membri del team QA per la registrazione di un certo numero di difetti, si crea una relazione avversaria in cui il team QA sta cercando i guasti con il team Dev. Non è un buon mix.

Analogamente, se Dev ritiene che sia compito di QA trovare i difetti, allora la qualità diventa il lavoro di qualcun altro. Se un insetto esce dalla porta, è colpa di QA. Se funziona, Dev ha fatto un lavoro fantastico. Perché dedicare del tempo a scrivere un codice di qualità?

Per quanto riguarda la terminologia, è importante dal punto di vista della tracciabilità di metrica e possibilmente dal flusso di lavoro. Preferisco i termini "bug" e "difetto". I difetti ottengono "patch" (singoli file), "correzioni rapide" (raccolte) o "service pack" (interi programmi di installazione) e bug sono corretti nelle versioni future.

Gli sviluppatori non introducono bug intenzionalmente, lo fanno facendo attenzione. Se implementano correttamente ciò che è stato progettato, non vi è alcun bug dal punto di vista dello sviluppatore e la colpa (se si vuole usare la parola) va a chi è responsabile del design. Il QA non dovrebbe necessariamente trovare errori di progettazione, dovrebbero trovare implementazioni che si discostano dal design e, in tal caso, potrebbe essere il problema di un programmatore.

Ogni sviluppatore che ho incontrato l'ha preso come un insulto personale quando vengono trovati bug nel suo codice. È un segno che loro si preoccupano del loro mestiere, ma può essere eccessivo.

Sono d'accordo che è impossibile codificare qualcosa senza bug esistenti in qualsiasi momento, ma è possibile inviare qualcosa da testare senza errori. Non dovresti mandarlo al QA non appena viene compilato, ma non dovresti esagerare durante il test del tuo codice. Parla con i tuoi colleghi della percentuale e della natura dei bug rilevati dal QA. Vedi se è in un intervallo accettabile.

Personalmente, devo un ragazzo della QA un paio di birre per alcune delle cose che ho mandato sulla sua strada. Ma nel complesso andiamo d'accordo e il processo funziona.

Chiamiamo tutti i bug, errori, ecc. "difetti". Se c'è stato un problema con il progetto fondamentale (anche se il programma ha implementato correttamente il cattivo design), di solito viene rimandato agli analisti come difetto di progettazione per una riprogettazione.

Per quanto riguarda i programmatori dovrebbero essere incolpati di bug ... Beh, è vero che è molto difficile per il programmatore catturare tutto, ed è vero che le persone del QA dovrebbero prendere questa roba, ma ci sono alcune cose che un programmatore dovrebbe essere a conoscenza e confrontarsi anche se le persone del QA non lo hanno sul loro test. Questo potrebbe riguardare problemi come l'allocazione delle risorse in cui il programmatore scrive codice che non rilascia correttamente la memoria, e il QA non ha un test adatto a innescare il problema della memoria (probabilmente perché non sapevano che una cosa del genere accadesse - ed è difficile da testare per cose che non si conoscono) ... Idealmente, un round di stress / carico e test delle prestazioni prenderebbe un problema simile, ma se l'applicazione è molto complicata e l'errore si innesca solo in casi molto particolari. .. forse il programmatore avrebbe dovuto essere un po 'più attento con il loro uso della memoria.

Quindi ... dovrebbero essere incolpati i programmatori? Dipende davvero dalla situazione, ma con un numero sufficiente di persone coinvolte, la colpa può essere facilmente dispersa in una grande folla. ;)

Questa distinzione è il motivo per cui ho apprezzato molto la tendenza Agile, e in particolare l'idea di creare non per "specialità", ma per progetto !

Quando un bug / difetto è scoperto, il progetto è minacciato. Che il bug provenga da un cattivo design, un problema tecnico, una cattiva implementazione delle specifiche o qualsiasi cosa sia irrilevante per il cliente: non funziona come lei vuole!

Pertanto, un bug in un progetto è per definizione la responsabilità delle persone che lavorano su questo progetto (tutti) ... e di coloro che hanno fornito assistenza (inclusi i clienti). Puntare il dito fa più male di quanto non aiuti, poiché da molto tempo il problema risiede nella comunicazione / ambiguità più di ogni altra cosa.

Detto questo, ci sono errori coding , che sono propri degli sviluppatori. Non esitare da loro, invece dovresti congratularti con cuore con chi li ha trovati (e chiedi scusa ...)

Impariamo dai nostri errori. A volte i requisiti e le specifiche sono così ampi che solo sperimentando il progetto andrà avanti. A volte ci sono casi angolari nella lingua / con la tecnologia, e colpendoli li scoprirai e imparerai a fare meglio. A volte il cliente ha chiesto qualcosa e solo fornendolo ti renderai conto che anche se risolve il problema che hanno descritto, il vero problema risiede altrove ...

Bugs and Defects sono un'occasione per imparare e per lucidare il prodotto che stai creando con un livello ancora più alto di qualità. A chi importa di incolpare? Pensa solo a cosa può essere fatto per migliorare il prodotto.

In una squadra sana in cui non ci sono programmatori evidentemente incompetenti che dovrebbero essere licenziati, nessuno dovrebbe essere incolpato poiché i programmatori non producono errori intenzionalmente - non c'è semplicemente nulla da incolpare per. Tuttavia tutti dovrebbero essere responsabili di adottare misure per prevenire tali errori in futuro - è compito loro produrre software di qualità.

Ti consiglierei di leggere sul processo di sviluppo del software in NASA ( link ). Sebbene non sia applicabile per la maggior parte delle aziende, ci sono ancora molte cose da imparare.

"Bug" è un termine molto ampio e spesso utilizzato in modo improprio, quindi ti preghiamo di definire cosa intendi per "bug".

Detto questo, generalmente, chi ha scritto il codice è responsabile del difetto. Ma a volte i "bug" sono dovuti a carenze nella raccolta dei requisiti o cattivo comportamento da parte di altri componenti di un sistema che il writer del codice non poteva prevedere e / o controllare.