Test automatizzati: spiegazione del suo valore commerciale

Per iniziare, non penso che questa sia una ripetizione di altre domande sui test unitari . Ciò con cui cerco aiuto è articolare il suo valore a un team di programmatori, analisti, manager e tester. Con i test automatici, non penso di dover fare una distinzione tra test unitari (ad esempio JUnit), BDD (ad esempio JBehave, Fitness) e UI (Selenium, Watir) perché penso che tutti forniscano un valore simile (ma sono libero di scrivi una risposta che non è d'accordo :))

Di seguito è riportato un elenco che ho identificato, cerco risposte che aiutino a espandere o perfezionare:

1. Risparmio di tempo / costi : la scrittura di test automatici può richiedere più tempo rispetto ai casi di test scritti. Tuttavia, considerando che i test vengono eseguiti più volte, il lavoro marginale (ad es. Costo / tempo) per eseguire i test automatizzati è inferiore di diversi ordini di grandezza. Che i test automatici siano economici da eseguire facilita la modifica del sistema nel tempo.
2. Documentazione : non esiste un modo più vero per sapere come funziona un sistema se non i suoi test. Ogni altra documentazione di solito è obsoleta nel momento in cui è scritta, ma i test (almeno quelli che passano) rivelano come le cose funzionano davvero. Questo vale sia per l'utente finale che per la documentazione API.
3. Qualità del codice : la scrittura di prova ti costringe a:
   • considerare i clienti perché i test sono client
   • rompe le dipendenze in cui rendere testabile il codice spesso significa capire come rendere quel codice non richiede la disponibilità di altri sistemi di grandi dimensioni

Alcuni dei miei pensieri:

1. Siate onesti che scrivere test automatici richiederà più tempo. Se stai eseguendo un TDD a livello di unità (che consiglierei come punto di partenza se investirai in test automatici), puoi aspettarti circa il 30% di tempo in più necessario per codificare una funzionalità. La chiave qui sta spiegando che questo ulteriore 30% (che è probabilmente superiore al 30% all'inizio mentre il tuo team impara a scrivere buoni test) è un investimento costruito per risparmiare sui costi nel tempo. Come per quanto riguarda il TDD a livello di unità, il design del sistema è accoppiato liberamente e altamente coeso, il che rende il sistema adattabile ai cambiamenti nel tempo. Nuovi requisiti e bug imprevisti richiedono sempre modifiche al tuo sistema,
2. C'è un sacco di dibattito sul valore del livello di accettazione e dei test a livello di interfaccia utente, dato il tempo necessario per scrivere questi test, il tempo impiegato per eseguirli e la manutenzione necessaria. Consiglierei di leggere questo articolo di James Shore a riguardo.
3. Nel mondo dei test automatici, ci sono buoni modi e cattivi modi per farlo. Se stai lanciando test automatizzati alla tua direzione, affiancherei il modo in cui stai pianificando di far addestrare il tuo team a scrivere buoni test. The Art of Unit Testing di Roy Osherove, Lavorare efficacemente con il codice legacy di Michael Feathers e The Art of Agile Development di James Shore sono tutti dei grandi libri che trattano questi argomenti direttamente o indirettamente. Dovresti anche esaminare una sorta di allenatore o formazione formale. È un grande cambiamento.
4. In termini di valore aziendale, i punti 2 e 3 di cui sopra servono effettivamente il tuo primo punto, quindi martellerei a casa sul punto 1 e parlerei di come il punto 2 e il punto 3 servano quel punto più grande. La documentazione rende il tuo sistema più comprensibile, il che rende il tuo team più veloce. La qualità del codice rende il tuo sistema adattabile al cambiamento, il che rende il tuo team 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 consegnata come software funzionante.

Una cosa di sicuro valore è che i test automatizzati possono essere eseguiti continuamente; come ogni ora su una ricostruzione o simile. In questo modo, eventuali errori o regressioni vengono scoperti rapidamente in poche ore o giorni dopo che un programmatore lavora sul codice offensivo, ciò rende molto più semplice il cambio di contesto. Il secondo vantaggio dei test continui è che ti costringe a mantenere i test in uno stato di lavoro; niente è più noioso che passare la prima settimana di un ciclo di prova a sistemare tutti i test non aggiornati. Se è possibile automatizzarli, è possibile eseguirli in qualsiasi momento e eseguendoli regolarmente è possibile rilevare rapidamente i bug nei test o nel codice.

Spese di prova

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 sul libro paga stia redigendo 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 è in grado di commettere errori e diventare pigro.

Le modalità di fallimento del test del computer sono anche molto più evidenti: si è arrestato in modo anomalo (i report dei test smettono di apparire), ha avuto un piccolo errore che ha causato un risultato di test falso (eseguire nuovamente un test deterministico e il risultato differisce). Se un essere umano non salta un gradino e seleziona "OK", come possiamo dirlo?

Durabilità del test

Un test automatizzato 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 di origine. 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 in atto 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 eseguendo l'immissione dei dati per generare lo stesso oppure sta registrando note in formato libero che richiedono un analista, uno sviluppatore o un responsabile per essere digerite.

Principalmente (a seconda della copertura del test) codice privo di 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 quel bug ritorna :)

La mia opinione è che i test di unità / integrazione sono molto 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 / presentatori e lascio il databinding alle viste.

Ovviamente, i test automatizzati non sostituiscono le vecchie avventure punta e clicca intorno alla tua applicazione cercando di capire le cose più sfrenate che l'utente potrebbe fare.

C'è anche un punto di integrazione continua .

Ancora una cosa - bisogna cercare che la qualità del codice porti alla qualità del prodotto, al valore commerciale e alla manutenibilità - altrimenti non ha senso farlo.

Penso che dovresti guidare con i punti magici di "costo inferiore" e "più caratteristiche / tempo unitario" / tempo ciclo inferiore.

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 grande fattore qui. Avendo una buona copertura con test unitari piacevoli e LEGGIBILI (!!!), puoi riformattare il tuo sistema senza essere nervoso per compromettere la funzionalità esistente.

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

Lascerei anche venderlo come aspetto della documentazione, cose come Fitnesse possono farlo bene, ma fino a quando non lo sperimentano potrebbe essere difficile da visualizzare.

Aree in cui penso che potrebbe avere fortuna venderlo

1. I test unitari possono prendere il posto di molte imbracature per 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 impostare e ripetere facilmente le situazioni problematiche - senza spendere molto tempo a impostare i dati dei test (soprattutto utilizzando un sistema di derisione decente)

3. Quando si creano suite di test BDD e UI, si ottiene una risposta molto più rapida se ci sono interruzioni semplici rispetto all'attesa per la prossima volta che il tester lo guarda

4. I test BDD e UI possono evitare di premere ripetutamente i pulsanti per verificare tutti gli aspetti che potrebbero essere stati influenzati dalla modifica e risparmiarti di dover ricordare ogni area.

5. Le build automatiche spesso evidenziano quando qualcuno ha dimenticato di archiviare il codice

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

7. Test di unità e derisione decente significheranno meno codice interconnesso e saranno più facili da risolvere

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

Qualcuno deve credere che ci sia un problema prima di accettare una soluzione proposta a quel problema.

I test automatici possono risparmiare sui costi di correzione dei bug, quindi se i tuoi colleghi non credono che i costi di correzione dei bug siano considerevoli o eccessivi, sarà difficile convincerli. Se tali costi sono elevati o eccessivi, ma le persone non credono di esserlo, potrebbe essere necessario prima ottenere alcuni dati convincenti su tali costi.

Ciò che le aziende amano è aumentare il valore e ridurre i costi. Devi spiegare come i test automatizzati aumenteranno il valore poiché aggiungono un costo aggiuntivo.

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

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

L'argomento della documentazione fornito non è molto valido. La differenza tra l'aggiornamento dei test e la documentazione aggiornata è solo un'abitudine.

"Ciò con cui cerco aiuto è articolare il suo valore a un team di programmatori, analisti, manager e tester. Con test automatici, non credo di dover fare una distinzione tra test unitari (ad esempio JUnit), BDD ( ad es. JBehave, Fitness) e UI (Selenium, Watir) perché penso che tutti forniscano un valore simile (ma sono libero di scrivere una risposta che non è d'accordo :)) "

OK accetterò quella sfida;)

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

Gli strumenti BDD / TDD di rspec e testunit fanno parte della programmazione. Non li fai scoppiare e ne parli separatamente con il management, non li rimandi a causa della mancanza di tempo, li includi in tutte le tue stime del tempo. Se davvero spinto ti ha chiesto quanto tempo le persone hanno a disposizione per spiegare loro l'informatica e la programmazione. Non uso questi test per il front-end

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

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

Consiglio sempre di suddividere i test in 4 gruppi (maggiori dettagli qui ). Resta con me qui, vedrò come questo ti aiuterà a vendere i test agli altri in un momento.

1. Test delle tue funzionalità principali . Vale a dire, per uno strumento di monitoraggio di siti Web si tratterebbe di test di allerta che dovrebbero essere attivati ​​per i siti Web che si stanno monitorando. Questi test assicurano che queste cose non si rompano mai.
2. Prove di fumo di tutta la tua applicazione . Ad esempio, utilizzando Selenium per navigare in tutti i collegamenti / pulsanti in un'app Web e assicurarsi che non vi siano errori dal server. Questi test ti evitano di perdere tempo con i tester con build ovviamente interrotte.
3. Test di qualsiasi codice fragile . Vale a dire, per quel vecchio modulo che nessuno vuole mai toccare, o il complesso pezzo di codice che sembra contenere sempre dei bug.
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 sopra.

Suddividendo 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 la gente pensa che valga la pena testare quei codici? Se non riesci a trovare un accordo, forse non includi quei test per ora. Se puoi, vale a dire se le persone concordano sul fatto che i test sulle funzionalità principali che vengono eseguiti su ogni commit sono utili, allora inizia ad aggiungerli.

L'altro gruppo che può essere utile sono i test che sono difficili o richiedono tempo per essere eseguiti manualmente . Dovrebbe esserci un vantaggio abbastanza facile da spiegare qui in termini di risparmio di tempo per i test manuali o di testare cose che vengono saltate a causa della mancanza di tempo.