Come convincere uno sponsor del progetto che tutte le funzioni nel tuo codice dovrebbero avere test unitari [chiuso]

Question

Le persone non tecniche nella maggior parte dei casi non vedono alcun valore nella scrittura di unit test.Vogliono solo completare il codice di base e non spendere tempo e denaro in cose come i test unitari.Più tardi, ogni giorno chiedono solo di correggere un bug in più.I progetti non rispettano le scadenze e continuano a non vedere valore in buoni test automatizzati.

Answer 1

Il modo migliore è non diventare troppo tecnico con le persone "non tecniche".Basta inserirlo nei tempi di consegna senza entrare nei dettagli.

D’altro canto, sembra che le scadenze del progetto non fossero realistiche per realizzarlo effettivamente.

Answer 2

semplicemente ha scritto a lungo proprio su questo argomento.

Per riassumere le mie argomentazioni contro le lamentele comuni:

La pulizia è invisibile agli utenti;dobbiamo aggiungere nuove funzionalità.I bug costantemente prodotti da un codice disordinato sono visibili anche agli utenti.Il tempo impiegato per correggere questi bug avrebbe potuto essere impiegato per aggiungere funzionalità.Più a lungo rimaniamo nel debito di qualità, più tempo ci vorrà per aggiungere ogni nuova funzionalità.

Non abbiamo tempo per pulire.Preferiresti dedicare il tuo tempo a correggere i bug generati dal problema piuttosto che risolverlo?È come strappare le erbacce ogni fine settimana invece di estirparle dalle radici.La prevenzione è sedici volte più preziosa della cura.

Gli sviluppatori si sono cacciati in questo pasticcio;dovrebbero uscirne nel loro tempo libero.Se gli sviluppatori non avessero rilasciato i rilasci così velocemente, se non avessero risposto così rapidamente al feedback dei primi utilizzatori, anche quando il prodotto si è trasformato in una bestia molto diversa dalla sua concezione originale, non avremmo i nostri attuali clienti e ricavi .Lavoreremo per un'altra azienda e non ci lamenteremo del software che abbiamo creato.

Attenzione CEO:Il dito puntato impedisce la risoluzione.Sfida invece i tuoi sviluppatori a ridurre le segnalazioni di bug.Questo è facilmente misurabile, in modo da poter tenere traccia del tempo rispetto ai risultati.Ricorda, gli sviluppatori preferiscono implementare nuove funzionalità piuttosto che correggere i bug, quindi se chiedono tempo per correggere i bug, è una cosa seria.

Answer 3

Prova a usare un analogo.Chiedi loro se vorrebbero che i loro figli guidassero Volvo o Kit car realizzate da qualche ragazzo in fondo alla strada.La risposta dovrebbe essere sempre la Volvo.Allora chiedi perché?La risposta è più affidabile e sicura.Come fanno a saperlo?La risposta è testare.Tutte le automobili sono testate in modo estremo e il costo lo riflette.Se vogliono che il software sia quanto più affidabile possibile, hanno bisogno di test.(Oppure diventano i manichini dei crash test)

Answer 4

Beh, penso che il problema sia che dici "tutte le funzioni".Tutte le funzioni non necessitano di test unitari e alcuni sostengono che il test unitario delle singole funzioni sia assolutamente sbagliato in molti scenari.

Invece, consiglio di testare le "unità di funzionalità" effettive.Invece di scrivere un singolo test per ogni funzione, scrivi un test per ogni scenario o funzionalità.Oltre a farti risparmiare un sacco di tempo e a permetterti di eseguire i test sotto il radar, spesso è molto più accurato perché testa letteralmente le funzioni nel modo in cui vengono utilizzate.Troppo spesso i test unitari funzione per funzione non testano la cosa giusta o, peggio ancora, testano simulazioni.

Ti consiglio di evitare a tutti i costi l'uso di mock nei test.L'uso di una simulazione sostanzialmente invalida il test perché stai testando come funziona in circostanze ideali invece di come funziona nel mondo reale.

Un vantaggio collaterale è che ottieni anche un migliore rilevamento dei codici morti.Qualsiasi codice che non sia coperto da un test di alto livello probabilmente non viene utilizzato e può essere rimosso.Non sottovalutare mai il valore dell'eliminazione del codice morto.

Answer 5

Vendere test unitari completi dopo che lo sviluppo è già iniziato lo è molto difficile.Direi addirittura che spesso è impossibile.Se non ottieni in anticipo il consenso di tutte le parti interessate del progetto per i test unitari completi, allora dovresti essere felice per qualsiasi test unitario che riesci a eseguire.

Answer 6

Tu no.I test non dovrebbero essere qualcosa che viene scritto separatamente, quindi non è necessario tenerne conto nella pianificazione più di quanto si pianificherebbe specificamente la "compilazione" o la "digitazione del codice".Tutto il tempo impiegato a scrivere i test dovrebbe essere compensato dal tempo che ti faranno comunque risparmiare.

Answer 7

Fallo e basta.All'inizio sarai più lento poiché scriverai più codice e penserai prima al problema.Ma passerai rapidamente altri al progetto poiché avrai meno errori/bug e il tuo design sarà migliore.

Se si progetta il sistema pensando ai test, sarà intrinsecamente più flessibile un progetto rispetto a un progetto non testabile.Sarà quindi più veloce aggiungere funzionalità in futuro.

Answer 8

@Craig, ho pensato anche all'analogo dell'auto, ma penso che l'analogia vada in pezzi poiché sembra che ci siano già dei test presenti nel progetto ed è semplicemente una questione di grado.In tal caso l'analogia con l'auto diventa "Ti interessa se la luce di cortesia dell'auto viene testata purché vengano testati i sistemi critici (freni, fari, trasmissione, ecc.)".In qualità di sponsor di un progetto tormentato che vede il progetto andare oltre la data di fine, non mi interessa davvero se la luce della cupola viene testata o meno.

Answer 9

Un buon modo per vendere il valore degli unit test è dal punto di vista del supporto: se si utilizza un framework di unit test che ha un runtime che può essere distribuito (nUnit è uno), è possibile avere una voce di menu "Esegui unit test" nel menu di aiuto.Questo può eseguire tutti i test unitari e i risultati possono essere inviati al supporto tecnico per aiutare a risolvere i problemi del client.

Ovviamente ci sono molti modi in cui potresti vendere la maggiore stabilità, ma il supporto tecnico è un costo in “denaro reale” che la maggior parte dei manager vorrebbe ridurre.