Fattibilità di un team di sviluppo senza * ruolo * dedicato * del tester [chiuso]

Ultimamente ho pensato molto a come costruire un team di sviluppo snello. Alla fine, vorrei aprire la mia piccola software house con un piccolo numero di persone affini. L'obiettivo non sarà diventare ricchi, ma piuttosto avere un ambiente di lavoro sano.

Finora, sto definendo una squadra magra come la seguente:

• Piccolo;
• Auto-organizzazione;
• Tutti i membri devono avere in mente il QA;
• I membri devono essere in grado di svolgere più ruoli

L'ultimo punto è dove sono un po 'preoccupato perché, come dice il mantra ...

Gli sviluppatori fanno i tester male.

Anche se capisco che, spesso, gli sviluppatori sono "troppo vicini" al loro codice o al codice del loro collega per effettuare valutazioni di livello superiore della qualità, non sono convinto che siano di fatto dei tester difettosi. Al contrario, sono dell'opinione che le qualità di un buon sviluppatore si sovrappongano molto con le qualità di un buon tester.

Supponendo che questo sia corretto, ho pensato a diversi modi per aggirare il problema dev / tester e credo di aver escogitato un modello praticabile.

Il mio modello richiede:

• Una piccola software house con oltre 2 progetti
• Un approccio agile (iterativo) allo sviluppo e alla consegna
• 1 squadra per progetto
• Tutti i membri del team saranno sviluppatori di software
  • La loro descrizione del lavoro indicherà chiaramente lo sviluppo , l' assicurazione della qualità , i test e la consegna come responsabilità

Se tutte queste condizioni sono state soddisfatte, i progetti possono essere organizzati nel modo seguente (questo esempio farà riferimento a due progetti, A e B ):

• Ogni membro del team si alternerà tra il ruolo di sviluppatore e il ruolo di tester
• Se un membro del team è uno sviluppatore nel progetto A , sarà un tester nel progetto B
  • I membri lavoreranno solo 1 progetto alla volta, e quindi si prevede di agire come sia un Dev o di un tester.
• Un ciclo di ruoli è composto da 3 iterazioni come Dev e 2 iterazioni come Tester (di nuovo, su due diversi progetti)
• I team di progetto avrebbero sempre 3 sviluppatori e 2 tester.
• I cicli di ruolo dei membri devono essere sfasati di 1 iterazione.
  • Ciò riduce al minimo la brusca variazione delle squadre. Per ogni iterazione, 2 Dev e 1 Tester rimarranno gli stessi dell'iterazione precedente.

Considerato quanto sopra, vedo i seguenti pro e contro:

Professionisti

• Distribuisce la conoscenza del progetto in tutta l'azienda.
• Assicura che i membri del team non stiano testando il codice che hanno aiutato a scrivere.
• Cicli di ruolo fuori fase indicano che nessun progetto ha mai uno switch membro al 100%.
• Ruoli alternati spezzano la monotonia di progetti noiosi.

Contro

• Le iterazioni di entrambi i progetti sono strettamente collegate. Se un progetto dovesse annullare una iterazione a metà strada e ricominciare, i due progetti sarebbero fuori sincrono. Ciò renderebbe difficile la gestione del ciclo di ruoli.
• Cerniere sull'assunzione Gli sviluppatori iniziano a lavorare anche come tester.

Ho ricevuto recensioni contrastanti quando ho discusso di questo approccio con amici e colleghi. Alcuni credono che pochi sviluppatori vorrebbero mai alternare ruoli come questo, mentre altri mi dicono che personalmente adorerebbero provarlo.

Quindi la mia domanda è: un tale modello potrebbe funzionare nella pratica? In caso contrario, potrebbe essere modificato in un modello funzionante?

Nota: per brevità mi sono concentrato solo sui ruoli Dev e Tester. Espanderò su altri ruoli se necessario.

Non sono d'accordo

Gli sviluppatori fanno i tester male

La maggior parte dei team su cui ho lavorato nella mia carriera non ha ricevuto alcun supporto per il controllo qualità. Ciò include un paio di grandi società globali che coinvolgono prodotti come il loro sistema di accesso e registrazione globale. In un altro caso, ho avuto il 30% delle entrate dell'azienda attraverso una scatola sulla mia scrivania. (Queste pratiche non sono consigliate BTW;)) Queste aziende si affidavano agli ingegneri per assicurarsi che il loro codice funzionasse correttamente. E noi, essendo orientati ai dettagli, un po 'compulsivi e orgogliosi del nostro lavoro, faremo di tutto per assicurarci che il nostro software funzioni correttamente.

Inoltre, come sviluppatore, eseguo molti più test rispetto ai tester. Di solito collaudo il mio codice al 90%, o al 100% se non lavoro con Java.

Mi piace lavorare con i tester perché provengono da una prospettiva diversa e catturano cose a cui non ho pensato. Ma in realtà non conto su di loro per fornire una copertura di test superiore al 30-50%, mentre mi ritengo responsabile per il 100%. (A proposito, non è uno schianto su di loro - di solito sono sparsi tra i progetti.)

Invece di chiedere agli ingegneri nelle interviste se vogliono fare il QA, chiedi: se un bug si presenta in produzione, chi è il responsabile? Se introduco un bug e un cliente lo sperimenta, mi sento male e mi assumo la responsabilità. Non incolpo i ragazzi del QA. IMHO Questo è il tipo di ingegnere che vuoi assumere (e lavorare con)

Il mio metodo per garantire la qualità è a) test di unità super aggressivi (anche se non riesco proprio a farmi fare il pieno sviluppo basato su test), b) un forte processo di revisione del codice aiuta davvero ec) l'integrazione di un'intolleranza e l'impazienza con difetti nella cultura del team.

Mi ha sempre colpito il fatto che i ragazzi più anziani erano quelli che erano i più abili e attenti a problemi anche minori, perché potevano indicare un problema più grande. Ma soprattutto erano quelli più disposti a passare il tempo per farlo bene.

Ma la maggior parte dei team su cui ho lavorato, specialmente per le piccole aziende, non ha avuto un componente formale di controllo qualità.

Sono d'accordo con la risposta di @Rob Y e vorrei aggiungere alcuni punti:

• In termini di agilità, i tester dedicati all'interno di un team sono un anti-modello, perché costringono i team a lavorare sulla pipeline ed essere intrinsecamente inefficienti. Finisci costantemente con storie che sono "sviluppate" ma non testate. I tester dedicati vanno bene se lavorano al di fuori della squadra (o di una squadra separata).

• Gli sviluppatori fanno cattivi tester ... e i tester fanno cattivi tester. Il QA è difficile. In effetti, è molto difficile. Il tuo problema potrebbe non essere costituito da persone e ruoli. Il tuo problema potrebbe essere che il tuo software è precipitato. Ancora una volta, in agile, è responsabilità del tuo team testare prima della produzione (indipendentemente dal fatto che abbiano o meno un QA dedicato).

• Il controllo qualità fa parte dello sviluppo, come refactoring, architettura, ecc. È responsabilità di un team di sviluppo produrre software secondo un certo standard concordato e realistico. I QA non miglioreranno tale standard. Gli sviluppatori migliori probabilmente lo faranno.

• Provocazione: chi afferma che i QA sono migliori degli sviluppatori di QA-ing? È qualcosa che la gente dice ma ... [citazione necessaria]. La necessaria mentalità "hacker" del QA è una mentalità per sviluppatori. In effetti, praticamente tutti gli hacker sono o erano sviluppatori, non QA ...

• Provocazione 2: il 99% del lavoro di controllo qualità può essere (e, oserei dire, dovrebbe essere ) automatizzato tramite script. Una buona squadra lo farà, e per farlo correttamente hai bisogno di ... sviluppatori.

In un precedente lavoro, avevamo solo sviluppatori e nessuno staff addetto al controllo qualità. Di conseguenza non c'era nessun altro da incolpare se un problema è arrivato alla produzione. Abbiamo preso molto sul serio le nostre responsabilità di controllo qualità e abbiamo fatto affidamento su suite di test automatizzate. Dato che scrivere test automatici è ancora in codice, non è stato un grosso problema convincere gli sviluppatori a farlo.

L'importante è renderlo parte della cultura del team e parte di ogni progetto. Abbiamo redatto piani di test (solo brevi elenchi di test che intendevamo scrivere per un progetto) e altri sviluppatori avrebbero esaminato e suggerito casi e scenari che ci eravamo persi.

Se sei rigoroso, può funzionare molto bene. Ha funzionato per noi: abbiamo avuto tempi di attività eccellenti e bassi difetti in un servizio web di e-commerce sempre attivo.

Innanzitutto un avvertimento: ho lavorato professionalmente sia come ingegnere di qualità che come ingegnere del software.

Un tale modello potrebbe funzionare nella pratica?

Tutto è possibile.

Anche se capisco che, spesso, gli sviluppatori sono "troppo vicini" al loro codice o al codice del loro collega per effettuare valutazioni di livello più elevato della qualità, non sono convinto che siano di fatto dei tester difettosi. Al contrario, sono dell'opinione che le qualità di un buon sviluppatore si sovrappongano molto con le qualità di un buon tester.

Dipende dal tipo di test necessario. Se hai bisogno di test manuali paralizzanti, monotoni e ripetitivi per assicurarti che ogni singolo schermo o elemento sia stato davvero tradotto in elboniano ... avrai dei problemi.

E nella mia esperienza, ogni progetto richiede almeno un po 'di questo tipo di test (anche se non tutti i progetti hanno fatto quel tipo di test). Il problema è che non si ottiene questo tipo di test da persone che non hanno familiarità con le migliori pratiche di QA. Cavolo, non lo capisci nemmeno da persone che conoscono le migliori pratiche, ma "fidati" degli sviluppatori.

Come tester, non puoi fidarti degli sviluppatori. Ho perso il conto dei bug che ho scoperto che "non poteva essere stato causato da quel cambiamento" o "funziona perfettamente sulla mia scatola di sviluppo".

Anche se riesci a trovare sviluppatori in grado di tollerare di non fare ciò che amano fare 2 settimane su 5, incontrerai anche questa contraddizione fondamentale. Peggio ancora, stai spendendo tempo ed energia per addestrare le persone ad essere brave in due lavori anziché in uno. Le aziende hanno difficoltà a trovare e formare le persone brave in un unico lavoro, figuriamoci due.

Forse sei fantastico in qualche modo che non ho ancora incontrato - ma ne dubito.

Penso che potrebbe funzionare, ma ci sono un paio di cose che mi assicurerei di fare.

1. Sii molto sincero sui doppi ruoli per i candidati. Non è per tutti per molte ragioni. Se hai troppe persone a cui non piace, avrai fallimenti e turnover.
2. Prepara un piano in cui è possibile valutare il modo migliore per incorporarlo nel team. Anche se mi piace concentrarmi su un compito / progetto alla volta, non sono sicuro che non vorrei programmare per un periodo di tempo molto lungo. Forse i test sono una bella vacanza lontano dalla programmazione. Non che sia più semplice, basta usare alcune cellule cerebrali diverse per cambiare. Preparati a provarlo in diversi modi prima di decidere cosa è meglio.

La sincronizzazione dei progetti non sembra una soluzione pratica. Se qualcuno è un testatore di un progetto, potrebbe essere il miglior candidato per sostituire un programmatore e viceversa.

Questo piano non consente ai team di auto-organizzarsi abbastanza. Una strategia probabilmente non si adatta a tutti i team e tutti i progetti.