Come presentare al meglio la prova dell'unità alla direzione?

Question

Sto preparando una presentazione sui test unitari ai dirigenti. La mia squadra ha scritto test unitari da anni ma altre aree dell'azienda sembrano aver difficoltà ad adottarlo. Posso ottenere entusiasti gli sviluppatori, ma se non c'è un buy-in dalla gestione, non diventerà uno standard.

Ragazzi, avete suggerimenti su come affrontare al meglio la gestione al riguardo? Quali sono alcune cose che hai provato in passato che hanno funzionato? Quali sono le cose che non hanno funzionato?

Answer 1

Per i manager non tecnologici sono tornato indietro su un'analogia con la costruzione di una casa. Ne avrebbero costruito uno senza progetti, semplicemente prendendo mattoni da una pila e mettendone uno sull'altro con una vaga idea a forma di casa in mente? In caso contrario, perché non accetteranno la documentazione adeguata prima della codifica, delle revisioni dei progetti, ecc.?

Per test di unità, si potrebbe provare a confronto la qualità test dei vari componenti della casa singolarmente prima di mettere insieme (mattoni, cemento, porte, finestre, impianto idraulico)

Per quelli con qualsiasi presa tecnologia a tutti, mi menzioni che il 30% al 50% gestisce le condizioni di errore e il ripristino (nei sistemi embedded mission-critical) e che non è possibile testarlo senza test dell'unità. Ad esempio, se si esegue solo il test di integrazione blackbox, come è possibile - in modo controllato e ripetibile - testare cosa accade quando il modulo A non può allocare memoria in un dato punto o un timeout scade nel modulo C in attesa di un messaggio di risposta da qualche parte, o una lettura del database che normalmente avrà successo. Spiega che nascondendo moduli di interfaccia puoi simulare il loro comportamento errato a volontà.

E, naturalmente, disegno il mio grafico di favouriite con un simbolo $ su un asse e un orologio sull'altro. Ho battuto il management in testa con questo in ogni occasione per dimostrare che il costo di ottenere bug fuori aumenta più tardi vengono scoperti (cambia una riga in una specifica dei requisiti - 5 minuti; alcuni paras in un documento di progettazione - ore; linee di codice (alla revisione del codice o fase di test unitario) - giorni, trovare l'ago in un bug di pagliaio e correggerlo al test di sistema - settimane).

Non è solo un test di unità - devi convincere il management - e gli altri sviluppatori - che il "sovraccarico superfluo" di documentazione, recensioni, test ... s/w Processi in generale (e che include l'apprendimento di nuovi strumenti) ... consente di risparmiare tempo anziché aggiungere tempo a un progetto. In altre parole, richiede più tempo e costa di più per sbagliare. Misura due volte, taglia una volta, ecc.

Per il test dell'unità, digli di continuous integration. Consiglio vivamente Jenkins, ma usa quello che funziona per te. Spiega che una build regolare, sia notturna che con ogni check-in, può estrarre automaticamente i test unitari dal tuo VCS ed eseguirli, inviando e-mail o in altro modo avvisando di un nuovo codice che ha interrotto i test esistenti quasi subito.

Se nessuna di queste opere, cercare un nuovo posto di lavoro (se si è a Singapore, o vuole essere, parlare con me ;-)

Answer 2

Dite loro che rende il codice più manutenibile e farà risparmiare denaro a lungo termine. Riduce anche i bug, se fatto correttamente.

In altre parole, riduce i costi e aumenta l'affidabilità del software. $ Costo

Answer 3

Per costruire su @hvgotcodes risposta, non solo dire loro come si fa le cose meglio, compilare alcune statistiche dal proprio team di come deve

1. sua volta ridotto intorno
2. Ridotto
3. regressioni ridotti
4. ecc

Soprattutto i costi, le aziende amano per risparmiare denaro :)

Answer 4

unit test, se fatto bene, si suppone che

• bug di cattura in precedenza, riducendo così la quantità di bug trovato da QA o in produzione, e riducendo anche i costi di correzione dei bug
• supporto di refactoring , mantenendo così il design pulito ed estendibile, che a lungo termine dovrebbe rendere la manutenzione più economica

Ci sono delle statistiche pertinenti raccolte all'interno della vostra azienda che possono basare concretamente queste affermazioni? Cioè numero di bug rilevati dal QA/utenti in prodotti diversi, o costi di implementazione medio di bugfix/funzionalità, ...

Answer 5

Non fuorviare.

Quando si citano costi ridotti, si sta insinuando che il costo del controllo qualità e il più semplice refactoring sono maggiori del prezzo di creazione e manutenzione dei test. Sarebbe bene indicarlo e cercare di mettere in atto alcune metriche per rafforzare il tuo punto.

Il problema è che non è possibile inserire un valore in dollari sul percorso non eseguito ("Abbiamo evitato 1.000 difetti che sarebbero costati 1 milione di dollari per risolvere!").

Ma dovresti essere in anticipo sul fatto che c'è un costo per la creazione dei test e che devono essere mantenuti. Se li crei e li lasci cadere in rovina, sei altrettanto peggio.

Il tuo argomento otterrà una spinta quando andrai ad aggiungere nuove funzionalità ed è più facile perché hai mantenuto il codice pulito.

Answer 6

Penso statistiche renderebbe migliore dei casi per quanto riguarda i manager non tecnici riguardano. Code Complete, 2nd Ed. ha un riepilogo di un paio di studi che dimostrano che il test unitario porta a una percentuale di rilevamento del difetto del 30% (Tabella 20-2, p 470). Penso che dovrebbe essere facile prenderlo da lì e fare in modo che meno bug si traducano in più soldi risparmiati.

Answer 7

In alcuni casi ho trovato che l'attesa per l'opportunità giusta è la chiave.

Ad esempio, in un caso ho aspettato che ci fosse un sito caldo con un cliente. E 'stato molto doloroso (pensa $$$). Una delle domande inevitabili poste dal management è stata come evitare lo stesso problema in futuro. Ed è allora che ho presentato i test unitari alla direzione ...

Quindi penso che dipenda molto dalle circostanze.

Answer 8

Mostra loro un esempio di dove il test ha già riscontrato un problema e salvato la giornata.

Answer 9

Se possibile, proverei a fornire esempi reali delle difficoltà che la tua azienda ha dovuto affrontare in passato quando supportava codice in tempo reale senza test. Quindi continua a evidenziare forse con esempi specifici la riduzione dei costi di supporto per gli aggiornamenti e le correzioni sono stati effettuati test.

Buona fortuna e facci sapere come vai avanti.:)

Answer 10

Presentarlo come Behavior Driven Development o Test Driven Development, non solo come test dell'unità.

Entrambi i BDD e TDD hanno aspetti positivi facilmente comprensibili per i non tecnici. In effetti, uno dei loro principali vantaggi è che si concentrano su aspetti non tecnici.

L'unità di test, d'altra parte, è un concetto tecnico che può essere molto astratto per il non programmatore. Metti alla prova il tuo codice? Non lo fai mentre sviluppi? Perché stiamo pagando per il personale di prova? E così via.

Answer 11

1 - Hanno bisogno di sapere o addirittura approvare? Tu sei l'ingegnere e sai meglio di loro come costruire cose che funzionano, quindi in realtà non dovrebbero interferire. Gli interesserebbero quali strumenti e quali metodi di assicurazione qualità/sicurezza hai usato se fosse un nuovo modello di auto che hai costruito per loro? Non lo penserei.

2 - Il costo dei difetti è molto, molto alto. La bassa qualità, i difetti e il debito tecnico sono un rischio di progetto molto serio che può mettere a repentaglio l'intero investimento di un progetto software. La prevenzione dei difetti è molto più economica del rilevamento dei difetti (molti multipli secondo gli studi). I test unitari hanno il circuito di retroazione più breve possibile, evitando così la sistematica bassa qualità del progetto e riducono significativamente il rischio del progetto.

3 - Non è possibile andare veloci per un lungo periodo di tempo senza un tasso di difetto molto basso - ovvero, Investire ritmi spendendo/speculando (ciò che dovrebbero ottenere).

Answer 12

tracciare un'analogia a qualcosa i gestori probabilmente utilizzano in maniera regolare - come un correttore ortografico nel loro client di posta o editor di documenti ....