Il prodotto potenzialmente spedibile richiede test di automazione [chiuso]

Alla fine di uno sprint, qualunque cosa tu fornisca dovrebbe essere di qualità di produzione, questo è uno dei pilastri della mischia. Se non viene eseguito alla fine dello sprint, potrebbe trascinarlo per anni man mano che trovi nuove cose da aggiungere e nuove cose da sistemare. Fallo e portalo fuori dalla porta.
Se hai bisogno di un motivo: perché desideri ottenere il feedback, solo l'utilizzo da parte del cliente può farti ottenere.

Se analizzo il tuo post, quello che sto leggendo è che hai problemi con gli errori in entrambi i casi. Non è con i test che questi bug si risolveranno da soli, quindi finirai con sprint "hardening" a prescindere.

Il mio consiglio:
1) Investire nella qualità della costruzione. Se hai problemi con i bug, riunisci la squadra e scopri perché. Non dare la colpa, basta porre il problema e cercare soluzioni.
2) I test sono effettivamente in codice? Perché i test codificati sono di solito banali da automatizzare.
Se la tua idea di un test di regressione passa attraverso alcuni schermi manualmente, dovrai affrontare diversi livelli di test. I test dell'interfaccia utente possono essere automatizzati, ma sono i più difficili, quindi dovresti provare a testare quanto più puoi approfondire verso il livello dell'unità.

Penso che sia necessario affrontare questa soluzione in modo sprint.

Si desidera confrontare il tempo trascorso con la creazione di test automatici per eseguirli manualmente. Supponiamo che tu conosca il costo di fare i tuoi test di regressione manuale o che tutto questo esercizio sia discutibile. La chiave è l'efficacia del team nel creare e mantenere i test di regressione automatizzati. Se non hai esperienza in questo settore, questo progetto potrebbe non essere il momento di iniziare l'apprendimento perché non sarai molto efficiente e probabilmente non sarai in grado di stimare la quantità di tempo che impiegheranno. Tuttavia, puoi provare ad automatizzare uno o due dei tuoi test e vedere quanto tempo puoi risparmiare con la possibilità di stimare il tempo per automatizzare il resto (l'automazione non deve essere tutto o nessuno. Alcuni test potrebbero essere più facili per fare solo manualmente).

Sai quanti sprint sono rimasti? Molto difficile fare un ROI confrontando i risparmi su due approcci a un'attività ripetuta quando non sai quante volte lo ripeterai. Forse sei abbastanza fiducioso che puoi avvicinarti, ma se pensi che ci possano essere più sprint coinvolti in questo progetto di quanto pensi, anche il minimo risparmio di tempo con i test automatici potrebbe essere un aumento di morale. Se i membri del team si ritrovano a odiare i test e preferiscono modificare i pixel nella GUI, l'automazione potrebbe salvare la sanità mentale.

Cronologia dei progetti con e senza test di integrazione. Il tuo team ha scelto di eseguire test in quanto temeva i progetti che non lo avevano o seguivano solo le tendenze della moda? Questo può essere un altro controllo di sanità mentale. Dipende anche dal numero di sprint lasciati. Avere un sacco di scatti non può essere un segnale di "pensa solo a quanto tempo risparmiamo non facendo test di regressione" ma "ci sono molti sprint rimasti perché questo è un progetto molto complicato, quindi avere dei test potrebbe essere più utile di quanto pensiamo ".

Non penso che ci sia una risposta universale per qualsiasi squadra da testare o non testare e quanto dovresti automatizzarli. L'esperienza ha molto a che fare con questo. Alcuni progetti sono più propensi a implementare nuove cose più di altri. Se il pensiero di automatizzare i test getterà la tua squadra in preda al panico che questo metterà il progetto troppo in ritardo, non farlo. D'altra parte, se hanno la sensazione che preferiscono passare il weekend a scrivere test automatici, se ciò significa che non devono più continuare a farlo manualmente (non è per questo che volevamo imparare come programmare?), Che potrebbe essere il strada da percorrere Qual è il prezzo di una squadra felice?

Lavoro in entrambi gli stili contemporaneamente, con il codice legacy accuratamente sottoposto a regressione testata appena prima di un rilascio effettivo e più codice testato con l'automazione.

Se avessi la possibilità di fare una scelta per lavorare in un solo stile, non ci sono contest: automatizza i test ed eseguili tutte le volte che è possibile. La qualità del codice è migliore e i problemi vengono scoperti mentre gli sviluppatori ricordano ancora a cosa stavano pensando. Sono molto più veloci e più facili da risolvere in questo modo.