Non ho documenti di ricerca o statistiche da darti, ma riferirò la mia esperienza lavorando in un team / organizzazione che storicamente aveva una copertura unitaria medio-bassa e nessun test end-to-end, e gradualmente spostando la barra dove siamo ora, con più di un approccio ATDD (ma, ironicamente, non tradizionale TDD).
In particolare, questo è il modo in cui le tempistiche del progetto venivano utilizzate (e continuano a giocare su altri team / prodotti nella stessa organizzazione):
- Fino a 4 settimane di analisi e implementazione
- 2 settimane di test di regressione, correzione di errori, stabilizzazione e preparazione del rilascio
- 1-2 settimane per la correzione di difetti noti
- 2-3 settimane di pulizia del codice e problemi / supporto post-produzione (difetti sconosciuti / interruzioni non pianificate)
Sembra un ridicolo sovraccarico, ma in realtà è molto comune, è spesso mascherato in molte organizzazioni da un QA mancante o inefficace. Abbiamo buoni tester e una cultura di test intensivi, quindi questi problemi vengono risolti in anticipo e risolti in anticipo (la maggior parte del tempo), anziché essere autorizzati a giocare lentamente nel corso di molti mesi / anni. Il 55-65% dei costi di manutenzione è inferiore alla norma comunemente accettata dell'80% del tempo impiegato per il debug - il che sembra ragionevole, perché abbiamo avuto alcuni test unitari e team interfunzionali (incluso il QA).
Durante la prima versione del nostro ultimo prodotto da parte del nostro team, avevamo iniziato a eseguire il retrofit dei test di accettazione, ma non erano all'altezza e abbiamo dovuto fare affidamento su molti test manuali. Il rilascio è stato in qualche modo meno doloroso di altri, IMO in parte a causa dei nostri test di accettazione casuali e anche in parte a causa della nostra altissima copertura di test unitari rispetto ad altri progetti. Tuttavia, abbiamo trascorso quasi 2 settimane in regressione / stabilizzazione e 2 settimane in problemi di post-produzione.
Al contrario, ogni versione successiva a quella iniziale ha avuto criteri di accettazione precoce e test di accettazione e le nostre attuali iterazioni si presentano così:
- 8 giorni di analisi e implementazione
- 2 giorni di stabilizzazione
- 0-2 giorni combinati di supporto post-produzione e pulizia
In altre parole, siamo passati dal 55-65% delle spese generali di manutenzione al 20-30% delle spese generali di manutenzione. Stesso team, stesso prodotto, la differenza principale sta nel progressivo miglioramento e razionalizzazione dei nostri test di accettazione.
Il costo per mantenerli è, per sprint, 3-5 giorni per un analista di controllo qualità e 1-2 giorni per uno sviluppatore. Il nostro team ha 4 sviluppatori e 2 analisti di QA, quindi (senza contare UX, gestione dei progetti, ecc.) Questo è un massimo di 7 giorni-uomo su 60, che completerò con un overhead di implementazione del 15% solo per essere attivo il lato sicuro.
Dedichiamo il 15% di ogni periodo di rilascio allo sviluppo di test di accettazione automatizzati e nel processo siamo in grado di tagliare il 70% di ciascun rilascio facendo test di regressione e correggendo bug di pre-produzione e post-produzione.
Potresti aver notato che la seconda sequenza temporale è molto più precisa e anche molto più breve della prima. È qualcosa che è stato reso possibile dai criteri di accettazione e dai test di accettazione anticipati, perché semplifica enormemente la "definizione di fatto" e ci consente di essere molto più fiduciosi nella stabilità di un rilascio. Nessun altro team è riuscito (finora) con un programma di rilascio bisettimanale, tranne forse quando ha fatto rilasci di manutenzione abbastanza banali (solo correzione di errori, ecc.).
Un altro interessante effetto collaterale è che siamo stati in grado di adattare il nostro programma di rilascio alle esigenze aziendali. Una volta, abbiamo dovuto allungarlo a circa 3 settimane per coincidere con un'altra versione, e siamo stati in grado di farlo mentre offrivamo più funzionalità ma senza spendere altro tempo in test o stabilizzazione. Un'altra volta, abbiamo dovuto accorciarlo a circa 1½ settimane, a causa di festività e conflitti di risorse; abbiamo dovuto assumere meno lavoro di sviluppo, ma, come previsto, siamo stati in grado di dedicare di conseguenza meno tempo ai test e alla stabilizzazione senza introdurre nuovi difetti.
Quindi, nella mia esperienza, i test di accettazione, specialmente se eseguiti molto presto in un progetto o in uno sprint, e se ben mantenuti con i criteri di accettazione scritti dal Product Owner, sono uno dei migliori investimenti che puoi fare. A differenza del TDD tradizionale, che le altre persone sottolineano correttamente è focalizzato più sulla creazione di codice testabile che su codice privo di difetti - ATDD aiuta davvero a rilevare i difetti molto più velocemente; è l'equivalente organizzativo di avere un esercito di tester che eseguono ogni giorno un test di regressione completo, ma molto più economico.
ATDD ti aiuterà in progetti a lungo termine realizzati in stile RUP o (ugh) Waterfall, progetti della durata di 3 mesi o più? Penso che la giuria sia ancora fuori per quello. Nella mia esperienza, i rischi maggiori e più brutti in progetti di lunga durata sono scadenze non realistiche e requisiti in evoluzione. Le scadenze non realistiche indurranno le persone a prendere scorciatoie, comprese le scorciatoie di test, e le modifiche significative ai requisiti probabilmente invalideranno un gran numero di test, richiedendo che vengano riscritti e potenzialmente gonfiando il sovraccarico di implementazione.
Sono abbastanza sicuro che ATDD abbia un fantastico guadagno per i modelli Agile o per i team che non sono ufficialmente Agile ma hanno programmi di rilascio molto frequenti. Non l'ho mai provato su un progetto a lungo termine, principalmente perché non sono mai stato o ho mai sentito parlare di un'organizzazione disposta a provarlo su quel tipo di progetto, quindi inserisci qui la dichiarazione di non responsabilità standard. YMMV e tutto il resto.
PS Nel nostro caso, non è necessario un ulteriore sforzo da parte del "cliente", ma abbiamo un Product Owner dedicato a tempo pieno che scrive effettivamente i criteri di accettazione. Se sei nel settore dei "software di consulenza", sospetto che potrebbe essere molto più difficile indurre gli utenti finali a scrivere utili criteri di accettazione. Un Product Owner / Product Manager sembra un elemento piuttosto essenziale per fare ATDD e anche se posso ancora una volta parlare solo della mia esperienza, non ho mai sentito parlare di ATDD che viene praticato con successo senza che qualcuno adempia a quel ruolo.
