Test automatici: spiegando il suo valore aziendale

Alcuni dei miei pensieri:

1. Sii onesto che scrivere test automatici richiederà più tempo. Se stai facendo un TDD a livello di unità (che ti consiglierei come punto di partenza se investirai in test automatici), puoi aspettarti un 30% in più di tempo in più per codificare una funzione. La chiave qui è spiegare che questo extra 30% (che è probabilmente superiore al 30% all'inizio come il tuo team impara a scrivere buoni test) è un investimento costruito per risparmiare costi nel tempo. Per lo meno con il TDD a livello di unità, il design del sistema è liberamente accoppiato e altamente coesivo, il che rende il sistema adattabile al cambiamento nel tempo. Nuovi requisiti e bug inaspettati richiedono sempre modifiche al tuo sistema, quindi mantenere il tuo sistema in uno stato in cui il cambiamento è facile (dal bel design che proviene da TDD) e sicuro (il set di test automatici che verificano continuamente il tuo sistema) significa che costerà meno soldi per fare quei cambiamenti.
2. C'è un ampio dibattito sul valore dei test di livello di accettazione e dell'interfaccia utente, data la quantità di tempo necessario per scrivere questi test, quanto tempo ci vuole per eseguirli e quanta manutenzione richiedono. Consiglierei di leggere questo questo articolo di James Shore.
3. Nel mondo dei test automatici, ci sono buoni modi e cattivi modi per farlo. Se stai sottoponendo i test automatici alla tua gestione, ti affiancherò come stai pianificando la formazione del tuo team nello scrivere buoni test. The Art of Unit Testing di Roy Osherove, Working Effectively With Legacy Code di Michael Feathers e The Art of Agile Development di James Shore sono tutti grandi libri che trattano questi argomenti direttamente o indirettamente. Dovresti anche studiare una sorta di allenatore o di formazione formale. È un grande cambiamento.
4. In termini di valore aziendale, il n. 2 e il n. 3 dei tuoi punti sopra servono effettivamente il tuo primo punto, quindi tornerei a casa sul punto n. 1 e parlerò di come il n. 2 e il n. La documentazione rende il tuo sistema più comprensibile, il che rende la tua squadra più veloce. La qualità del codice rende il tuo sistema adattabile ai cambiamenti, il che rende la tua squadra più veloce. Per gli uomini d'affari, si tratta di massimizzare il flusso di valore dal momento in cui un'idea viene lanciata al momento in cui l'idea viene fornita come software funzionante.

Una cosa di sicuro valore è che i test automatici possono essere eseguiti continuamente; come ogni ora in una ricostruzione o simile. In questo modo, tutti gli errori o le regressioni vengono espulse rapidamente in poche ore o giorni da un programmatore che lavora sul codice incriminato, il che rende molto più semplice il cambio di contesto. Il secondo vantaggio dei test continui è che ti costringe a mantenerti in uno stato operativo; niente è più noioso della prima settimana di un ciclo di test che fissa tutti i test scaduti. Se puoi automatizzarli, puoi eseguirli in qualsiasi momento e amp; eseguendoli regolarmente puoi catturare bug nei tuoi test o codice rapidamente.

Spese per i test

Una volta scritto un test automatico, può essere eseguito da un computer al costo di pochi joule. Il test manuale equivalente richiede che una persona a libro paga stenda un elenco di istruzioni.

Affidabilità del test

Il computer può essere considerato affidabile per eseguire fedelmente la stessa procedura di test ogni volta. L'umano è capace di commettere errori e diventare pigro.

Le modalità di errore del test del computer sono anche molto più evidenti: si è arrestato in modo anomalo (i rapporti di test non sono più visualizzati), ha avuto un errore di bit che ha causato un risultato falso del test (eseguire nuovamente un test deterministico e il risultato è diverso). Se un essere umano salta un passaggio e controlla "OK", come possiamo dire?

Durata del test

Un test automatico deve essere un artefatto concreto (ad esempio un pezzo di codice) per poter essere eseguito, ed è naturalmente incluso con gli altri artefatti di sviluppo del software: il repository sorgente. Un test manuale può essere sviluppato su un foglio di carta da un tester e mai formalizzato. È più probabile che l'azienda abbia bisogno di processi per garantire che ciò non accada.

Valore di prova

Il computer può essere programmato per produrre risultati di test in una forma coerente e facilmente analizzabile. La persona sta facendo l'immissione di dati per generare lo stesso, o sta registrando note in formato libero che richiedono un analista, sviluppatore o manager per la digestione.

Principalmente (a seconda della copertura del test) codice senza bug, e direi che uno degli argomenti più importanti è quando dici al tuo manager che puoi scrivere un test per un bug scoperto , assicurandoti di sapere sempre in futuro se il problema si ripresenta:)

La mia opinione è che i test di unità / integrazione sono più importanti, mentre se si applica un modello di interfaccia utente come MVC è sufficiente per la maggior parte dei progetti. Di solito collaudo tutte le azioni sui miei controller / relatori, e lascia il database alle Viste.

Naturalmente, i test automatici non sostituiscono il buon vecchio punto e fai clic su avventure intorno alla tua applicazione cercando di capire le cose più selvagge che l'utente possa fare.

C'è anche un punto di Integrazione continua .

Un'ultima cosa: è necessario sforzarsi che la qualità del codice porti alla qualità del prodotto, al valore aziendale e alla manutenibilità, altrimenti non ha senso farlo.

Penso che dovresti guidare con i punti magici di "costo inferiore" e "più funzioni / unità di tempo" / ciclo più breve.

Tuttavia, prima di presentare un caso, consiglierei di riflettere sulla tua situazione. La tua domanda mi ha portato a scrivere un post sul blog sui potenziali svantaggi dei test automatizzati .

La facilità di refactoring è un fattore importante qui. Avendo una buona copertura con un test di unità bello e LEGGIBILE (!!!), puoi rifattorizzare il tuo sistema senza essere nervoso nel compromettere le funzionalità esistenti.

Devi vendere il concetto - devi evitare di dire loro che migliorerà il codice. Se hanno qualche investimento nel codice che immediatamente li metterà contro di te / auto test. Se sono validi, capiranno anche GIGO, quindi non capiranno perché pensi che non si applichi.

Lascerei da vendere anche come aspetto della documentazione, cose come Fitnesse possono farlo bene, ma fino a quando non sono state sperimentate potrebbe essere difficile da visualizzare.

Aree Penso che potrebbe avere fortuna a venderlo

1. I test delle unità possono prendere il posto di molti cablaggi degli sviluppatori - in cui si crea un'applicazione solo per accedere all'area di debug / test senza passare attraverso tutti i login / menu.

2. I test ti consentono di configurare e ripetere facilmente le situazioni dei problemi, senza dedicare molto tempo alla configurazione dei dati di test (specialmente utilizzando un sistema di derisione decente)

3. Mentre crei suite di BDD & Test dell'interfaccia utente: ottieni una risposta molto più rapida in caso di interruzioni semplici rispetto all'attesa successiva della verifica da parte del tester

4. BDD & I test dell'interfaccia utente possono evitare di premere ripetutamente i pulsanti per controllare tutti gli aspetti che potrebbero essere stati influenzati dal cambiamento e risparmiare di dover ricordare ogni area.

5. Le build automatiche spesso evidenziano quando qualcuno ha dimenticato di eseguire il check-in del codice

6. I test ti aiutano a evitare la ricomparsa di bug.

7. Test delle unità e mocking discreto significano meno codice inter-linked e saranno più facili da risolvere

Ricorda che stai provando a venderlo, non a convertirli in una religione, quindi accetta piccoli passi e cerca di non farli diventare anti-voi. Ci vorrà anche del tempo per adattarsi e imparare a scrivere dei buoni test.

Qualcuno deve credere che ci sia un problema prima che accetti una soluzione proposta a questo problema.

I test automatici possono salvare i costi di correzione dei bug, quindi se i tuoi colleghi non credono che i costi di bug fixing siano consistenti o eccessivi, sarà difficile convincerli. Se tali costi sono alti o eccessivi, ma le persone non credono che lo siano, potresti prima ottenere dei dati convincenti su tali costi.

Ciò che le aziende amano è l'aumento del valore e l'abbassamento dei costi. Devi spiegare in che modo il test automatizzato aumenterà il valore poiché aggiunge un costo aggiuntivo.

Se il tuo codice è modulare sarà possibile riutilizzarlo. Ciò significa che i test non devono essere scritti di nuovo e puoi semplicemente lavorare su quel codice esistente.

Se ci sono progetti legacy, i test automatici rendono molto più facile il refactoring. Il debito tecnico deve essere pagato ad un certo punto.

L'argomento della documentazione fornito non è molto buono. La differenza tra tenere aggiornati i test e la documentazione aggiornata è solo un'abitudine.

"Ciò di cui cerco aiuto è l'articolazione del suo valore per un team di programmatori, analisti, manager e tester. Con i test automatici, non penso di dover fare una distinzione tra i test unitari ( es. JUnit), BDD (es. JBehave, Fitness) e UI (Selenium, Watir) perché penso che tutti abbiano un valore simile (ma sentiti libero di scrivere una risposta che non è d'accordo :)) "

OK, prenderò questa sfida;)

Lavoro principalmente con programmatori e QA e i miei strumenti sono ruby, rail, testunit, rspec, gelsomino e selenio.

Gli strumenti BDD / TDD di rspec e testunit sono parte della programmazione. Non li rompi e ne parli separatamente alla direzione, non li rimandi per mancanza di tempo, li includi in tutte le tue stime di tempo. Se davvero spinto chiedi quanto tempo le persone hanno per te a spiegare l'informatica e la programmazione a loro. Non uso questi test per il front-end

GUI / UI / Jasmine / selenio. Questi sono diversi. Li ho fatti da persone di QA che hanno background per programmatori. Ci assicuriamo che i test siano scritti per essere il più possibile robusti e basati sul contenuto e non sul layout. Il (possibilmente nuovo) costo di questo dovrebbe essere spiegato come un costo spostato . Invece di pagare con software rotto, clienti persi e correzioni costose in seguito, ora paghi molto meno (relativamente) con alcune semplici pratiche.

Penso che la chiave sia parlare di categorie specifiche di test che creerai, non di "test automatizzati" nel loro complesso. Quest'ultimo può essere un po 'nebuloso e preoccupante, ed è troppo facile trovare esempi di dove sarebbe una perdita di tempo.

Consiglio sempre di dividere i test in 4 gruppi (maggiori dettagli qui ). Rimani con me qui, vedrai come questo ti aiuta a vendere test agli altri in un momento.

1. Test delle funzionalità principali . Vale a dire, per uno strumento di monitoraggio del sito web questo sarebbe test di avvisi che dovrebbero sparare per i siti Web che stai monitorando. Questi test assicurano che questa roba non si interrompa mai.
2. Test dei fumi dell'intera applicazione . Ad esempio, utilizzando Selenium per navigare tutti i link / pulsanti in un'app Web e assicurarsi che non vi siano errori dal server. Questi test evitano di sprecare tempo per i tester con build ovviamente danneggiati.
3. Test di qualsiasi codice fragile . Vale a dire, per quel vecchio modulo che nessuno vorrebbe mai toccare, o per la complessa parte di codice che sembra avere sempre degli errori.
4. Test che gli sviluppatori volevano scrivere per supportare il loro lavoro . Perché a volte i test sono utili quando scrivi qualcosa, ma non rientrano nelle categorie precedenti.

Dividendo i test in queste categorie ora puoi avere una discussione diversa. Prendi i primi tre gruppi (il quarto è comunque a discrezione degli individui) e chiedi se le persone pensano che i test per quei pezzi di codice varrebbero la pena? Se non riesci ad ottenere un accordo, forse non includi quei test per ora. Se puoi, cioè se le persone concordano che i test relativi alle funzionalità di base che vengono eseguiti su ciascun commit sono utili, allora inizia ad aggiungerli.

L'altro gruppo che può essere utile è test che richiedono molto tempo o molto tempo per eseguire manualmente . Ci dovrebbe essere un vantaggio piuttosto facile da spiegare qui in termini di risparmio del tempo di test manuale, o di cose testate che vengono saltate per mancanza di tempo.