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

https://stackoverflow.com/questions/7252

08-06-2019
|

Domanda

Abbiamo un programmatore junior che semplicemente non scrive abbastanza test.
Devo assillarlo ogni due ore: "hai scritto i test?"
Abbiamo provato:

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

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

Conosci altre motivazioni?

Soluzione

Questo è uno dei le cose più difficili fare.Portare la tua gente a farlo prendilo.

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

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

Che questi ragazzi insieme possono produrre codice molto velocemente e di qualità superiore.
Se il tuo ragazzo più giovane impara abbastanza per "capirlo" con un ragazzo più anziano che lo indirizza lungo la strada giusta (ad es."Ok, ora prima di continuare, scriviamo at test per questa funzione.") Ne varrà la pena le risorse che ci impegnerai.

Forse chiedi anche a qualcuno nel tuo gruppo di dare il Test unitario 101 presentazione di Kate Rhodes, penso che sia un ottimo modo per coinvolgere le persone nei confronti dei test, se consegnati bene.

Un'altra cosa che puoi fare è avere il tuo Jr.Gli sviluppatori praticano il Gioco di bowling Kata che li aiuterà ad apprendere lo sviluppo basato sui test.È in Java, ma può essere facilmente adattato a qualsiasi linguaggio.

Altri suggerimenti

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

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

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

Per quanto mi riguarda, ho iniziato a insistere affinché ogni bug che trovo e risolvo venga espresso come un test:

"Hmm, non è giusto..."
Trova possibile problema
Scrivi un test, mostra che il codice fallisce
Risolvi il problema
Mostra che il nuovo codice passa
Ripeti se il problema originale persiste

Provo a farlo anche mentre scrivo 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 che lavora su un particolare progetto.)

Immagina che io sia un finto programmatore, chiamato...Marco.Immagina di essermi diplomato non molto tempo fa e di non aver mai dovuto scrivere dei test.Immagina di lavorare in un'azienda che non lo impone o non lo richiede realmente.OK?Bene!Ora immagina che l'azienda stia passando all'utilizzo dei test e stiano cercando di mettermi in linea con questo.Darò una reazione un po' sarcastica agli argomenti menzionati finora, come se non avessi fatto alcuna ricerca al riguardo.

Iniziamo 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 ottenere più casi, ecc.Questo rende le cose più complicate secondo me.Dammi dettagli concreti.

Mostrarlo previene i difetti.

So che.Per questo vengono chiamati test.Il mio codice è buono e ho controllato la presenza di problemi, quindi non vedo dove questi test potrebbero essere d'aiuto.

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

Ohh, quindi pensi che io sia un cattivo programmatore solo perché non eseguo test così utilizzati.Sono offeso e decisamente infastidito da te.Preferirei avere assistenza e sostegno piuttosto che detti.

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

Ohh, questo è così importante che le risorse verranno spese per assicurarmi di vedere come vengono fatte le cose e che qualcuno mi assista su come vengono fatte le cose.Questo è utile e potrei iniziare a farlo di più.

@Justin Standard:Leggere Test unitario 101 presentazione di Kate Rhodes.

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

Mi piacerebbe vedere articoli più convincenti e altri strumenti che mi aiutino ad allinearmi con il pensiero che questo è il modo giusto di fare le cose.

@Domenico Cooney:Dedica un po' di 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ù elementi nel mio bagaglio di conoscenze, che potrei utilizzare di nuovo.

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

Avere una persona (persone) di riferimento per rispondere alle domande è utile, potrebbe rendermi più propenso a provare.I buoni esempi sono fantastici e mi danno qualcosa a cui aspirare e qualcosa a cui cercare un riferimento.I libri che sono direttamente rilevanti per questo sono un ottimo riferimento.

@Adam Hayle:Recensione a sorpresa.

Dimmi una cosa, hai fatto nascere qualcosa a cui sono completamente impreparato.Mi sento a disagio con questo, ma farò del mio meglio.Ora avrò paura e un po' di apprensione per il fatto che ciò si ripeta, grazie.Tuttavia, la tattica intimidatoria potrebbe aver funzionato, ma ha un costo.Tuttavia, se nient’altro funziona, questa potrebbe essere proprio la spinta necessaria.

@Rytmis:Gli elementi sono considerati completati solo quando presentano casi di test.

Ohh, interessante.Vedo che devo assolutamente farlo adesso, altrimenti non finisco nulla.Questo ha senso.

@jmorris:Liberarsi/Sacrificarsi.

bagliori, bagliori, bagliori - C'è la 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 adesso, ma non lo sarà per molto.Tuttavia, se proprio non capisco, capisco che andrò.Penso che lo otterrò.

Alla fine, il supporto del mio team avrà un ruolo importante in tutto questo.Avere una persona che si prende il suo tempo per assistermi e farmi iniziare ad adottare buone abitudini è sempre il benvenuto.Poi, in seguito, avere una buona rete di supporto sarebbe fantastico.Sarebbe sempre apprezzato che qualcuno venisse qualche volta dopo, ed esaminasse un po' di codice, per vedere come procede il tutto, non in una recensione di per sé, ma più come una visita amichevole.

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

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

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

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

Ecco cosa farei:

Prima volta fuori..."Faremo questo progetto insieme.Io scriverò i test e tu scriverai 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."
Seguendo quello..."Hai finito?Grande!Per prima cosa diamo un'occhiata ai test che stanno guidando il tuo sviluppo.Oh, nessun test?Fammi sapere quando sarà terminato e riprogrammeremo l'esame del tuo codice.Se hai bisogno di aiuto per formulare i test fammi sapere e ti aiuterò."

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

Potrebbe anche valere la pena sottolineare lo scopo a lungo termine dei 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 ho visto questo menzionato.

Nell'eseguire 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, lo è anche sapere quanto poco sai.

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

Modificare:[Justin Standard]

Non abbatterti, quello che hai da dire è più o meno giusto.

Sul tuo punto sulle revisioni del codice:ciò che scoprirai è che non solo lo sviluppatore junior imparerà nel processo, ma lo faranno anche i revisori.Tutti coloro che partecipano a una revisione del codice imparano se lo rendi un processo collaborativo.

Francamente, se devi mettere Quello Se fai molti sforzi per convincerlo a fare qualcosa, potresti dover fare i conti con il pensiero che potrebbe non essere adatto alla squadra e potrebbe essere necessario andarsene.Ora, questo non significa necessariamente licenziarlo...potrebbe significare trovare qualche altro posto in azienda in cui le sue competenze siano più adatte.Ma se non c'è altro posto... sai cosa fare.

Presumo che sia anche un assunto abbastanza nuovo (<1 anno) e probabilmente recentemente uscito dalla 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 farla franca al college.

In questo caso, una cosa che ho trovato opere è quella di avere una sorta di "revisione del nuovo noleggio a sorpresa". Non importa se non l'hai mai fatto prima ... non lo saprà.Basta farlo sedere e dirgli che esaminerai la sua prestazione e gli mostrerai alcuni numeri reali... prendi il tuo normale foglio di revisione (hai un processo di revisione formale, vero?) e cambia l'intestazione se vuoi in modo che appaia ufficiale e mostrargli 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 semplicemente "tormentarlo" per questo, si spera che capirà il punto.Devi dimostrargli che le sue azioni lo influenzeranno effettivamente, sia in termini di retribuzione che in altro modo.

Lo so, forse dovresti evitare di 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.

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

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

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

Chiedere:"Che ne dici della prossima settimana?"

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

Questo è lo scopo del test unitario automatico.

Essendo io stesso un programmatore junior, ho pensato di rivelare com'è stato quando mi sono trovato in una situazione simile al tuo sviluppatore junior.

Quando sono uscito dall'università per la prima volta, ho scoperto che mi aveva gravemente non attrezzato per affrontare il mondo reale.Sì, conoscevo alcune nozioni di base su Java e un po' di filosofia (non chiedere) ma questo è tutto.Quando ho ottenuto il mio lavoro per la prima volta è stato a dir poco scoraggiante.Lascia che ti dica che probabilmente ero uno dei più grandi cowboy in circolazione, metterei insieme una piccola correzione di bug/algoritmo senza commenti/test/documentazione e lo spedirei fuori dalla porta.

Ho avuto la fortuna di essere sotto la supervisione di una persona gentile e molto paziente programmatore senior.Fortunatamente per me, ha deciso di sedersi con me e trascorrere 1-2 settimane esaminando insieme il mio codice molto hackerato.Spiegherebbe dove avevo sbagliato, i punti più fini di c e i puntatori (ragazzo, questo mi ha confuso!).Siamo riusciti a scrivere un corso/modulo abbastanza decente in circa una settimana.Tutto quello che posso dire è che se lo sviluppatore senior non avesse investito il tempo per aiutarmi sulla strada giusta, probabilmente non sarei durato a lungo.

Fortunatamente, tra due anni, spero che alcuni dei miei colleghi possano addirittura considerarmi un programmatore medio.

Porta a casa punti

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

Assegnali a progetti che non richiedono "codice stabile di alta qualità" se questa è la tua preoccupazione e lascia che jr.lo sviluppatore fallisce.Chiedi a loro di "entrare nel fine settimana" per correggere i loro bug.Pranzare molto e parlare 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 anche inventare qualcosa di meglio delle tecniche attualmente utilizzate dal tuo team.

Se il programmatore junior, o chiunque altro, non vede il valore dei test, allora 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 loro mancanza) 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 e tutoraggio, potrebbe non essere adatto alla tua squadra, quindi lascialo andare e cerca qualcuno che lo capisca.

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

Non so se è necessario bloccare i commit in questo modo però.Sul posto di lavoro tutti hanno un commit gratuito per tutto e tutti i messaggi di commit SVN (con differenze) vengono inviati via email al team.

Nota:Voi Veramente voglio il Componente aggiuntivo per le differenze colorate di Thunderbird se hai intenzione di farlo.

Il mio capo o io (i 2 programmatori "senior") finiremo per leggere i commit, e se c'è qualcosa del tipo "hai dimenticato di aggiungere test unitari", basta sfogliare un'e-mail o andare a chattare con la persona, spiegando perché loro necessari test unitari o altro.Anche tutti gli altri sono incoraggiati a leggere 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 il commit che ho fatto stamattina, ho trovato questo bel trucchetto in cui puoi fare blah blah qualunque cosa, leggere il commit e vedere come funziona!"

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

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

Tanta psicologia e utili tecniche di "tutoraggio" ma, in tutta onestà, tutto questo si riduce a "scrivere test se vuoi avere ancora un lavoro, domani".

Puoi esprimerlo nei termini che ritieni appropriati, duri o morbidi, non importa.Ma il fatto è che i programmatori non sono pagati solo per mettere insieme il codice e controllarlo: sono pagati per mettere insieme attentamente il codice, quindi mettere insieme i test, quindi testare il loro codice, POI controllare il tutto.(Almeno così sembra, dalla tua descrizione.)

Quindi, se qualcuno si rifiuta di svolgere il proprio lavoro, spiegagli che può restare a casa, domani, e assumerai qualcuno che farà il lavoro.

Ancora una volta, puoi fare tutto questo con delicatezza, se ritieni che sia necessario, ma molte persone hanno solo bisogno di un forte schiaffo di La vita nel mondo reale, e faresti loro un favore dandoglielo.

Buona fortuna.

Cambia la sua descrizione del lavoro per un po' per dedicarsi esclusivamente alla scrittura e al mantenimento dei test.Ho sentito che molte aziende lo fanno per un po' di tempo quando iniziano, per persone nuove e inesperte.

Inoltre, lancia una sfida mentre ricopre quel ruolo:Scrivere test che a) falliranno sul codice corrente a) soddisferanno i requisiti del software.Si spera che questo gli induca a creare alcuni test solidi e approfonditi (migliorando il progetto) e lo renda migliore nella scrittura dei test per quando si reintegra 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 inteso o necessario tenere conto di quel caso di test.

Se il tuo collega non ha esperienza nella scrittura di test, forse ha difficoltà a testare oltre le situazioni semplici e ciò si manifesta come test inadeguato.Ecco cosa proverei:

Dedica un po' di tempo e condividi con il tuo collega tecniche di test, come l'inserimento delle dipendenze, la ricerca di casi limite e così via.
Offriti di rispondere a domande sui test.
Esegui revisioni del codice dei test per un po'.Chiedi al tuo collega di esaminare le tue modifiche che sono esemplari di test validi.Guarda i loro commenti per vedere se stanno davvero leggendo e comprendendo il tuo codice di test.
Se ci sono libri che si adattano particolarmente bene alla filosofia di test del tuo team, dagliene una copia.Potrebbe essere utile se il feedback o le discussioni sulla revisione del codice 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 i test sono 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 insistere su questi punti.

Se hai davvero bisogno di "diventare duro", allora istituisci un sistema imparziale;a nessuno piace sentirsi preso di mira.Ad esempio, il tuo team potrebbe richiedere che il codice mantenga un certo livello di copertura del test (in grado di essere utilizzato per il gioco, ma almeno in grado di essere automatizzato);richiedere nuovo codice per avere test;richiedere ai revisori di considerare la qualità dei test quando eseguono revisioni del codice;e così via.L’istituzione di tale sistema dovrebbe derivare dal consenso del team.Se moderi attentamente la discussione potresti scoprire altri motivi di fondo per cui i test del tuo collega non sono quelli che ti aspettavi.

È responsabilità del suo Mentore insegnargli/le.Quanto bene gli stai insegnando COME eseguire il test.Stai programmando con lui?Molto probabilmente il Junior non sa COME impostare un buon test per xyz.

Da junior appena uscito da scuola conosce molti concetti.Un po' di tecnica.Qualche esperienza.Ma alla fine, tutto ciò che è Junior è POTENZIALE.Quasi ogni caratteristica su cui lavorano ci sarà qualcosa di nuovo che non hanno mai fatto prima.Sicuramente il Junior potrebbe aver eseguito un semplice modello di stato per un progetto in classe, aprendo e chiudendo "porte", ma mai un'applicazione dei modelli nel mondo reale.

Lui/lei sarà bravo tanto quanto bene insegni.Se fossero stati in grado di "Capirlo e basta", pensi che avrebbero preso una posizione Junior in primo luogo?

Nella mia esperienza, i Junior vengono assunti e hanno quasi le stesse responsabilità dei Senior, ma vengono semplicemente pagati meno e poi ignorati quando iniziano a vacillare.Perdonami se sembro amareggiato, è perché lo sono.

@jsmorris

Una volta lo sviluppatore senior e "architetto" hanno rimproverato me e un tester (era il mio primo lavoro dopo il college) tramite e-mail per non essere rimasto fino a tardi e aver terminato un compito così "facile" la sera prima.Ci siamo impegnati tutto il giorno e abbiamo smesso alle 19:00, stavo dibattendo dalle 11:00 prima di pranzo quel giorno e avevo tormentato ogni membro del nostro team per chiedere aiuto almeno due volte.

Ho risposto e ho inviato in copia al team:"Sono deluso da te ormai da un mese.Non ricevo mai aiuto dalla squadra.Sarò al bar dall'altra parte della strada se hai bisogno di me.Mi dispiace di non aver potuto eseguire il debug del metodo a 12 parametri e 800 righe da cui dipende quasi tutto."

Dopo essermi rinfrescato per un'ora al bar, sono tornato in ufficio, ho preso la mia merda e me ne sono andato.Dopo qualche giorno mi hanno chiamato chiedendomi se sarei venuto, ho detto di sì ma avevo un colloquio, forse domani.

"Allora te ne vai?"

Nel tuo repository di origine:utilizzare gli hook prima di ogni commit (ad esempio hook pre-commit per SVN)

In quell'hook, verifica l'esistenza di almeno un caso d'uso per ciascun metodo.Utilizza una convenzione per l'organizzazione dei test unitari che potresti facilmente applicare tramite un hook pre-commit.

Compilare tutto su un server di integrazione e verificare regolarmente la copertura del test utilizzando uno strumento di copertura del test.Se la copertura del test non è al 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 adattarsi bene a 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 un codice testato al 100%, è colpa sua, non di un errore "oops, scusa, ho dimenticato".

Ricordare :Le persone non fanno mai quello che ti aspetti, fanno sempre quello che controlli.

Prima di tutto, come sottolinea la maggior parte degli intervistati qui, se il ragazzo non vede l'utilità dei 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 che dire delle poche cose che fai Potere Fare?

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

La maggior parte delle organizzazioni commette il difetto fatale di assegnare i ruoli di test al nuovo assunto, la persona con la MINIMA quantità di esposizione al 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 gli odori dei codici e i punti di errore che possono emergere.

Inoltre, il programmatore che ha commesso l'errore probabilmente non troverà il difetto perché di solito non si tratta di un errore di sintassi (quelli vengono rilevati durante la compilazione), ma di un errore logico - e la stessa logica è all'opera quando scrivono il file testare come quando scrivono il codice.Non chiedere alla persona che ha sviluppato il codice di testarlo: troverà meno bug di chiunque altro.

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

Un approccio leggermente meno vendicativo sarebbe lasciare che questa persona faccia ciò in cui è brava (suppongo che questa persona sia stata assunta perché è effettivamente competente nella parte di programmazione del lavoro) e assumere uno o due tester per eseguire i test ( Gli studenti universitari spesso seguono tirocini o termini "cooperativi", apprezzerebbero l'esposizione e sono economici)

Nota a margine:Alla fine, vorrai che il team di QA riferisca a un direttore del QA, o almeno non a un manager dello sviluppatore di software, perché avere il team di QA che riferisce al manager il cui obiettivo principale è portare a termine il prodotto è un conflitto di interessi.

Se la tua organizzazione ha meno di 6 persone o non puoi farla franca creando un nuovo team, ti consiglio la programmazione abbinata (PP).Non sono un convertito totale di tutte le tecniche di programmazione estreme, ma credo decisamente nella programmazione abbinata.Tuttavia, entrambi i membri del team di programmazione accoppiato devono essere dedicati, altrimenti semplicemente non funziona.Devono seguire due regole:l'ispettore deve comprendere appieno cosa viene codificato sullo schermo oppure deve chiedere spiegazioni al codificatore;il programmatore può codificare solo ciò che può spiegare: non sarà tollerato alcun "vedrai" o "fidati di me" o agitazione della mano.

Raccomando il PP solo se il tuo team ne è capace, perché, come i test, nessuna quantità di applausi o minacce convincerà una coppia 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 di eseguire revisioni del codice rispetto alla scelta di scrivere specifiche funzionali dettagliate.programmazione accoppiata, il PP di solito vince.

Se PP non fa per te, allora TDD è la soluzione migliore, ma solo se presa alla lettera.Sviluppo basato sui test 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 è che ora (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, chiedi ai programmatori l'equivalenza di un barattolo di 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!) ente di beneficenza.Finché non pagano, evitateli :)

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 test, e si è trasformato nel mio percorso professionale e non lo scambierei con niente al mondo.Un solido reparto di controllo qualità 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' spietato, ma dal modo in cui descrivi la situazione sembra che tu debba licenziare questo ragazzo.O almeno chiarirlo:rifiutarsi di seguire le pratiche di sviluppo della casa (compresi i test di scrittura) E controllare il codice difettoso che altre persone devono ripulire alla fine ti farà licenziare.

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

Nella mia esperienza, il modo migliore per abituare i professionisti junior è 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 della progettazione dello script di test dovrebbe far parte di una revisione della progettazione e il codice effettivo dovrebbe essere rivisto nella revisione del codice.Ciò rende il programmatore responsabile di eseguire test adeguati su ogni riga di codice che scrive e l'ingegnere senior e i colleghi responsabili di fornire feedback e indicazioni sul codice e sui test scritti.

Sulla base del tuo commento, "Dimostrare che il design diventa più semplice", presumo che voi ragazzi pratichiate TDD.Fare una revisione del codice a posteriori non funzionerà.Il punto fondamentale di TDD è che si tratta di una filosofia di progettazione e non di test.Se non ha scritto i test come parte della progettazione, non otterrai molti benefici dalla scrittura dei test a posteriori, specialmente da uno sviluppatore junior.Finirà per perdere un sacco di casi particolari e il suo codice sarà comunque scadente.

La soluzione migliore è avere a molto paziente sviluppatore senior a sedersi con lui e fare un po' di programmazione in coppia.E continua così finché non impara.Oppure non impara, nel qual caso devi riassegnarlo a un compito per il quale è 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 persone del “B-Team”.I membri dell'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 l'esecuzione di lavori di manutenzione, tutto il lavoro che prevede procedure rigorose che hanno piccole conseguenze in caso di fallimento.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow