Test degli sviluppatori vs.Test del team QA: qual è la giusta divisione del lavoro?[Chiuso]

Question

Mentre cerco di sostenere più testing da parte degli sviluppatori, trovo l'argomento "Non è questo il lavoro del QA?" è usato molto.A mio avviso, non ha senso dare al team QA tutte le responsabilità dei test, ma allo stesso tempo Spolsky e altri dicono che non dovresti usare sviluppatori da $ 100/ora per fare qualcosa che un tester da $ 30/ora potrebbe fare .Quali sono le esperienze degli altri in un'azienda con un team QA dedicato?Dove dovrebbe essere tracciata la divisione del lavoro?

Una precisazione:Intendevo il QA come un team di convalida e verifica.Gli sviluppatori non dovrebbero eseguire la convalida (test incentrato sul cliente), ma dov'è il punto di divisione della verifica (test funzionale)?

Answer 1

È la differenza tra " scatola nera " test (dove sai cosa dovrebbe fare il codice, ma non come funziona), e "scatola bianca" test (dove sapere come funziona guida il modo in cui lo testate). " scatola nera " i test sono ciò a cui pensa la maggior parte delle persone quando menzioni la garanzia della qualità.

Lavoro per un'azienda in cui il team QA è anche sviluppatori di software. (Ciò restringe il campo molto se ti interessa indovinare la compagnia.) Conosco l'opinione di Joel e la mia esperienza mi porta a non essere d'accordo: per lo stesso motivo per cui un cappello bianco " l'hacker è più efficace nel trovare falle nella sicurezza, alcuni tipi di errori sono trovati in modo più efficace dai tester della scatola bianca che sanno come scrivere il codice (e quindi quali sono gli errori comuni - ad esempio, problemi di gestione delle risorse come perdite di memoria).

Inoltre, poiché gli sviluppatori orientati al QA fanno parte del processo sin dalla fase di progettazione iniziale, possono teoricamente aiutare a guidare codice di qualità superiore durante tutto il processo. Idealmente, per ogni sviluppatore che lavora al progetto con un focus mentale sulla funzionalità, hai uno sviluppatore avversario con un focus mentale sulla violazione del codice (e quindi migliorandolo).

Visto sotto questa luce, è meno una questione di utilizzo degli sviluppatori per i tester che di una sorta di programmazione disconnessa delle coppie in cui uno sviluppatore si concentra sul controllo della qualità.

D'altra parte, molti test (come la funzionalità di base dell'interfaccia utente) francamente non hanno bisogno di quel tipo di abilità. Ecco dove Joel ha ragione.

Per molte aziende, ho potuto vedere un sistema in cui i team di programmazione si scambiavano le attività di revisione del codice e di verifica del codice reciproco. I membri del team di Business Logic, ad esempio, potrebbero trascorrere un tour occasionale per testare e rivedere il codice per il team dell'interfaccia utente e viceversa. In questo modo non stai "sprecando" talento degli sviluppatori nei test a tempo pieno, ma stai ottenendo i vantaggi di esporre il codice a (speriamo) controllo e punizione da parte di esperti. Quindi, un team di QA più tradizionale può occupare la "scatola nera" test.

Answer 2

Se del caso, i team di controllo qualità dovrebbero essere in grado di condurre test di sicurezza, regressione, usabilità, prestazioni, stress, installazione / aggiornamento e non sviluppatori

Gli sviluppatori dovrebbero effettuare unit test con copertura del codice per il codice che viene scritto come obiettivo minimo.

Nel mezzo, c'è ancora un bel po 'di test da fare

• test del percorso del codice completo
• Test dei componenti
• Test di integrazione (dei componenti)
• Test di sistema (integrazione)
• etc

La responsabilità di questi sono mescolati tra QA e sviluppo sulla base di un accordo reciproco su ciò che ha più senso. Alcuni test dei componenti possono essere eseguiti solo tramite test unitari, altri sono testati "sufficientemente" durante i test di integrazione ecc.

Parlate tra loro, scoprite cosa fanno tutti a proprio agio. Ci vorrà del tempo, ma ne vale la pena.

Answer 3

Dovrebbero esserci sempre dei test per gli sviluppatori. Se uno sviluppatore sta producendo troppi bug, allora sta perdendo tempo a correggere quei bug. È importante che gli sviluppatori non sviluppino l'atteggiamento che dice, vabbè se lascio un bug, verrà catturato e avrò la possibilità di risolverlo.

Cerchiamo di mantenere una soglia per i bug prodotti. Se questa soglia viene superata durante il test, lo sviluppatore è responsabile per questo. Sta a te decidere quale sia questa soglia (per noi può variare da un progetto all'altro).

Inoltre, tutti gli unit test vengono eseguiti dagli sviluppatori.

Answer 4

Sono stato nel settore solo per un anno, ma nella mia esperienza gli sviluppatori sono responsabili del test unitario delle loro funzionalità, mentre il controllo qualità è responsabile degli scenari di test. Il QA dovrebbe inoltre verificare eventuali condizioni diverse.

Answer 5

Sto incollando la mia risposta a una domanda sul nostro forum interno. Se hai circa un'ora .. ascolta il

I test dovrebbero essere il più automatizzati possibile, il che lo trasformerà nuovamente in sviluppo se i tester stanno scrivendo codice che viene aggiunto alla suite di test automatizzata.

Inoltre, ho scoperto che nella revisione del codice vengono eseguiti molti controlli di qualità, in quanto le persone suggeriranno ulteriori casi limite e angolari che desiderano vedere aggiunti ai test unitari in fase di revisione (insieme al codice che testano ovviamente).

La mia posizione generale è che i tester non dovrebbero mai trovare bug a livello di unità (compresi i casi limite). I tester dei bug rilevati dovrebbero trovarsi a livello di componente, integrazione o sistema. Naturalmente, all'inizio i tester possono trovare "percorso felice" bug e altri semplici bug, ma queste anomalie dovrebbero essere utilizzate per aiutare gli sviluppatori a migliorare.

Parte del tuo problema potrebbe essere l'utilizzo di sviluppatori da $ 100 dollari l'ora e tester da $ 30 all'ora:}. Ma a prescindere dal costo, penso che sapendo che i bug rilevati in precedenza nel ciclo di sviluppo sono inevitabilmente più economici, probabilmente risparmieresti ancora facendo in modo che gli sviluppatori possiedano più test. Se hai un team di sviluppatori altamente pagato e tester di hacking, probabilmente troverai molti dei grandi problemi ovvi, ma perderai molti dei bug più oscuri che torneranno a perseguitarti in seguito.

Quindi, suppongo che la risposta alla tua domanda sia che i tester dovrebbero testare quanto vuoi. Puoi licenziare tutti i tester e fare in modo che gli sviluppatori facciano tutti i test, oppure puoi assumere un esercito di tester e lasciare che gli sviluppatori effettuino il check in quello che vogliono.

Esistono 2 tipi di gruppi qa, quelli che vogliono mantenere lo status quo. Lo abbiamo sempre fatto. Odiano e si liberano naturalmente di coloro che cercano di rendere le cose più efficienti e quindi vanno oltre la loro zona di comfort. Mi è successo più di una volta. Sfortunatamente i gestori di qa sono incompetenti come i loro team di qa. Quindi un responsabile della qualità che gestisce da 6 anni ucciderà qualsiasi automazione, introdurrà molti processi solo per giustificare la sua esistenza. Questa è una responsabilità del management superiore di riconoscerlo.     Ci sono persone di qa un po 'tecniche che conoscono gli strumenti. Purtroppo un linguaggio di programmazione non è uno strumento, ma una visione. Lavorare con queste persone dipende davvero da quanto sono disposti a imparare e da quanto la direzione è disposta a correre il rischio di cambiare le cose. I test devono essere scritti nello stesso modo in cui un codice principale è una struttura orientata agli oggetti scritta facile da mantenere. Penso che gli sviluppatori dovrebbero rivedere i test di qualità. Il più delle volte ho scoperto che l'automazione non stava testando nulla. Sfortunatamente il lavoro di qa è considerato di classe inferiore, quindi gli sviluppatori non si preoccupano. Anch'io ho fortuna, quando ho il supporto di uno sviluppatore influente in un gruppo, che è disposto a spiegare i miei sforzi a un manager. Sfortunatamente funziona solo la metà delle volte. I tester IMHO dovrebbero riferire al responsabile dello sviluppo. E tutto il team dovrebbe assumersi la responsabilità di ciò che i test di qa effettivamente testano.

Ecco alcuni modi in cui il test degli sviluppatori è il più efficace / il più alto profitto:

• Lo sviluppatore modifica una libreria condivisa mentre lavora su una funzione - dev ha una visione dei possibili effetti collaterali che QA / validazione non ha
• Lo sviluppatore non è sicuro dell'esecuzione della chiamata in libreria e scrive un unit test
• Lo sviluppatore scopre il caso d'uso non considerato nelle specifiche che il codice deve supportare, scrive il codice, aggiorna la specifica, scrive il test

È discutibile quanto dovere di prova dovrebbe essere svolto dallo sviluppatore nel terzo esempio, ma sostengo che è più efficiente per lo sviluppatore perché tutte le minuzie correlate da molti strati di documentazione e codice sono già nel suo corto- termine memoria. Questa tempesta perfetta potrebbe non essere raggiungibile da un tester dopo il fatto.

Stiamo parlando di QA o validazione? Penso al QA sulla falsariga di checklist di controllo, applicazione di standard di codice, linee guida dell'interfaccia utente, ecc. Se stiamo parlando di validazione, non ha senso che gli sviluppatori trascorrano molto tempo a creare ed eseguire casi di test formali, ma gli sviluppatori deve fornire tutta la documentazione logica e di progettazione necessaria per creare buoni test.

Answer 6

Answer 7

Answer 8

I test dovrebbero essere il più automatizzati possibile, il che lo trasformerà nuovamente in sviluppo se i tester stanno scrivendo codice che viene aggiunto alla suite di test automatizzata.

Inoltre, ho scoperto che nella revisione del codice vengono eseguiti molti controlli di qualità, in quanto le persone suggeriranno ulteriori casi limite e angolari che desiderano vedere aggiunti ai test unitari in fase di revisione (insieme al codice che testano ovviamente).

Answer 9

La mia posizione generale è che i tester non dovrebbero mai trovare bug a livello di unità (compresi i casi limite). I tester dei bug rilevati dovrebbero trovarsi a livello di componente, integrazione o sistema. Naturalmente, all'inizio i tester possono trovare "percorso felice" bug e altri semplici bug, ma queste anomalie dovrebbero essere utilizzate per aiutare gli sviluppatori a migliorare.

Parte del tuo problema potrebbe essere l'utilizzo di sviluppatori da $ 100 dollari l'ora e tester da $ 30 all'ora:}. Ma a prescindere dal costo, penso che sapendo che i bug rilevati in precedenza nel ciclo di sviluppo sono inevitabilmente più economici, probabilmente risparmieresti ancora facendo in modo che gli sviluppatori possiedano più test. Se hai un team di sviluppatori altamente pagato e tester di hacking, probabilmente troverai molti dei grandi problemi ovvi, ma perderai molti dei bug più oscuri che torneranno a perseguitarti in seguito.

Quindi, suppongo che la risposta alla tua domanda sia che i tester dovrebbero testare quanto vuoi. Puoi licenziare tutti i tester e fare in modo che gli sviluppatori facciano tutti i test, oppure puoi assumere un esercito di tester e lasciare che gli sviluppatori effettuino il check in quello che vogliono.

Esistono 2 tipi di gruppi qa, quelli che vogliono mantenere lo status quo. Lo abbiamo sempre fatto. Odiano e si liberano naturalmente di coloro che cercano di rendere le cose più efficienti e quindi vanno oltre la loro zona di comfort. Mi è successo più di una volta. Sfortunatamente i gestori di qa sono incompetenti come i loro team di qa. Quindi un responsabile della qualità che gestisce da 6 anni ucciderà qualsiasi automazione, introdurrà molti processi solo per giustificare la sua esistenza. Questa è una responsabilità del management superiore di riconoscerlo.     Ci sono persone di qa un po 'tecniche che conoscono gli strumenti. Purtroppo un linguaggio di programmazione non è uno strumento, ma una visione. Lavorare con queste persone dipende davvero da quanto sono disposti a imparare e da quanto la direzione è disposta a correre il rischio di cambiare le cose. I test devono essere scritti nello stesso modo in cui un codice principale è una struttura orientata agli oggetti scritta facile da mantenere. Penso che gli sviluppatori dovrebbero rivedere i test di qualità. Il più delle volte ho scoperto che l'automazione non stava testando nulla. Sfortunatamente il lavoro di qa è considerato di classe inferiore, quindi gli sviluppatori non si preoccupano. Anch'io ho fortuna, quando ho il supporto di uno sviluppatore influente in un gruppo, che è disposto a spiegare i miei sforzi a un manager. Sfortunatamente funziona solo la metà delle volte. I tester IMHO dovrebbero riferire al responsabile dello sviluppo. E tutto il team dovrebbe assumersi la responsabilità di ciò che i test di qa effettivamente testano.

Ecco alcuni modi in cui il test degli sviluppatori è il più efficace / il più alto profitto:

• Lo sviluppatore modifica una libreria condivisa mentre lavora su una funzione - dev ha una visione dei possibili effetti collaterali che QA / validazione non ha
• Lo sviluppatore non è sicuro dell'esecuzione della chiamata in libreria e scrive un unit test
• Lo sviluppatore scopre il caso d'uso non considerato nelle specifiche che il codice deve supportare, scrive il codice, aggiorna la specifica, scrive il test

È discutibile quanto dovere di prova dovrebbe essere svolto dallo sviluppatore nel terzo esempio, ma sostengo che è più efficiente per lo sviluppatore perché tutte le minuzie correlate da molti strati di documentazione e codice sono già nel suo corto- termine memoria. Questa tempesta perfetta potrebbe non essere raggiungibile da un tester dopo il fatto.

Stiamo parlando di QA o validazione? Penso al QA sulla falsariga di checklist di controllo, applicazione di standard di codice, linee guida dell'interfaccia utente, ecc. Se stiamo parlando di validazione, non ha senso che gli sviluppatori trascorrano molto tempo a creare ed eseguire casi di test formali, ma gli sviluppatori deve fornire tutta la documentazione logica e di progettazione necessaria per creare buoni test.

Answer 10

La mia posizione generale è che i tester non dovrebbero mai trovare bug a livello di unità (compresi i casi limite). I tester dei bug rilevati dovrebbero trovarsi a livello di componente, integrazione o sistema. Naturalmente, all'inizio i tester possono trovare "percorso felice" bug e altri semplici bug, ma queste anomalie dovrebbero essere utilizzate per aiutare gli sviluppatori a migliorare.

Parte del tuo problema potrebbe essere l'utilizzo di sviluppatori da $ 100 dollari l'ora e tester da $ 30 all'ora:}. Ma a prescindere dal costo, penso che sapendo che i bug rilevati in precedenza nel ciclo di sviluppo sono inevitabilmente più economici, probabilmente risparmieresti ancora facendo in modo che gli sviluppatori possiedano più test. Se hai un team di sviluppatori altamente pagato e tester di hacking, probabilmente troverai molti dei grandi problemi ovvi, ma perderai molti dei bug più oscuri che torneranno a perseguitarti in seguito.

Quindi, suppongo che la risposta alla tua domanda sia che i tester dovrebbero testare quanto vuoi. Puoi licenziare tutti i tester e fare in modo che gli sviluppatori facciano tutti i test, oppure puoi assumere un esercito di tester e lasciare che gli sviluppatori effettuino il check in quello che vogliono.

Answer 11

Esistono 2 tipi di gruppi qa, quelli che vogliono mantenere lo status quo. Lo abbiamo sempre fatto. Odiano e si liberano naturalmente di coloro che cercano di rendere le cose più efficienti e quindi vanno oltre la loro zona di comfort. Mi è successo più di una volta. Sfortunatamente i gestori di qa sono incompetenti come i loro team di qa. Quindi un responsabile della qualità che gestisce da 6 anni ucciderà qualsiasi automazione, introdurrà molti processi solo per giustificare la sua esistenza. Questa è una responsabilità del management superiore di riconoscerlo.     Ci sono persone di qa un po 'tecniche che conoscono gli strumenti. Purtroppo un linguaggio di programmazione non è uno strumento, ma una visione. Lavorare con queste persone dipende davvero da quanto sono disposti a imparare e da quanto la direzione è disposta a correre il rischio di cambiare le cose. I test devono essere scritti nello stesso modo in cui un codice principale è una struttura orientata agli oggetti scritta facile da mantenere. Penso che gli sviluppatori dovrebbero rivedere i test di qualità. Il più delle volte ho scoperto che l'automazione non stava testando nulla. Sfortunatamente il lavoro di qa è considerato di classe inferiore, quindi gli sviluppatori non si preoccupano. Anch'io ho fortuna, quando ho il supporto di uno sviluppatore influente in un gruppo, che è disposto a spiegare i miei sforzi a un manager. Sfortunatamente funziona solo la metà delle volte. I tester IMHO dovrebbero riferire al responsabile dello sviluppo. E tutto il team dovrebbe assumersi la responsabilità di ciò che i test di qa effettivamente testano.

Answer 12

Ecco alcuni modi in cui il test degli sviluppatori è il più efficace / il più alto profitto:

• Lo sviluppatore modifica una libreria condivisa mentre lavora su una funzione - dev ha una visione dei possibili effetti collaterali che QA / validazione non ha
• Lo sviluppatore non è sicuro dell'esecuzione della chiamata in libreria e scrive un unit test
• Lo sviluppatore scopre il caso d'uso non considerato nelle specifiche che il codice deve supportare, scrive il codice, aggiorna la specifica, scrive il test

È discutibile quanto dovere di prova dovrebbe essere svolto dallo sviluppatore nel terzo esempio, ma sostengo che è più efficiente per lo sviluppatore perché tutte le minuzie correlate da molti strati di documentazione e codice sono già nel suo corto- termine memoria. Questa tempesta perfetta potrebbe non essere raggiungibile da un tester dopo il fatto.

Stiamo parlando di QA o validazione? Penso al QA sulla falsariga di checklist di controllo, applicazione di standard di codice, linee guida dell'interfaccia utente, ecc. Se stiamo parlando di validazione, non ha senso che gli sviluppatori trascorrano molto tempo a creare ed eseguire casi di test formali, ma gli sviluppatori deve fornire tutta la documentazione logica e di progettazione necessaria per creare buoni test.

Answer 13

Answer 14