QA vs Development Ratio [chiuso]

Question

Sto lavorando come sviluppatore di software e oggi ho avuto una lite con il nostro team addetto al controllo qualità su quanto segue:

Quanto i membri del team QA devono superare il numero di sviluppatori che stanno lavorando allo stesso prodotto?

So che questa non è una domanda su come programmare qualcosa, ma penso che questa domanda sia praticamente collegata allo sviluppo del software. Quindi spero che questa domanda non venga chiusa. Invece riceverò risposte da programmatori professionisti che hanno una buona esperienza di lavoro in società di sviluppo SW in modo da poter fare una buona statistica.

Answer 1

La risposta è molto soggettiva, ma ecco la mia esperienza.

In Microsoft abbiamo una solida organizzazione per lo sviluppo di test. È un po 'diverso dal tradizionale QA perché assumiamo programmatori per testarli e coinvolgerli nel processo già nella fase di progettazione. Il loro compito è testare e soprattutto automatizzare i test per il prodotto. Nella mia esperienza, il tester impiega all'incirca il tempo necessario per testare e automatizzare una funzionalità come fa lo sviluppatore per codificare e correggere i bug nel prodotto. Ciò implica un mapping 1: 1. Questo è molto simile alla regola empirica che la scrittura di unit test richiede fino a quando si scrive il codice

Questo mix varierà in base a diversi criteri:

1. Quanta unit test stanno facendo gli sviluppatori. Più fanno, meno test devono essere eseguiti.
2. Quanto gli sviluppatori stanno scrivendo da zero anziché sfruttando le librerie esistenti. Se è in uso un sacco di codice preesistente e i tester devono verificare anche quella funzionalità, è necessario tenere conto del costo di sviluppo sommerso per il mapping 1: 1.
3. Quanto è dinamico lo sviluppo. Se stai scrivendo un'interfaccia utente in cui modifiche dello sviluppatore relativamente piccole causano una grande modifica alla superficie testabile, avrai bisogno di più invasori di tester.
4. La mission è fondamentale. Per scrivere qualcosa come GMail dove viene usato casualmente e i bug possono essere tollerati e corretti sul campo, sono necessari meno tester. All'altro estremo, se stai lavorando su dispositivi di imaging medico , hai bisogno di molto di più test perché i bug sono difficili da correggere sul campo e molto cattivi quando si verificano.

Answer 2

Per la maggior parte dei progetti dell'azienda, lavoro con un rapporto di 1: 1. Ma questo può variare su diversi fattori:

• Uscita di sviluppo. Ho visto uno sviluppatore che aveva una grande quantità di output e aveva 3 QA funzionanti sulle sue funzionalità.
• Barra di qualità per il prodotto. Un sistema mission-critical e ad alta affidabilità dovrebbe avere una barra di QA più elevata rispetto a un sito Web di reportistica interna e avrà bisogno di più persone addette al QA.
• Alcuni progetti devono essere testati in un numero maggiore di configurazioni e scenari. Gli sviluppatori potrebbero rimanere costanti, ma ovviamente avrai bisogno di più QA per coprire l'intera matrice di test.
• Quanto è automatizzabile il test. Se i test non possono essere facilmente automatizzati, avrai bisogno di più persone per eseguire i passaggi manuali.

Answer 3

Nella mia esperienza, ci sono due tipi principali di personale addetto al controllo qualità: quelli che seguono semplicemente uno script scritto e interagiscono con un'applicazione nel tentativo di trovare casi limite, e quelli che possono effettivamente scrivere da soli il codice di test automatizzato e cercare di trovare modi nuovi e innovativi (fuzzing, selenio, scrittura di client API) per violare il codice del team di sviluppo.

Se il tuo team di controllo qualità è composto principalmente da persone del primo tipo, allora un rapporto 1: 1 o migliore rispetto ai tuoi sviluppatori è probabilmente un must. Altrimenti, faranno fatica a tenere il passo con tutte le nuove funzionalità introdotte dal team di sviluppo e spesso resisteranno a qualsiasi modifiche apportate al prodotto, perché complica ulteriormente il flusso di lavoro dei test.

Quest'ultimo tipo (vale a dire, ingegneri di test che possono codificare), d'altra parte, è un manna dal cielo per qualsiasi team di sviluppo produttivo. I programmatori possono comunicare con loro come colleghi e i tester possono trovare modi utili per automatizzare e migliorare i propri processi scrivendo imbracature e utility di test più intelligenti e meglio astratte. Un ingegnere di test davvero bravo può probabilmente supportare il lavoro di 2-3 sviluppatori, soprattutto se quegli sviluppatori stanno già scrivendo utili unità e test di integrazione che il tester può usare come punto di partenza.

Answer 4

Il mio posto di lavoro è attualmente circa 8: 1 dev: qa. La ragione di ciò è che prendiamo molto sul serio i test automatizzati. È richiesto tutto il lavoro per avere una copertura quasi completa dell'unità di test. Ci impegniamo anche in test funzionali con Fitnesse (tutte le storie degli utenti devono avere un test fitness), i check-in attivano test completi con un server CI, gli sviluppatori effettuano il check-in frequentemente, rilasciamo frequentemente.

Questo è tutto su un'applicazione ENORME con diverse migliaia di classi e innumerevoli scenari. Il vantaggio è la velocità, l'agilità e ovviamente i costi. Qualunque tempo extra uno sviluppatore (anche costoso) spenda per scrivere i test è inferiore al capitale umano di assumere / gestire più personale addetto al controllo qualità o di trovare bug nella produzione (anche il personale addetto al controllo qualità è umano dopo tutto).

Il piccolo personale addetto al controllo qualità che impieghiamo trascorre il tempo a scrivere i propri test automatizzati con Selenium o impegnarsi in nuove funzionalità. Passano relativamente poco tempo a riproporre ripetutamente la stessa funzionalità.

Answer 5

Ci sono molti fattori che rispondono a questo.

1. Hai test automatici?
2. Come sono strutturati i tuoi cicli di rilascio?
3. Qual è la percentuale di copertura del test unitario?
4. Quanto sono bravi i tuoi dipendenti (sia QA che Dev)?
5. Includete il QA nell'intero ciclo di vita del progetto o alla fine li scarichi?
6. Stai effettuando rilasci incrementali al QA?

Ho lavorato in luoghi in cui variava da 3: 1 (QA / DEV) a .5: 1 (QA / DEV). Si riduce a quante risorse di QA ci vogliono per testare adeguatamente il prodotto e non c'è una risposta a tutti.

Answer 6

In questo momento in cui lavoro ci sono 3 sviluppatori per ogni persona addetta al controllo qualità. Questo ha i suoi alti e bassi poiché a volte il QA trova un problema ma ci sono soluzioni al di fuori delle modifiche al codice, ad es. non fare clic dove è inutile farlo.

Un paio di volte non esiste un QA in cui ho lavorato che a volte è quasi una ricetta per un disastro poiché i clienti diventano il QA in quanto i loro problemi diventano problemi per gli sviluppatori.

Answer 7

La quantità di personale addetto al QA non dovrebbe dipendere dalla quantità di sviluppatori . Dovrebbe dipendere dalla qualità desiderabile del prodotto, ma non da altro.

Molti qui dicono che "al QA" il lavoro di un buon sviluppatore è un compito più semplice di "al QA" un'opera di uno sviluppatore peggiore. Diavolo, perché è vero? "Assicurare la qualità" - e il QA è "garanzia di qualità" - significa progettare un processo che contrassegna il prodotto con "QA superato". e "QA fallito". Conosco solo due processi che dipendono dal codice stesso: controllo statico del codice e revisione tra pari. Mentre il primo è in qualche modo usato, e talvolta ha bisogno di ragazzi del QA per mantenerlo, la cosa che si chiama " qualità " del codice non è ciò che conta per una macchina senz'anima. E la revisione tra pari viene eseguita dai programmatori, non dal QA. Spero che questo ti convinca che la quantità di QA non dipende dagli sviluppatori, vero?

Nel dominio in cui opera la nostra azienda, non c'è concorrenza e il mercato è molto ristretto. Pertanto riceviamo tutte le informazioni necessarie dalle segnalazioni di bug e non abbiamo QA , quindi il rapporto è zero. Tutti i test vengono eseguiti dagli sviluppatori. Tuttavia, viviamo, perché la qualità richiesta non ha bisogno di assoldare nessun ragazzo di controllo qualità.

Answer 8

Nella nostra organizzazione il rapporto è dev: QA è 5: 2, e per questo dobbiamo capire alcuni altri scenari come

1. che sta lavorando al test unitario, nel nostro caso una persona è completamente dedicata a scrivere un piano di test unitario e un team di 5 membri sta eseguendo casi di test unitari e correggendo i bug il nostro PL non è affatto coinvolto nella codifica, ma sta facendo solo cose orientate al processo / revisione

2. i test funzionali sono effettuati da un tester part-time che puoi dire una mezza risorsa e un ciclo di test funzionali eseguiti dagli sviluppatori

Quindi dipende dalle dimensioni del progetto, dalla scritta LOC e dalle risorse dell'azienda in base al loro livello CMM

Answer 9

Ci sono molti fattori, il più importante è il livello di qualità richiesto per l'applicazione, è un piccolo sito web? o uno strumento medico importante? o un sistema finanziario? Una singola riga di codice modificata per lo space shuttle potrebbe richiedere settimane di test ...

In un negozio di sviluppo progressivo, le esigenze di risorse del QA (in rapporto allo sviluppo) dovrebbero ridursi nel tempo man mano che vengono implementati i miglioramenti del QA, come TDD, Revisioni del codice, ecc. , Il QA dovrebbe essere utilizzato per migliorare il processo e aiutare gli sviluppatori a sentirsi sciocchi (rimuovendo i bug prima del rilascio).

Answer 10

Dipende dall'organizzazione e dalla web / app che si stanno sviluppando. Tutte le aziende hanno il loro rapporto di sviluppo: QA in base alle loro esigenze.

In breve, dipende dalla dimensione del progetto e dalle risorse disponibili nell'organizzazione.

Answer 11

Pensa in termini di ore trascorse rispetto al numero di persone. È del tutto possibile che per un test ben collaudato e "approvato" applicazione, per ogni ora di sviluppo, potrebbe esserci un'ora di impegno per il controllo qualità. Mi riferisco in modo specifico al ruolo di QA tecnico, non ai test funzionali. Un team di controllo qualità e un team di sviluppo devono essere in grado di lavorare a stretto contatto, in modo che il team di controllo qualità possa scrivere casi di test contemporaneamente allo sviluppo. Ciò significa che tutto deve essere scritto in un contratto di implementazione (nomi delle funzioni, parametri di input, ecc.).

Answer 12

Bene, questo dipende dalla qualità del personale alla fine della giornata. Se un programmatore lavora tanto quanto due QA, allora il rapporto è 1: 2 e viceversa. La qualità del personale qui sarebbe # 1.