Quale fase di Agile (SCRUM) dovremmo iniziare a creare test di automazione?

L'automazione del test (e tutti gli altri test) dovrebbe far parte della definizione di fatto . Questo al fine di rendere un prodotto potenzialmente spedibile. Puoi spedire se non è stato testato?

I test dovrebbero anche essere un approccio a tutto il team, quindi l'automazione dei test non è responsabilità dei tester. Inizia pensando di testare il prima possibile nel processo.

L'automazione dei test è così importante in Agile perché:

Organizational Agility is constrained by Technical Agility

In other words, when you are slow in making changes to your product, then it doesn’t matter how you structure your teams, your organization or what framework you adopt, you will be slow to respond to changes.

https://less.works/less/technical-excellence/index.html

Se rimandi i test fino a un'altra iterazione, sarai sempre in ritardo. Rendere più difficile cambiare la direzione del prodotto in quanto è più difficile da refactoring e salvaguardare il comportamento esterno del prodotto . Avere test manuali ripetitivi è fondamentale per rallentare, automatizzarlo!

Molti tester ti diranno che non dovresti iniziare a testare end-to-end finché l'interfaccia del prodotto non si sarà stabilizzata. Non aspettare, fai invece un buon uso di PageObjects e assicurati che i tuoi test siano mantenibili e che diventi responsabilità dello sviluppatore creare e correggili.

La cosa fondamentale è che non segna una storia completa a meno che tu non abbia scritto test automatici per quella storia.

Quindi 1 sembra essere fuori, mentre stai scrivendo i test per un'attività completata in uno sprint precedente. e se i test falliscono?

Idealmente dovresti scrivere test automatici nello stesso sprint che il codice è stato scritto. Il codice non deve essere considerato "fatto" fino a quando non sono stati scritti test automatici e si deve ottenere il codice in uno stato "finito" entro la fine di uno sprint.

Dovresti avviare il processo il primo giorno dello sprint collaborando con lo sviluppatore per comprendere il codice e per aiutarli a comprendere le tue esigenze come tester. Ad esempio, se crei pagine Web puoi aiutarle a comprendere la necessità di aggiungere identificatori univoci per ogni elemento di pagina con cui è necessario interagire.

Ricorda che in mischia, il tuo compito non è scrivere test. Il tuo compito è lavorare con il team per completare gli obiettivi di sprint. Ciò significa comunicazione e collaborazione, che dovrebbe accadere molto presto nello sprint. È possibile iniziare a lavorare su progetti di test e piani di test ben prima che il codice sia pronto per essere testato.

Se stai per testare automaticamente potresti anche creare i test in anticipo. Questo ti aiuterà a definire quale comportamento ti aspetti e ti stimoli a pensare come un cliente, dovrebbe rendere il tuo software più utilizzabile alla fine. E potrai beneficiare immediatamente del test mentre stai implementando la funzionalità.

Puoi farlo entrambi, ma in genere vuoi indirizzare i test di regressione con i test di automazione. Ciò significherebbe che farei il manuale finché non sei abbastanza sicuro da essere un test di regressione. Questo potrebbe essere nel bel mezzo di uno sprint per alcune funzionalità e potrebbe essere in uno sprint futuro per altre funzionalità.

Come indicato in un'altra risposta , quando si verifica il test dovrebbe essere una parte di definizione di fatto . Tuttavia, non sono d'accordo con alcune di questa risposta, quindi ho voluto espandere le esperienze che ho incontrato.

In un ambiente veramente agile, tutti sono in grado di fare tutto. Non ci sarebbe qualcuno al 100% dedicato alla sperimentazione, si svilupperebbero anche competenze per aiutare con un lavoro di base dell'interfaccia utente, o qualcos'altro. Tuttavia, viviamo raramente in un mondo ideale.

Quello che vorrei raccomandare sarebbe un approccio un po 'ibrido. Per la tua definizione di Fatto, direi che il test manuale dovrebbe essere parte dello Sprint in cui il lavoro è codificato. Sai che funziona e qualsiasi bug può essere immediatamente segnalato, eventualmente corretto, prima che lo Sprint sia finito, così puoi pianificare il prossimo uno. Concentrandoti sui test manuali, acquisisci familiarità con ciò che il codice dovrebbe fare. All'inizio del prossimo Sprint quando potresti non avere tante cose da fare, puoi impostare i tuoi test automatici che possono essere eseguiti come parte del processo di generazione per prevenire errori di regressione.