Includere i tester all'interno del team o creare un'area di test? [chiuso]

We could hire less testers / We have to hire more people

Questo è un equivoco. La quantità totale di attività di test è ancora la stessa in entrambi gli scenari. E se nello scenario due un tester dedicato a un prodotto dovesse funzionare "senza lavoro" perché non c'è abbastanza da testare per dargli 8 ore di lavoro al giorno, probabilmente lo assegni a testare il lavoro da un prodotto diverso sia (almeno, temporaneamente).

We have no bottleneck cause each Tester is allocated to a specific product

Come sopra: puoi ancora ottenere un collo di bottiglia perché ci potrebbero essere troppe cose da testare in un unico prodotto per far sì che una sola persona soddisfi il tuo programma.

Ciò che dovresti invece chiedere a te stesso sono: i diversi prodotti sono per lo più indipendenti l'uno dall'altro in modo che possano essere testati individualmente? E i diversi prodotti hanno bisogno di conoscenze molto specifiche per testarli bene (il che significa che i tester devono specializzarsi per ciascun prodotto)? Quindi ha senso assegnare a ciascun prodotto uno o più tester come "esperti" per questo prodotto.

D'altro canto, se i diversi prodotti sono solo parti di un sistema applicativo, con una strong interazione tra di loro, quindi assegnare persone diverse rigorosamente a prodotti diversi non ha molto senso ( osservazione: che potrebbe non solo essere vero per i tuoi tester, ma anche per i tuoi sviluppatori ). E anche se non lo fosse, se i prodotti non hanno bisogno di conoscenze specifiche degli utenti, chiunque disponga di un piano di test può iniziare subito a testare la cosa, l'opzione di spostare i tester tra i prodotti rende il tuo team più flessibile e aiuta a evitare i colli di bottiglia.

Spostare le persone tra i diversi team, tuttavia, comporta sempre più costi di comunicazione e organizzativi - quando una squadra può lavorare completamente da sola, potrebbe essere molto più efficiente di quando alcuni di loro devono lavorare su diversi cose in parallelo. Dovrai decidere da solo cosa funziona meglio nel tuo caso.

Se stai effettivamente facendo mischia, piuttosto che qualcosa con alcuni principi Agile che stai chiamando scrum, allora è facile perché ci sono solo tre ruoli in scrum: il proprietario del prodotto, lo scrum master e il team di sviluppo. Non puoi avere un "team di test" separato perché una funzione non è finita finché non è stata testata, quindi la funzione di test ha di far parte del team di Scrum specifico.

Se in realtà non stai facendo mischia, allora fai tutto ciò che è meglio per te. In realtà non capisco come stai facendo lo sviluppo del prodotto senza alcuni tester, ma questo è un altro problema.

Penso che dipenda da ciò che vuoi che facciano i tuoi tester. In alcuni casi un tester è uno sviluppatore, un'unità di scrittura e altri test automatici. In alcuni casi sono tester manuali che scrivono e / o eseguono script di test. In alcuni casi sono ingegneri addetti all'implementazione che verificano che la consegna del prodotto soddisfi i requisiti effettivamente richiesti.

In questi casi è necessaria una diversa distribuzione di tester. Nel dev-tester, deve essere parte del team di sviluppo con conoscenza dei cambiamenti di sviluppo. Nel tester dei requisiti deve essere parte del team del prodotto con conoscenza della consegna del prodotto.

Il QA è un altro aspetto interessante: in questo caso è più un team di distribuzione / produzione che è molto disconnessa dal processo di sviluppo. (cioè si rilascia loro il prodotto finale a pellicola termoretraibile che, se passata, sarà dato alla produzione).

Quindi - come con così tante cose - un po 'di mix è appropriato. Ho scoperto che un tester per team funziona molto bene poiché ha bisogno della conoscenza del prodotto su cui sta lavorando il team per aiutarlo a testarlo in modo efficiente. Ma i tester che sono assegnati al prodotto sono anche molto importanti in quanto sono quelli che tendono a conoscere tutta la cronologia sociale, di configurazione e dei clienti del prodotto che spesso si perde tra gli sviluppi.

Raccomando vivamente di far parte dei tester parte dei team di sviluppo piuttosto che una funzione separata. Questo è per tre motivi principali, basati sulla mia esperienza nella gestione di squadre organizzate in entrambi i modi.

1. I test possono essere eseguiti come parte dello sprint (si dice che stai facendo Scrum), ovvero una definizione più completa di Done per le tue squadre e meno possibilità di rilavorazioni lungo la linea.
2. I tester possono lavorare più a stretto contatto con il team di sviluppo che può effettivamente ridurre la quantità di test da eseguire. Ciò può essere dovuto al fatto che un tester e uno sviluppatore si associano per testare e correggere qualcosa in parallelo. Oppure, i tester sono coinvolti nella pianificazione in modo da poter guidare gli sviluppatori sui casi limite che dovrebbero prendere in considerazione. Infine, i tester che fanno parte della pianificazione e lavorano a stretto contatto con lo sviluppatore consentono loro di capire con maggiore facilità cosa ha bisogno e non ha bisogno di ripetere i test dopo ogni modifica.
3. Infine, mantieni un buon focus sul team piuttosto che su tutti noi rispetto a quelli che si sentono tra i team di sviluppo e il team di test. Non è garantito che ciò avvenga con l'altro set-up, ma avere i team divisi in questo modo può prestarsi a tale comportamento.

Nella mia esperienza, la verifica di una funzione richiede di solito più tempo rispetto allo sviluppo di quella funzione. Quindi, se hai ruoli di test puri avrai bisogno di più tester rispetto agli sviluppatori.

Tuttavia, questo può variare notevolmente a seconda della quantità di automazione del test che hai installato e di quanto specifici sono i tuoi requisiti. Allo stesso modo, se hai specifiche molto ristrette, la quantità di conoscenza specifica del prodotto necessaria per testare una funzionalità è inferiore, puoi testarla solo dalla descrizione. Considerando che con una specifica più flessibile ti aspetteresti che il tester utilizzi le conoscenze specifiche del prodotto per colmare le lacune. cioè 'ahh ma quando l'app è in stato X la funzionalità fallisce'

Dato che sei preoccupato per risorse e colli di bottiglia ti suggerirei di modificare il tuo processo di scrum per includere alcuni dei concetti di KANBAN.

Qui si assegna un volume a ciascuna fase di sviluppo e si sposta solo un'attività nella fase successiva quando è disponibile la capacità. Questo rende molto chiaro dove sono i colli di bottiglia nel processo e ti dà un'idea approssimativa di quanta più risorse hai bisogno di assegnare a quell'area per eliminarle.