Come fare in modo che i programmatori junior scrivano i test? [chiuso]

Abbiamo un programmatore junior che semplicemente non scrive abbastanza test.
Devo tormentarlo ogni due ore, "hai scritto delle prove?"
Abbiamo provato:

• Dimostrando che il design diventa più semplice
• Mostrarlo previene i difetti
• Rendendolo una cosa dell'ego che solo i cattivi programmatori non lo fanno
• Questo fine settimana 2 membri del team sono dovuti venire a lavorare perché il suo codice aveva un riferimento NULL e non l'ha testato

Il mio lavoro richiede un codice stabile di alta qualità e di solito tutti "lo ottengono" e non è necessario eseguire i test. Sappiamo che possiamo fargli scrivere test, ma sappiamo tutti che i test utili sono quelli scritti quando ci sei dentro.

Conosci altre motivazioni?

Questa è una delle cose più difficili da fare. Far sì che la tua gente lo ottenga .

A volte uno dei modi migliori per aiutare i programmatori di livello junior a "capirlo" e ad apprendere le tecniche giuste dagli anziani è fare un po 'di programmazione in coppia.

Prova questo: su un progetto imminente, accoppia il ragazzo junior a te stesso o a un altro programmatore senior. Dovrebbero lavorare insieme, alternandosi "guida" (essendo quello che digita sulla tastiera) e "coaching" (guardando alle spalle del conducente e indicando suggerimenti, errori, ecc.). Può sembrare uno spreco di risorse, ma troverai:

1. Che questi ragazzi insieme possano produrre codice molto velocemente e di qualità superiore.
2. Se il tuo ragazzo più giovane impara abbastanza per "ottenerlo" con un ragazzo anziano che lo guida lungo la strada giusta (es. "Ok, ora prima di continuare, scriviamo al test per questa funzione"). impegnarsi in esso.

Forse anche qualcuno nel tuo gruppo fa la presentazione di Unit Testing 101 di Kate Rhodes, penso che sia un ottimo modo per entusiasmare le persone al test, se consegnato bene.

Un'altra cosa che puoi fare è far provare ai tuoi Jr. Devs il Bowling Game Kata che li aiuterà ad imparare lo sviluppo basato sui test. È in java, ma può essere facilmente adattato a qualsiasi lingua.

Fai una revisione del codice prima di ogni commit (anche se è un minuto "Ho cambiato il nome di questa variabile"), e come parte della revisione del codice, rivedi eventuali unit test.

Non firmare il commit finché i test non sono a posto.

(Inoltre, se il suo lavoro non è stato testato, perché era in una build di produzione in primo luogo? Se non è testato, non lasciarlo entrare, quindi non dovrai lavorare nei fine settimana)

Per quanto mi riguarda, ho iniziato a insistere sul fatto che ogni bug che trovo e risolvo sia espresso come un test:

1. "Hmmm, non è giusto ..."
2. Trova un possibile problema
3. Scrivi un test, mostra che il codice fallisce
4. Risolvi il problema
5. Mostra che il nuovo codice passa
6. Esegui il loop se il problema originale persiste

Cerco di farlo anche mentre sbatto qualcosa, e ci riesco più o meno nello stesso tempo, solo con una suite di test parziale già installata.

(Non vivo in un ambiente di programmazione commerciale e spesso sono l'unico programmatore a lavorare su un particolare progetto.)

Immagina che io sia un finto programmatore, di nome ... Marco. Immagina di essermi diplomato a scuola non molto tempo fa e di non dover mai scrivere dei test. Immagina di lavorare in un'azienda che non lo impone o lo richiede. ok? bene! Ora immagina che l'azienda stia passando all'utilizzo dei test e che stiano cercando di mettermi in linea con questo. Darò una reazione un po 'irriverente agli elementi menzionati finora, come se non avessi fatto alcuna ricerca su questo.

Cominciamo con il creatore:

Dimostrando che il design diventa più semplice.

Come può scrivere di più, rendere le cose più semplici. Ora dovrei tenere d'occhio la possibilità di ricevere più casi, ecc. Questo rende più complicato se me lo chiedi. Dammi dettagli concreti.

Mostrarlo previene i difetti.

Lo so. Questo è il motivo per cui vengono chiamati test. Il mio codice è buono e ho verificato che non ci fossero problemi, quindi non vedo dove questi test potrebbero aiutare.

Rendendolo una cosa dell'ego che solo i cattivi programmatori non lo fanno.

Ohh, quindi pensi che io sia un pessimo programmatore solo perché non faccio molti test usati. Sono insultato e positivamente infastidito da te. Preferirei avere assistenza e supporto piuttosto che detti.

@ Justin Standard : All'inizio di un nuovo progetto, accoppia il ragazzo junior con te stesso o con un altro programmatore senior.

Ohh, questo è così importante che le risorse saranno spese per assicurarmi di vedere come vengono fatte le cose e avere qualche aiuto su come le cose sono fatte. Questo è utile e potrei iniziare a farlo di più.

@ Justin Standard : Leggi la presentazione di Unit Testing 101 di Kate Rhodes.

Ahh, quella è stata una presentazione interessante e mi ha fatto pensare ai test. Ha martellato alcuni punti che dovrei considerare e potrebbe aver influenzato un po 'le mie opinioni.

Mi piacerebbe vedere articoli più interessanti e altri strumenti che mi aiutino ad essere in linea con il pensiero che questo sia il modo giusto di fare le cose.

@ Dominic Cooney : dedica del tempo e condividi le tecniche di test.

Ahh, questo mi aiuta a capire cosa ci si aspetta da me per quanto riguarda le tecniche, e mette più oggetti nel mio bagaglio di conoscenze, che potrei usare di nuovo.

@ Dominic Cooney : Rispondi a domande, esempi e libri.

Avere una persona di riferimento (persone) per rispondere alla domanda è utile, potrebbe rendermi più propenso a provare. I buoni esempi sono ottimi e mi danno qualcosa a cui mirare e qualcosa a cui cercare riferimento. I libri che sono direttamente pertinenti a questo sono un ottimo riferimento.

@ Adam Hayle : recensione a sorpresa.

Dì cosa, hai saltato qualcosa per cui sono completamente impreparato. Mi sento a disagio con questo, ma farò del mio meglio. Ora sarò spaventato e un po 'apprensivo di nuovo, grazie. Tuttavia, la tattica spaventosa potrebbe aver funzionato, ma ha un costo. Tuttavia, se nient'altro funziona, questa potrebbe essere solo la spinta necessaria.

@ Rytmis : gli elementi sono considerati completati solo quando hanno casi di test.

Ohh, interessante. Vedo che devo farlo davvero adesso, altrimenti non sto completando nulla. Questo ha senso.

@ jmorris : Get Rid / Sacrifice.

bagliori, bagliori, bagliori - C'è una possibilità che io possa imparare e, con il supporto e l'assistenza, posso diventare una parte molto importante e funzionale dei team. Questo è uno dei miei handicap ora, ma non durerà a lungo. Tuttavia, se non lo capisco, capisco che andrò. Penso che lo otterrò.

Alla fine, il supporto della mia squadra gioca un ruolo importante in tutto questo. Avere una persona che si prende il suo tempo per assistere e farmi iniziare a prendere buone abitudini è sempre il benvenuto. Quindi, in seguito, avere una buona rete di supporto sarebbe fantastico. Sarebbe sempre apprezzato avere qualcuno che viene qualche volta dopo, e ripassa un po 'di codice, per vedere come scorre tutto, non in una recensione in sé, ma più come una visita amichevole.

Ragionamento, preparazione, insegnamento, follow-up, sostegno.

Ho notato che molti programmatori vedono il valore del testing a livello razionale. Se hai sentito cose come "sì, so che dovrei testarlo ma ho davvero bisogno di farlo rapidamente", allora sai cosa intendo. Tuttavia, a livello emotivo sentono di ottenere qualcosa solo quando stanno scrivendo il vero codice.

L'obiettivo, quindi, dovrebbe essere quello di far capire in qualche modo che il test è in realtà l' unico modo per misurare quando qualcosa è "fatto", e quindi dare loro la motivazione intrinseca per scrivere test.

Temo che sia molto più difficile di quanto dovrebbe essere, però. Sentirai molte scuse del tipo "Ho molta fretta, lo riscriverò / rifattorizzerò più tardi e poi aggiungerò i test" - e, naturalmente, il follow-up non avviene mai perché, sorprendentemente, sei altrettanto impegnato la prossima settimana .

Ecco cosa farei:

• Prima volta ... "Faremo questo progetto insieme. Scriverò i test e tu scriverà il codice. Presta attenzione a come scrivo i test, perché è così che facciamo le cose da queste parti ed è quello che mi aspetto da te. "

• Dopodiché ... "Hai finito? Ottimo! Per prima cosa diamo un'occhiata ai test che stanno guidando il tuo sviluppo. Oh, nessun test? Fammi sapere quando sarà finito e riprogrammeremo guardando il tuo codice. Se tu ' hai bisogno di aiuto per formulare i test fammelo sapere e ti aiuterò. "

Lo sta già facendo. Veramente. Semplicemente non lo scrive. Non convinto? Guardalo mentre segue il ciclo di sviluppo standard:

• Scrivi un pezzo di codice
• Compilalo
• Corri a vedere cosa fa
• Scrivi il prossimo pezzo di codice

Il passaggio 3 è il test. Fa già dei test, lo fa solo manualmente. Fagli questa domanda: "Come fai a sapere domani che il codice di oggi funziona ancora?" Risponderà: "È una piccola quantità di codice!"

Chiedi: "Che ne dici della prossima settimana?"

Quando non ha una risposta, chiedi: "Come vorresti che il tuo programma ti dicesse quando un cambiamento interrompe qualcosa che ha funzionato ieri?"

Questo è ciò che riguarda il test automatico delle unità.

Come programmatore junior, sto ancora cercando di prendere l'abitudine di scrivere test. Ovviamente non è facile acquisire nuove abitudini, ma pensando a cosa potrebbe funzionare per me, devo fare +1 sui commenti sulle revisioni del codice e sul coaching / pair programming.

Può anche valere la pena sottolineare lo scopo a lungo termine del test: garantire che ciò che ha funzionato ieri funzioni ancora oggi, la prossima settimana e il mese prossimo. Lo dico solo perché sfogliando le risposte non l'ho visto menzionato.

Nel fare le revisioni del codice (se decidi di farlo), assicurati che il tuo giovane sviluppatore sappia che non si tratta di metterlo giù, ma di migliorare il codice. Perché in questo modo è meno probabile che la sua fiducia venga danneggiata. E questo è importante. D'altra parte, così è sapere quanto poco sai.

Ovviamente non so davvero niente. Ma spero che le parole siano state utili.

Modifica: [ Justin Standard ]

Non abbatterti, quello che hai da dire è praticamente giusto.

Sul tuo punto di vista sulle revisioni del codice: quello che troverai è che non solo lo sviluppatore junior imparerà nel processo, ma anche i revisori. Tutti in una revisione del codice apprendono se lo rendi un processo collaborativo.

Francamente, se devi mettere che tanto per convincerlo a fare qualcosa, potresti dover accettare il pensiero che potrebbe non essere adatto alla squadra e potrebbe dover andare. Ora, questo non significa necessariamente licenziarlo ... potrebbe significare trovare un altro posto in azienda le sue capacità sono più adatte. Ma se non c'è altro posto ... sai cosa fare.

Presumo che sia anche un neoassunto (<1 anno) e probabilmente da poco ha finito la scuola ... nel qual caso potrebbe non essere abituato a come funzionano le cose in un contesto aziendale. Cose del genere che la maggior parte di noi potrebbe sopportare al college.

Se questo è il caso, una cosa che ho trovato funziona è avere una sorta di "recensione a sorpresa di nuovi assunti". Non importa se non l'hai mai fatto prima ... non lo saprà. Mettilo a sedere e digli che ripasserai la sua performance e gli mostrerai alcuni numeri reali ... prendi il tuo normale foglio di revisione (hai un processo di revisione formale, giusto?) E cambia l'intestazione se lo desideri in modo che appaia ufficiale e mostragli dove si trova. Se gli mostri in un contesto molto formale che non fare i test sta influenzando negativamente la sua valutazione delle prestazioni invece di "tormentarlo", si spera che ottenga il punto. Devi dimostrargli che le sue azioni lo influenzeranno effettivamente, sia che sia saggio o meno.

Lo so, potresti voler stare lontano dal farlo perché non è ufficiale ... ma penso che tu abbia ragione per farlo e probabilmente sarà molto più economico che doverlo licenziare e reclutare qualcuno di nuovo.

Essendo io stesso un programmatore junior, pensavo che avrei rivelato com'era quando mi sono trovato in una situazione simile al tuo sviluppatore junior.

Quando sono uscito per la prima volta dall'università, ho scoperto che non ero molto attrezzato per affrontare il mondo reale. Sì, conoscevo alcune basi di JAVA e un po 'di filosofia (non chiedere) ma questo è tutto. Quando ho ottenuto il mio lavoro per la prima volta è stato un po 'scoraggiante per non dire altro. Lascia che ti dica che probabilmente ero uno dei più grandi cowboy in circolazione, avrei messo insieme una piccola correzione di bug / algoritmo senza commenti / test / documentazione e lo spedivo fuori dalla porta.

Ho avuto la fortuna di essere sotto la supervisione di un tipo e molto programmatore senior paziente. Fortunatamente per me, ha deciso di sedersi con me e passare 1-2 settimane a esaminare il mio codice togethor molto hackerato. Spiegava dove avevo sbagliato, i punti più fini di ce i puntatori (il ragazzo mi ha confuso!). Siamo riusciti a scrivere una classe / modulo abbastanza decente in circa una settimana. Tutto quello che posso dire è che se il senior dev non avesse investito il tempo per aiutarmi lungo la strada giusta, probabilmente non sarei durato molto a lungo.

Fortunatamente, a due anni di distanza, spero che alcuni dei miei colleghi possano persino considerarmi un programmatore medio.

Porta a casa punti

1. La maggior parte delle università non riesce a preparare gli studenti al mondo reale
2. La programmazione in coppia mi ha davvero aiutato. Questo non vuol dire che aiuterà tutti, ma ha funzionato per me.

Assegnali a progetti che non richiedono "codice stabile di alta qualità" se questo è il tuo problema e lascia che jr. lo sviluppatore fallisce. Invita loro a "entrare nel fine settimana" per correggere i loro bug. Pranza molto e parla delle pratiche di sviluppo del software (non lezioni, ma discussioni). Col tempo acquisiranno e svilupperanno le migliori pratiche per svolgere i compiti loro assegnati.

Chissà, potrebbero persino inventare qualcosa di meglio delle tecniche attualmente utilizzate dal tuo team.

Se il programmatore junior, o chiunque altro, non vede il valore nei test, sarà difficile convincerli a farlo ... punto.

Avrei costretto il programmatore junior a sacrificare il fine settimana per correggere il bug. Le sue azioni (o la mancanza di ciò) non lo influenzano direttamente. Inoltre, rendi evidente che non vedrà avanzamenti e / o aumenti salariali se non migliora le sue capacità nei test.

Alla fine, anche con tutto il tuo aiuto, incoraggiamento, mentoring, potrebbe non essere adatto alla tua squadra, quindi lascialo andare e cerca qualcuno che lo capisca.

Secondo il commento di RodeoClown sulla revisione del codice di ogni commit. Dopo averlo fatto un bel paio di volte, prenderà l'abitudine di testare le cose.

Non so se devi bloccare i commit in questo modo. Al mio posto di lavoro tutti si impegnano gratuitamente su tutto e tutti i messaggi di commit SVN (con differenze) vengono inviati via email al team.

Nota: vuoi davvero l' addon colorato-diff di thunderbird se hai intenzione di farlo.

Il mio capo o io (i 2 programmatori "senior") finiremo per leggere i commit, e se ci sono cose come "hai dimenticato di aggiungere unit test", facciamo semplicemente scorrere un'e-mail o andiamo a chattare con la persona, spiegandogli perché test unitari necessari o altro. Tutti gli altri sono incoraggiati a leggere anche i commit, poiché è un ottimo modo per vedere cosa sta succedendo, ma gli sviluppatori junior non commentano così tanto.

Puoi incoraggiare le persone a prendere l'abitudine dicendo periodicamente cose come "Ehi, Bob, hai visto quell'impegno che ho fatto stamattina, ho trovato questo bel trucco in cui puoi fare bla bla qualunque cosa, leggi il commit e guarda come funziona!"

NB: Abbiamo 2 sviluppatori "senior" e 3 sviluppatori junior. Potrebbe non essere scalabile o potrebbe essere necessario modificare leggermente il processo con più sviluppatori.

1. Rendi la copertura del codice parte delle revisioni.
2. Rendi "scrivi un test che esponga il bug" un prerequisito per correggere un bug.
3. Richiede un certo livello di copertura prima che il codice possa essere archiviato.
4. Trova un buon libro sullo sviluppo basato sui test e usalo per mostrare come il test-first può accelerare lo sviluppo.

Un sacco di psicologia e utili tecniche di "mentoring" ma, in tutta onestà, questo si riduce semplicemente a "scrivere test se vuoi avere ancora un lavoro, domani".

Puoi esprimerlo in qualunque termine pensi sia appropriato, duro o morbido, non importa. Ma il fatto è che i programmatori non sono pagati solo per mettere insieme il codice e registrarlo: sono pagati per mettere insieme il codice con cura, quindi mettere insieme i test, quindi testare il loro codice, POI controllare l'intera cosa. (Almeno questo è quello che sembra, dalla tua descrizione.)

Quindi, se qualcuno rifiuterà di fare il proprio lavoro, spiegagli che può restare a casa, domani, e assumerai qualcuno che lo farà.

Di nuovo, puoi fare tutto questo delicatamente, se pensi che sia necessario, ma molte persone hanno solo bisogno di uno schiaffo duro e duro di La vita nel mondo reale , e faresti loro un favore dandoglielo.

In bocca al lupo.

Cambia la descrizione del suo lavoro per un po 'di tempo per scrivere test e mantenerli. Ho sentito che molte aziende lo fanno per nuove persone inesperte da un po 'quando iniziano.

Inoltre, lancia una sfida mentre è in quel ruolo: scrivi test che a) falliscano sul codice corrente a) soddisfino i requisiti del software. Si spera che gli farà creare alcuni test solidi e approfonditi (migliorando il progetto) e lo renderà migliore nello scrivere i test per quando si reintegrerà nello sviluppo principale.

modifica> soddisfa i requisiti del software, il che significa che non sta solo scrivendo test per rompere intenzionalmente il codice quando il codice non ha mai voluto o necessario prendere in considerazione quel caso di test.

Se il tuo collega non ha esperienza nella scrittura di test, forse ha difficoltà a eseguire test al di là delle situazioni semplici e questo si manifesta come test inadeguati. Ecco cosa proverei:

• Dedica del tempo e condividi le tecniche di test, come l'inserimento di dipendenze, la ricerca di casi limite e così via con il tuo collega.
• Offriti di rispondere alle domande sui test.
• Esegui revisioni del codice dei test per un po '. Chiedi al tuo collega di rivedere i tuoi cambiamenti che sono esemplari di buoni test. Guarda i loro commenti per vedere se stanno davvero leggendo e comprendendo il tuo codice di prova.
• Se ci sono libri che si adattano particolarmente bene alla filosofia di test del tuo team, dagli una copia. Potrebbe essere utile se il tuo feedback sulla revisione del codice o le discussioni fanno riferimento al libro in modo che lui o lei abbia un thread da raccogliere e seguire.

Non sottolineerei particolarmente il fattore vergogna / colpa. Vale la pena sottolineare che il test è una buona pratica ampiamente adottata e che scrivere e mantenere buoni test è una cortesia professionale, quindi i tuoi compagni di squadra non hanno bisogno di trascorrere i fine settimana al lavoro, ma non vorrei dilungarmi su questi punti.

Se hai davvero bisogno di "diventare duro", istituisci un sistema imparziale; a nessuno piace sentirsi come se fossero scelti. Ad esempio, il tuo team potrebbe richiedere del codice per mantenere un certo livello di copertura dei test (in grado di essere giocato, ma almeno in grado di essere automatizzato); richiedere un nuovo codice per avere dei test; richiedere ai revisori di considerare la qualità dei test durante le revisioni del codice; e così via. L'istituzione di quel sistema dovrebbe venire dal consenso del team. Se moderi attentamente la discussione potresti scoprire altri motivi sottostanti che il test del tuo collega non è quello che ti aspetti.

È responsabilità del suo mentore insegnargli / le. Quanto bene gli stai insegnando COME fare il test. Stai programmando in coppia con lui? Lo Junior molto probabilmente non sa COME impostare un buon test per xyz.

Da giovane appena uscito dalla scuola conosce molti concetti. Qualche tecnica. Qualche esperienza. Ma alla fine, tutto un Junior è POTENZIALE. Quasi tutte le funzionalità su cui lavorano, ci sarà qualcosa di nuovo che non hanno mai fatto prima. Sicuramente il Junior potrebbe aver fatto un semplice schema statale per un progetto in classe, aprendo e chiudendo "porte", ma mai un'applicazione reale degli schemi.

Sarà bravo solo quanto bene insegni. Se fossero riusciti a "Prendilo e basta" pensi che avrebbero preso una posizione Junior in primo luogo?

Nella mia esperienza gli Junior vengono assunti e ricevono quasi le stesse responsabilità degli anziani, ma vengono semplicemente pagati di meno e poi ignorati quando iniziano a vacillare. Perdonami se sembro amareggiato, è perché lo sono.

@ jsmorris

Una volta ho chiesto allo sviluppatore senior e all '"architetto" di rimproverare me e un tester (era il mio primo lavoro dopo il college) via e-mail per non essere rimasto fino a tardi e aver terminato un compito così "facile" la sera prima. Ci siamo stati tutto il giorno e abbiamo chiuso alle 19:00, mi sono battuto dalle 11 del mattino prima di pranzo quel giorno e avevo tormentato ogni membro del nostro team per chiedere aiuto almeno due volte.

Ho risposto e ho chiesto al team: "Sono deluso da te da un mese ormai. Non ricevo mai aiuto dal team. Sarò al bar dall'altra parte della strada se hai bisogno di me. Sono scusa non sono riuscito a eseguire il debug del metodo a 12 parametri e 800 righe da cui dipende quasi tutto. "

Dopo essermi rinfrescato al bar per un'ora, sono tornato in ufficio, ho preso la mia merda e me ne sono andato. Dopo qualche giorno mi hanno chiamato chiedendomi se sarei entrato, ho detto che l'avrei fatto ma ho avuto un colloquio, forse domani.

"Quindi smetti allora?"

Sul tuo repository sorgente: usa gli hook prima di ogni commit (hook pre-commit per SVN per esempio)

In quell'hook, controlla l'esistenza di almeno un caso d'uso per ogni metodo. Usa una convenzione per l'organizzazione di unit test che potresti facilmente applicare tramite un hook pre-commit.

Su un server di integrazione compilare tutto e controllare regolarmente la copertura del test utilizzando uno strumento di copertura del test. Se la copertura del test non è del 100% per un codice, blocca qualsiasi commit dello sviluppatore. Dovrebbe inviarti il ​​test case che copre il 100% del codice.

Solo i controlli automatici possono scalare bene su un progetto. Non puoi controllare tutto a mano.

Lo sviluppatore dovrebbe avere un mezzo per verificare se i suoi casi di test coprono il 100% del codice. In questo modo, se non esegue il commit di un codice testato al 100%, è colpa sua, non di "oops, scusa ho dimenticato".

Ricorda: le persone non fanno mai quello che ti aspetti, fanno sempre quello che controlli.

Prima di tutto, come fanno notare la maggior parte degli intervistati, se il ragazzo non vede il valore nei test, non c'è molto che puoi fare al riguardo e hai già sottolineato che non puoi licenziarlo. Tuttavia, il fallimento non è un'opzione qui, quindi per quanto riguarda le poche cose che puoi fare?

Se la tua organizzazione è abbastanza grande da avere più di 6 sviluppatori, ti consiglio vivamente di avere un dipartimento di garanzia della qualità (anche se è solo una persona per iniziare). Idealmente, dovresti avere un rapporto di 1 tester su 3-5 sviluppatori. Il problema dei programmatori è ... sono programmatori, non tester. Devo ancora intervistare un programmatore a cui sono state formalmente insegnate le corrette tecniche di QA.

La maggior parte delle organizzazioni fa il difetto fatale di assegnare i ruoli di test al neoassunto, la persona con la MINIMA esposizione al tuo codice: idealmente, gli sviluppatori senior dovrebbero essere spostati al ruolo di QA poiché hanno esperienza nel codice e (si spera) hanno sviluppato un sesto senso per odori di codice e punti di errore che possono sorgere.

Inoltre, il programmatore che ha commesso l'errore probabilmente non troverà il difetto perché di solito non è un errore di sintassi (quelli vengono rilevati nella compilazione), ma un errore logico - e la stessa logica è al lavoro quando scrivono il test come quando scrivono il codice. Non chiedere alla persona che ha sviluppato il codice di testare quel codice: troveranno meno bug di chiunque altro.

Nel tuo caso, se puoi permetterti lo sforzo di lavoro reindirizzato, rendi questo nuovo ragazzo il primo membro del tuo team di QA. Fagli leggere "Test del software nel mondo reale: migliorare il processo", perché ovviamente avrà bisogno di un po 'di formazione nel suo nuovo ruolo. Se non gli piace, smetterà e il tuo problema sarà comunque risolto.

Un approccio leggermente meno vendicativo sarebbe lasciare che questa persona faccia ciò in cui è brava (presumo che questa persona sia stata assunta perché in realtà è competente nella parte di programmazione del lavoro) e assumere uno o due tester per fare il test ( Gli studenti universitari spesso hanno termini di pratica o "cooperativa", adorerebbero l'esposizione e sono economici)

Nota a margine: alla fine, vorrai che il team del QA riferisca a un direttore del QA, o almeno non a un responsabile dello sviluppatore di software, perché il fatto che il team del QA riferisca al manager il cui obiettivo principale è ottenere il prodotto è un conflitto di interesse.

Se la tua organizzazione è più piccola di 6 o non riesci a farla franca creando un nuovo team, ti consiglio la programmazione accoppiata (PP). Non sono un convertito totale di tutte le tecniche di programmazione estreme, ma credo decisamente nella programmazione in coppia. Tuttavia, entrambi i membri del team di programmazione accoppiato devono essere dedicati, o semplicemente non funziona. Devono seguire due regole: l'ispettore deve comprendere appieno ciò che viene codificato sullo schermo o deve chiedere al programmatore di spiegarlo; il programmatore può codificare solo ciò che può spiegare - non sarà tollerato nessun "vedrai" o "fidati di me" o agitare la mano.

Consiglio PP solo se la tua squadra è in grado di farlo, perché, come i test, nessuna quantità di applausi o minacce convincerà un paio di introversi pieni di ego a lavorare insieme se non si sentono a proprio agio nel farlo. Tuttavia, trovo che tra la scelta di scrivere specifiche funzionali dettagliate e fare revisioni del codice rispetto alla programmazione accoppiata, il PP di solito vince.

Se la PP non fa per te, allora TDD è la soluzione migliore, ma solo se presa alla lettera. Test Driven Development significa che scrivi PRIMA i test, esegui i test per dimostrare che effettivamente falliscono, quindi scrivi il codice più semplice per farlo funzionare. Il compromesso è ora che tu (dovresti) avere una raccolta di migliaia di test, che è anche codice, ed è altrettanto probabile che il codice di produzione contenga bug. Sarò onesto, non sono un grande fan di TDD, principalmente per questo motivo, ma funziona per molti sviluppatori che preferiscono scrivere script di test piuttosto che documenti di casi di test: alcuni test sono meglio di niente. Abbina TDD con PP per una migliore probabilità di copertura del test e meno bug nello script.

Se tutto il resto fallisce, fai in modo che i programmatori equivalgano a un barattolo delle parolacce: ogni volta che il programmatore interrompe la build, deve mettere $ 20, $ 50, $ 100 (qualunque cosa sia moderatamente dolorosa per il tuo staff) in un barattolo che va al tuo preferito ( registrato!) carità. Fino a quando non pagano, evitali :)

Scherzi a parte, il modo migliore per convincere il tuo programmatore a scrivere test è non lasciarlo programmare. Se vuoi un programmatore, assumi un programmatore - Se vuoi dei test, assumi un tester. Ho iniziato come programmatore junior 12 anni fa facendo i test, e si è trasformato nel mio percorso di carriera, e non lo cambierei per niente. Un solido reparto di controllo qualità che sia adeguatamente nutrito e dotato del potere e del mandato per migliorare il software è altrettanto prezioso quanto gli sviluppatori che scrivono il software in primo luogo.

Potrebbe essere un po 'crudele, ma dal modo in cui descrivi la situazione sembra che tu debba licenziare questo ragazzo. O almeno chiarisci: il rifiuto di seguire le pratiche di sviluppo della casa (inclusi i test di scrittura) e il controllo del codice difettoso che altre persone devono ripulire alla fine ti faranno licenziare.

Il motivo principale per cui i giovani ingegneri / programmatori non impiegano molto tempo per progettare ed eseguire script di test, è perché la maggior parte delle certificazioni CS non lo richiede fortemente, quindi altre aree dell'ingegneria sono ulteriormente coperte nei programmi universitari, come schemi di progettazione.

Nella mia esperienza, il modo migliore per far prendere l'abitudine ai giovani professionisti è renderlo esplicitamente parte del processo. Cioè, quando si stima il tempo che dovrebbe richiedere un'iterazione, il tempo di progettazione, scrittura e / o esecuzione dei casi dovrebbe essere incorporato in questa stima del tempo.

Infine, la revisione del progetto dello script di test dovrebbe essere parte di una revisione del progetto e il codice effettivo dovrebbe essere rivisto nella revisione del codice. Ciò rende il programmatore responsabile per il corretto test di ogni riga di codice che scrive, e l'ingegnere senior e colleghi responsabili di fornire feedback e guida sul codice e sul test scritto.

Sulla base del tuo commento, "Dimostrando che il design diventa più semplice", presumo che voi ragazzi vi esercitiate con il TDD. Fare una revisione del codice dopo il fatto non funzionerà. L'intera cosa su TDD è che è un design e non una filosofia di test. Se non ha scritto i test come parte del progetto, non otterrai molti vantaggi dalla scrittura dei test dopo il fatto, specialmente da uno sviluppatore junior. Finirà per perdere un sacco di casi d'angolo e il suo codice sarà ancora schifoso.

La soluzione migliore è avere uno sviluppatore senior molto paziente che si sieda con lui e faccia un po 'di programmazione in coppia. E continua a farlo finché non impara. Oppure non impara, nel qual caso è necessario riassegnarlo a un'attività a cui è più adatto perché finirai per frustrare i tuoi veri sviluppatori.

Non tutti hanno lo stesso livello di talento e / o motivazione. I team di sviluppo, anche quelli agili, sono formati da persone dell '"A-Team" e da persone del "B-Team". I membri di A-Team sono coloro che progettano la soluzione, scrivono tutto il codice di produzione non banale e comunicano con gli imprenditori, tutto il lavoro che richiede di pensare fuori dagli schemi. Il B-Team si occupa di cose come la gestione della configurazione, la scrittura di script, la correzione di bug zoppi e il lavoro di manutenzione, tutto il lavoro che ha procedure rigorose che hanno piccole conseguenze in caso di fallimento.