Viabilità di un team di sviluppo senza ruolo * dedicato * Tester [chiuso]

Non sono d'accordo con

Developers make bad testers

La maggior parte delle squadre a cui ho lavorato nella mia carriera non hanno avuto alcun supporto QA. Questo 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 della società attraverso una scatola sulla mia scrivania. (Queste pratiche non sono consigliate a BTW;)) Queste società dipendevano dagli ingegneri per assicurarsi che il loro codice funzionasse correttamente. E noi, essendo orientati ai dettagli, un po 'compulsivi e orgogliosi del nostro lavoro, faremmo di tutto per assicurarci che il nostro software funzionasse correttamente.

Inoltre, come sviluppatore faccio molto più test rispetto ai tester. Io collaudo abitualmente il mio codice al 90%, o al 100% se non sto lavorando con Java.

Mi piace lavorare con i tester perché ci arrivano da una prospettiva diversa e catturano cose a cui non pensavo. Ma davvero non conto su di loro per fornire più di una copertura di prova del 30-50%, mentre sono responsabile del 100%. (BTW Questo non è uno schianto su di loro - di solito sono diffusi attraverso i progetti.)

Piuttosto che chiedere agli ingegneri nelle interviste se vogliono fare 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 prendo la responsabilità. Non biasimo 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 a portare a pieno il Devilopment guidato dai test), b) un strong processo di revisione del codice aiuta davvero e c) integrare un intolleranza di e impazienza con i difetti nella cultura della squadra.

Mi è sempre sembrato che i ragazzi più anziani fossero quelli che erano più dilligenti e attenti anche a problemi minori, perché potevano indicare un problema più grande. Ma principalmente erano quelli più disposti a passare il tempo per farlo bene.

Ma la maggior parte delle squadre su cui ho lavorato, in particolare per le piccole imprese, non ha mai avuto un componente formale di controllo qualità.

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

• In agili, i tester dedicati all'interno di un team sono un anti-modello, perché costringono i team a lavorare in pipeline e ad essere intrinsecamente inefficienti. Finisci costantemente con storie che sono "sviluppate" ma non testate. I tester dedicati vanno bene se lavorano fuori dal team (o da un team separato).

• Dev fanno diventare dei cattivi tester ... e i tester fanno i cattivi tester. Il controllo qualità è difficile. In effetti, è molto difficile. Il tuo problema potrebbe non essere persone e ruoli. Il tuo problema potrebbe essere che il tuo software si è esaurito. Ancora una volta, in agile, è responsabilità della tua squadra testare prima della produzione (se hanno o meno un QA dedicato).

• Il QA fa parte dello sviluppo, come il refactoring, l'architettura, ecc. È responsabilità di un team di sviluppo produrre un software secondo uno standard certo, concordato e realistico. Il QA non migliorerà questo standard. Probabilmente lo faranno gli sviluppatori migliori.

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

• Provocazione 2: il 99% del lavoro di QA può essere (e, oserei dire, dovrebbe essere ) automatizzato tramite script. Un buon team lo farà, e per farlo correttamente occorrono ... sviluppatori.

In un precedente lavoro, avevamo solo sviluppatori e nessun personale addetto al controllo qualità. Di conseguenza non c'era nessun altro da incolpare se un problema arrivasse alla produzione. Abbiamo preso molto sul serio le nostre responsabilità in termini di garanzia della qualità e ci siamo basati molto sulle suite di test automatizzate. Poiché scrivere test automatici è ancora in codice, non è stato un grosso problema convincere gli sviluppatori a farlo.

L'importante è farne parte della cultura del team e parte di ogni progetto. Abbiamo scritto 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. Lo ha fatto per noi: abbiamo avuto tempi di attività eccellenti e difetti bassi in un servizio web di e-commerce sempre attivo.

In primo luogo un avvertimento - Ho lavorato professionalmente sia come ingegnere del software di qualità che come ingegnere del software.

Could such a model work in practice?

Tutto è possibile.

While I understand that, often, developers are "too close" to their code or their colleague's code to make higher-level assessments of quality, I'm not convinced they are de-facto bad testers. On the contrary, I'm of the opinion that the qualities of a good developer overlap greatly with the qualities of a good tester.

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

E nella mia esperienza, il progetto ogni richiede almeno un po 'di questo tipo di test (anche se non tutti i progetti di quel tipo di test sono stati eseguiti). Il problema è che non si ottiene questo tipo di test da persone che non hanno familiarità con le migliori pratiche di QA. Diavolo, 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 trovato che "non poteva essere stato causato da quel cambiamento" o "funziona perfettamente bene sulla mia casella di sviluppo ".

Anche se riesci a trovare sviluppatori che possano tollerare non fare ciò che amano fare 2 settimane su 5, ti imbatterai anche in questa contraddizione fondamentale. Peggio ancora, stai spendendo tempo ed energia per addestrare le persone ad essere brave in due lavori piuttosto che in uno. Le aziende hanno abbastanza tempo per trovare e formare persone brave in un singolo 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 farei sicuramente.

1. Siate molto in anticipo sul duplice ruolo dei candidati. Non è per tutti per molte ragioni. Se hai troppe persone a cui non piace, avrai un fallimento e un turnover.
2. Avere un piano in cui è possibile valutare il modo migliore per incorporare questo con il team. Anche se mi piace concentrarmi su un compito / progetto alla volta, non sono sicuro che vorrei non programmare per un periodo di tempo molto lungo. Forse il test è una bella vacanza lontano dalla programmazione. Non che sia più facile, basta usare alcune cellule cerebrali diverse per cambiare. Preparati a provarlo in modi diversi prima di decidere cosa è meglio.

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

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