Come hai convinto il tuo manager a farti test unitario?

Per "utilizzo" intendo essere autorizzato a sviluppare, fare il check-in al controllo del codice sorgente e mantenere i test unitari nel tempo, ecc.

Le obiezioni tipiche della direzione sono:

1. Il cliente non ha pagato per i test unitari
2. Il progetto non prevede il tempo per i test unitari
3. Debito tecnico? Quale debito tecnico?

Conosci altre obiezioni? Quali sono state le tue risposte?

Grazie in anticipo!

Di recente mi sono imbattuto in questo problema quando un cliente era d'accordo con la nostra metodologia, ma il management superiore ha capito che gli sviluppatori stavano impiegando il loro tempo a testare piuttosto che a svilupparsi ed erano preoccupati per questo - dopo tutto, avevano persone addette al controllo qualità per fare i test! Ho scritto un blog su come l'ho affrontato qui:

http://practicalagility.com/show-them-the-numbers-its-results-that-matter/

Per riassumere, ho confrontato le nostre ore stimate con le ore effettive per il progetto e quindi ho confrontato il nostro tasso di difetto con il tasso di difetto di altri team. Nel nostro caso questi numeri sono stati confrontati favorevolmente e non c'erano più preoccupazioni.

La mia conclusione basata su questa esperienza è:

... il modo migliore per convincere chiunque che il tuo approccio al fare qualcosa è pratico e pragmatico, è farlo e misurarlo con altri approcci. Alla gente non importa del dogma o del perché pensi che qualcosa dovrebbe essere il modo migliore. Solo mostrando alle persone i numeri e misurando l'efficacia del tuo approccio puoi davvero dimostrare che le tue pratiche sono efficaci.

Su altri progetti, abbiamo lavorato a fianco di sviluppatori clienti che non hanno creato test unitari o TDD e abbiamo dovuto mantenere i test che hanno superato. Tuttavia, diventa molto facile vendere l'approccio TDD a quegli sviluppatori clienti quando puoi dire loro cosa hanno rotto nel codice prima che lo sappiano!

Quindi, nel tuo caso, lo farei di nascosto se necessario (forse c'è una piccola area del codice che puoi iniziare a testare che cambia spesso o di cui sei responsabile), ma tenere traccia dei tuoi numeri - qual è il sforzo per creare i tuoi test? Qual è il tasso di difetto? Come si confronta con altri progetti / membri del team?

A mio avviso, nessuno dovrebbe chiedere l'autorizzazione o scusarsi per voler svolgere correttamente il proprio lavoro e qualsiasi sviluppatore professionista dovrebbe tentare di testare il proprio codice con test automatizzati ovunque sia possibile e pratico. Spero che nel tuo caso siano entrambe queste cose. In bocca al lupo!

Mostra il ritorno sull'investimento (ROI)

Scrivere test automatici richiede tempo. Una volta. L'esecuzione di test automatici richiede zero tempo, perché puoi fare qualcos'altro mentre sono in esecuzione.

Esempio: il test manuale della funzione X richiede 30 minuti. Scrivere un test automatico per questo richiederebbe 1 ora. Anche se non abbiamo bug, dovremo testare la funzione X dieci volte nel corso del progetto, poiché i suoi livelli e componenti dipendenti vengono modificati. Quindi automatizzare il test della funzione X ci farà risparmiare 4 ore durante la vita del progetto.

In realtà, è quando hai un bug che i test automatizzati ripagano davvero: in primo luogo, trovano i bug in anticipo e in modo economico, risparmiando tempo e imbarazzo. In secondo luogo, se hai un bug difficile e attraversi molti cicli di code-build-test per capirlo, il tempo risparmiato sui test manuali si somma straordinariamente velocemente.

Le aziende comprendono il risparmio di tempo e denaro. Ecco come venderlo.

Se li hai già affrontati e non sono d'accordo, ma non ti senti a tuo agio a scrivere codice senza di loro ... allora non chiedere di nuovo. Scrivili e non registrarli.

La direzione non conta le righe di codice, ma vedrà che tutti i tuoi check-in hanno tassi di passaggio più alti dal QA (o dai clienti) e alla fine ti chiederanno perché ... allora puoi essere tutto come "BAM! TDD !"

Non stai scherzando con il progetto, il processo o la fonte ... quindi non vedo un motivo negativo. Onestamente, non vedo un motivo per cui sia diverso dal punto di vista temporale rispetto all'esecuzione di tutti i test di esecuzione manuale + input + controllo.

1) Il cliente non ha pagato per i test unitari

Il cliente (pensava di averlo) pagato per una soluzione funzionante. A seconda dei contratti, la correzione dei difetti può effettivamente essere redditizia per la vostra azienda. Se c'è abbastanza blocco. Quindi, tornando a pagare per una soluzione funzionante. TDD dovrebbe aiutare tale obiettivo.

2) Il progetto non prevede tempo per il TDD

TDD non richiede più tempo. Dovrebbe ridurre la quantità di codice estraneo o superfluo e focalizzare la base di codice su ciò che fa passare i test. Tutti i test superati, soggetti a qualità e adeguatezza dei test, indicano che il codice è stato eseguito.

3) Debito tecnico? Quale debito tecnico?

Ho l'impressione che tu stia discutendo per l'aggiunta retrospettiva di test al codice esistente. Questa è una vendita da incubo nel migliore dei casi e non porta i benefici che potresti aspettarti. Tuttavia, l'aggiunta di test mentre correggi i bug dovrebbe essere accettabile e aiutare a lungo termine.

Non raccomando comunque di scrivere i test come suggerito da Snorfus. Sembra bello in teoria, ma i test di unità ci riesce e fare cambiamenti nel corso del tempo. Quando i requisiti cambiano, vengono aggiunte nuove funzionalità che è necessario aggiornare i test unitari. Se lavori come parte di un team, i test delle unità diventeranno obsoleti man mano che altri aggiungono funzionalità / correzioni.

Sto affrontando i punti specifici che hai citato piuttosto che sollevarne di nuovi perché c'è un margine di manovra lì per fare progressi o capire perché viene bloccato.

Per ogni cliente che deve affrontare problemi di produzione,

1. Scrivi un test unitario e invia un'e-mail al gestore dicendo che hai aggiunto un test unitario per coprire lo scenario.

2. E digli che questo problema non si ripresenterà in produzione perché il nostro test unitario viene eseguito di notte e verremo a conoscenza prima che il codice vada in produzione osservando il fallimento di questo test unitario.

3. Digli che se avessimo già eseguito questo test unitario prima che il codice andasse in produzione, questo problema di produzione non si sarebbe mai verificato.

Fallo in modo coerente e persistente e presto ne sarà convinto. Ai manager non piace il cliente che affronta i problemi di produzione e comprerà nell'idea di testing dell'unità. In bocca al lupo.