Qual è un buon rapporto tra sviluppatori e tester?

Question

Qual è il rapporto tra sviluppatori [senior] e tester che la gente ritiene migliore?

Ovviamente questo dipenderà in parte dalla velocità di sviluppo / manutenzione, ma esiste una regola empirica su cui una nuova società / progetto potrebbe funzionare?

Utilizzeresti anche tester "puri" o combineresti i test con altri ruoli (ad es. documentazione, formazione degli utenti, ecc.)

Ovviamente, le risposte possono dipendere dalla strategia aziendale / dai modelli di sviluppo utilizzati, quindi si prega di specificare se si sta rispondendo in generale, o se per uno stile specifico di prodotto / rilascio e così via.

Answer 1

Prima di tutto, gli sviluppatori per i tester è una buona regola empirica , ma è una cattiva regola .

Quello che devi considerare è quanti casi d'uso ha la tua applicazione. Le applicazioni con cui gli utenti interagiranno in modo incontrollato (applicazioni web I.E. o applicazioni desktop) richiederanno più tester di un'applicazione console simile.

Un'applicazione che prende un singolo file e rileva modelli di regex in esso richiederà meno tester rispetto a un nuovo sistema operativo.

Mentre quelle sono massime generali, il consiglio pratico sarebbe di usare una sorta di formula approssimativa basata su questi fattori

1) Quanti casi d'uso (compartimentati) ci sono?

Dico casi d'uso compartimentati perché se includi cambiamenti di stato e variabili persistenti, allora parti apparentemente non correlate di un programma possono risultare correlate. OSSIA 2 + 2 = 4 (1 caso d'uso) 2 * 2 = 4 (2o caso d'uso). Sono due semplici operatori, quindi due classi di casi d'uso. Tuttavia, se puoi aggiungere quindi moltiplicare , non puoi controllare SOLO aggiungi e moltiplicare singolarmente, tu devono controllarli in tutte le loro possibili permutazioni.

Quando si esamina il numero di casi d'uso, assicurarsi di includere i casi d'uso che comportano il concatenamento dei comandi.

2) Quanto tempo ci vuole per testarli?

Questo non significa (estendere la metafora della calcolatrice) solo aggiungendo 2 + 2 e guardando la risposta. È necessario includere il tempo necessario per il ripristino da un arresto anomalo. Se la risposta non è corretta, ci si aspetterebbe che il tester registri il bug con uno screenshot e istruzioni specifiche su come ricreare il bug. Se non dai loro il tempo per questo tipo di lavoro amministrativo, allora stai inserendo il tuo piano nel presupposto che non hai bug. E se lo stiamo assumendo, allora perché hanno dei tester;)

Un progetto complesso avrà sia un numero elevato di casi d'uso, sia un numero elevato di sviluppatori, ma non sono una correlazione garantita. È meglio esaminare attentamente i casi d'uso e prendere una decisione consapevole su quanti tester saranno richiesti.

Bonus aggiunto. Dopo aver suddiviso l'applicazione in modo così approfondito, potresti trovare alcuni casi d'uso che non sono mai stati considerati in fase di progettazione e risolverli prima che un tester li trovi.

Answer 2

Joel fa una buona argomentazione per 1 tester per ogni 2 ingegneri, nonché coprendo le scuse che le persone usano per non avere quei tester.

Answer 3

Ho scritto questo blog una volta qui . L'estratto più pertinente è di seguito.

" Ho visto prodotti di alta qualità realizzati con un rapporto dev: 10: 1 e prodotti orribili creati con un rapporto 1: 1. La differenza sta nell'attenzione e nella cura per la qualità. Se tutti (compresa la gestione) del team si preoccupano profondamente della qualità del prodotto, ha buone probabilità di accadere indipendentemente dal rapporto. Ma se la qualità è qualcosa che dovrebbe essere testato nel prodotto, sicuramente ha almeno 1 tester per ogni sviluppatore - più se puoi ottenerli. & Quot;

Answer 4

C'è stato un recente articolo pertinente su InfoQ che potresti trovare interessante.

Answer 5

Questa stringa è apparentemente piuttosto vecchia. Ma le risposte mi sono sembrate tutte sbagliate.

1). La domanda di un rapporto tra sviluppatore e tester è valida, poiché più complessi sono i requisiti, più sviluppatori sono necessari e quindi sono necessari più tester. Molte delle risposte sembrano respingere questo.

2). Indipendentemente dai domini applicativi, un buon rapporto che funziona nel mondo reale per il software "di alta qualità" è 2: 1. Puoi vivere con 4: 1, ma è davvero allungato. Naturalmente, ci sono molte variabili in questa stima, non solo la complessità dei requisiti, i sistemi / ambienti da implementare, ma anche quanto siano produttivi gli sviluppatori e quanto sia rigoroso il programma di consegna.

HTH

Answer 6

A mio avviso, una buona metrica da utilizzare per determinare il numero di tester necessari è la complessità dei requisiti, non il numero di sviluppatori. Se assumessi tester, darei un'occhiata all'elenco dei requisiti (o spezzerei il documento di progettazione in un elenco di requisiti se necessario) e penserei a quanto tempo di test ogni requisito avrebbe bisogno per verificare che funzionasse correttamente. Userei quell'analisi iniziale per assumere una base di tester, e poi aggiungerei tester in seguito se il carico di lavoro si rivelasse troppo elevato per la mia base iniziale.

Se stai mettendo insieme un budget e assumendo i tester in un secondo momento non è un'opzione, potresti voler budget in risorse di test leggermente più di quanto indicato dalla tua analisi. Troppo è sempre meglio che non abbastanza.

Se usare " puro " i tester sono un'altra domanda che dipende davvero da quante risorse di test sono necessarie. Ho scoperto che un buon compromesso è assumere tester in grado di svolgere altri lavori e utilizzarli in altre capacità nei momenti in cui il carico di prova è leggero.

Modifica: Se sei abbastanza fortunato da avere una serie di test di accettazione all'inizio, sostituisci "test di accettazione"; per "elenco dei requisiti" sopra. : -)

Answer 7

Non esiste un "buono" generalizzato il rapporto.

Chiaramente, il tempo necessario per testare qualcosa è contestuale - dipende da fattori che potrebbero avere poco o niente a che fare con il tempo impiegato per sviluppare quella funzione.

Considera anche:

• cosa conta come Sviluppo?
• cosa conta come Test?
• Se avessimo comunque eseguito i test di regressione, conta come "zero"? ore di test aggiuntive?

vedi: http://www.sqablogs.com/jstrazzere/150/What+is+the+%22Correct%22+Ratio+of+Development+Time+to+Test+Time%3F.html

Answer 8

Direi (a seconda della velocità con cui hai bisogno di cose testate) con l'automazione potresti avere 1 o 2 tester per ogni 5 sviluppatori.

Perché:

• Con l'automazione devono solo preoccuparsi di testare i nuovi moduli
• I test di regressione si prenderanno cura di quelli più vecchi.
• 1 o 2 tester possono facilmente coprire tutto il lavoro che 5 sviluppatori faranno ad esempio settimana / settimana
• Un buon rapporto che mi è stato insegnato è stato che per ogni 10 ore di sviluppo, il team di controllo della qualità impiegherà circa 3 o 4 ore per rintracciare la maggior parte dei difetti generati da quelle 10 ore.

Spero che possa aiutare :)

Answer 9

  

Inoltre, useresti tester "puri" o   combineresti test con altri   ruoli (ad es. documentazione, utente   formazione, ecc.)?

Dipende dal tipo di test, ma non caricerei i tester con altri ruoli. Gli ingegneri di prova competenti valgono il loro peso in oro (lo stesso degli ingegneri del software competenti). Se assegni loro compiti al di fuori del loro dominio di competenza, li rallenterai e li eliminerai. Agli ingegneri del software piace fare documentazione o formazione degli utenti? Di solito no. Neanche i tester.

Tuttavia, non c'è nulla di sbagliato nell'integrare il team di test con persone di altre aree, in particolare per test di usabilità, test di accettazione, revisioni rapide, ecc.

Answer 10

Una cosa è certa. Il numero di tester dovrebbe essere maggiore del numero di sviluppatori. Per ogni funzione creata da uno sviluppatore, un tester deve esercitare la funzione con vari tipi di test: funzionalità, usabilità, limiti, stress, ecc. Sebbene il rapporto esatto dipenderà maggiormente dal numero di casi di test e dalla durata di un ciclo di test essere (1 settimana, 3 giorni, 1 giorno o mezza giornata), un singolo sviluppatore genererà abbastanza attività di test per più tester. Inoltre, potrebbero esserci scenari che richiedono a più tester di simulare due o più utenti che lavorano contemporaneamente sul sistema.