I test end-to-end e di integrazione valgono la pena per cose non mission-critical?

È noto che i test end-to-end e di integrazione sono costosi. Naturalmente se sviluppiamo applicazioni in cui le persone potrebbero morire se le cose vanno male, è un investimento utile. Tuttavia, nelle applicazioni in cui gli errori non sono la fine del mondo, non sarebbe più economico saltare del tutto i test E2E e i test di integrazione e creare un piano di backup se qualcosa va storto? Come è sufficiente un test manuale di user story + unit test + usando un linguaggio tipicamente statico?

Ad esempio, se un web store ha perso un ordine, potrebbe invece inviare l'articolo gratuitamente + un altro articolo come scusa. L'utente finale potrebbe diventare ancora più felice in questo modo e l'azienda nel complesso risparmia denaro.

Immagino che la mia domanda sia, in generale, quanto costa un test di integrazione e un test E2E e quanti soldi risparmia? C'è un modo per fare un calcolo del rischio / costo per questo?

Non importa se si implementano E2E e test di integrazione o meno, è necessario un piano di backup in entrambi i casi . Non aspettarti mai che un sistema sia privo di bug solo perché è stato testato.

Pertanto, nella stima dei costi, non si confronta il costo per l'implementazione dei test E2E con i costi stimati dal piano di backup in caso di errore, si confronta:

• Costi per l'esecuzione manuale dei test E2E (più volte, prima di ogni nuova versione)

vs.

• Costi per la costruzione (e il mantenimento) di test E2E automatici

Nel caso in cui sia possibile utilizzare tali test E2E più volte, di solito ci saranno una serie di test in cui i costi raggiungono un punto di pareggio. Questa dovrebbe essere la metrica che applichi quando vuoi pianificare in anticipo quali test E2E farai manualmente e quali automatizzerai.

Si noti che potrebbero esserci alcuni tipi di test E2E che possono essere implementati facilmente, in cui il ROI è immediatamente chiaro, ma ci sono anche tipi di test E2E in cui lo sviluppo e la manutenzione possono essere più costosi che eseguirli manualmente per un periodo di diversi anni.

Forse in modo intuitivo, i test automatizzati possono effettivamente ridurre i tempi di sviluppo rispetto a nessun test. Quindi è una vittoria.

L'idea è che i test contribuiscano a vari livelli

1. Forza la raccolta e le specifiche rigorose dei requisiti

   Ciò ha un impatto enorme sulla velocità di sviluppo. Non tornare indietro per chiedere maggiori dettagli, senza equivoci, senza funzionalità non necessarie ecc

2. Gli sviluppatori sanno quando una funzionalità è completa

   La maggior parte dei test viene eseguita dagli sviluppatori durante la scrittura del codice anziché dai tester che controllano un prodotto finito. L'automazione di questo test riduce questo carico di lavoro

3. I bug introdotti da nuove funzionalità sono stati immediatamente rilevati.

   Questi possono facilmente costarti uno sprint e richiedere la riscrittura di un'intera funzionalità se non vengono rilevati.

4. Ciclo di rilascio più rapido

   Ciò significa meno codice in volo, il che significa meno fusione, il che significa meno lavoro e meno complessità per gli sviluppatori

Soprattutto se si dispone di una configurazione del framework di test, la scrittura di questi test richiede meno tempo di quanto si risparmi in queste efficienze.

Inoltre, risparmi sui tempi dei test manuali e alla fine ottieni un prodotto migliore.

La mia risposta? Forse, probabilmente no .

I test EOE sono buoni quando sono molto semplici. Se hai intenzione di coprire scenari di base, puoi riuscire ad ottenere qualche vantaggio con i test EOE. Ma se hai un'applicazione davvero complessa e di grandi dimensioni (mission critical o no), questi test EOE saranno costosi da mantenere e devi conoscere il tuo scenario per valutare se ne vale la pena.

Alcuni anni fa il blog dei test di Google ha discusso di questo argomento. Posso solo essere d'accordo con l'autore. Un buon test deve essere veloce , affidabile e isolare i guasti , caratteristiche che i test EOE non sono in grado di fornirti.

Ho lavorato su un'applicazione che ha più di 12 ore di test end-to-end che coprono molti scenari. Alla fine siamo riusciti a distribuire questi test su macchine diverse, controllando l'inizio, l'esecuzione e la fine dei test, raccogliendo e unendo i risultati. L'applicazione testata era un'applicazione monolite (che è più facile da installare ed eseguire per testare) ed è stato un incubo mantenere i test.

Per la maggior parte del tempo abbiamo mantenuto i test invece di rilevare i bug dai loro risultati. Scopri l'origine di un bug in un test end-to-end richiede molto tempo. Abbiamo anche affrontato molti test "falsi negativi" e poco tempo per capire il problema e correggerlo: problemi di caricamento dell'applet Java, elemento previsto non trovato sulla pagina (oltre ad altri problemi relativi alla velocità di automazione), mantenere il codice di query che vengono utilizzati solo nel test della memoria del database (poiché la query originale utilizza un codice specifico del database), ecc.

Tutto ciò ha bisogno di persone che si mantengano attive. Alla fine stiamo iniziando a eliminare alcuni test EOE e sostituirli con molti test unità / integrazione.

Quindi, il mio consiglio conservatore è usare la piramide dei test di Google:

Come prima ipotesi, Google suggerisce spesso una divisione del 70/20/10: 70% di test unitari, 20% di test di integrazione e 10% di test end-to-end. Il mix esatto sarà diverso per ogni squadra, ma in generale dovrebbe mantenere quella forma piramidale.

Nella mia esperienza, i test E2E, indipendentemente dalla criticità dell'app, sono sempre prudenti. Penso sempre in termini di scenario peggiore, se le cose vanno a forma di pera ti senti a tuo agio a stare di fronte al management e a giustificare il tuo approccio? In caso contrario, è necessario modificare il proprio approccio. Molte organizzazioni minimizzano l'importanza e le risorse assegnate ai test, ma sono certo che quando le cose vanno male tutti cercano qualcuno da incolpare e se hai preso la decisione di limitare i test o hai dato quel consiglio, allora sei tu a rispondere linea.

Lo sviluppo di software troppo spesso richiede un occhio sulle politiche organizzative.

"È noto che i test end-to-end e di integrazione sono costosi".

Penso di non essere d'accordo con questa affermazione.

In primo luogo, i test E2E sono importanti per gli utenti finali e possono essere le opzioni più efficaci in termini di tempo / costo più basso per testare sistemi complessi. Ad esempio, quando qualcuno acquista un'auto la maggior parte delle persone non la fa a pezzi e inizia a testare il carb, il cambio, le ruote in modo isolato. Invece, lo prendono per un test drive.

In secondo luogo, in termini di utensili, E2E non tende a rallentare l'evoluzione interna del prodotto e dura più a lungo. Se ci pensate, la superficie funzionale effettiva della maggior parte dei prodotti raramente cambia così tanto, mentre internamente può essere soggetta a tutti i tipi di sviluppi. Di conseguenza, una volta che l'attrezzatura di prova è attiva e funzionante, di solito dura molto bene. Ad esempio, se torniamo all'analogia della macchina. Lo stesso caso di prova "prendilo per un viaggio" funzionerebbe praticamente su Ford Model T come su una Tesla. Come farebbero gli investimenti in strade rotanti, gallerie del vento, installazioni per prove di tenuta ecc. Quanti test sui componenti interni avrebbero avuto un ROI così buono nel corso della loro vita?

Laddove il test E2E tende ad essere più costoso / inappropriato, tuttavia, è nella configurazione iniziale e se viene utilizzato per provare e testare tutto. Pragmaticamente, penso che il modo migliore per evitare questa trappola sia quello di priorità automatizzare i test di cose che:

1. Sono facili da automatizzare e difficilmente richiedono molta manutenzione per continuare a funzionare.
2. Consuma più tempo per applicare processi di test manuali coerenti, adeguati e adeguati.
3. Rischia di far sembrare te o il tuo capo idioti se il prodotto viene rilasciato con il prodotto rotto.

Usa qualsiasi forma di test incluso E2E che ritieni appropriato. Concentrati su quelli però.

Non è possibile confrontare realmente il costo dei test di integrazione con il costo di uno scenario del caso migliore in cui un errore riguarda solo un singolo ordine. Un bug logico avrebbe la stessa probabilità di influenzare un gran numero di ordini. Dire che un bug significa che non vengono acquisiti pagamenti - questo potrebbe avere effetti disastrosi per qualsiasi azienda.

Dovresti chiedere qual è il bug peggiore che realisticamente potrebbe finire in produzione a causa della mancanza di test E2E. E ricorda la legge di Murphys.

Presumo che questa domanda riguardi le applicazioni Web aziendali.

La mia raccomandazione per cose medio-critiche:

• Esegui test automatici per le API di back-end, assicurandoti che il back-end funzioni come previsto. Questi test devono essere scritti dagli sviluppatori durante l'implementazione di un'API.
• Non preoccuparti dei test automatici dell'interfaccia utente, ovvero esegui manualmente i test frontend.

Penso che la maggior parte dei test dovrebbe essere a livello di API o componente. Non mi interessano i test unitari che eseguono solo alcune funzioni interne.