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

9

Un po 'di me - Sono un tester manuale per quasi 2 anni in un ambiente Agile usando SCRUM (sprint di 1-2 settimane). Quindi voglio introdurre test di automazione nel mio lavoro usando Selenium WebDriver (con Java).

La mia domanda è durante quando devo testare manualmente la funzionalità e quando devo convertirli per i test di automazione?

Ho letto e ottenuto un approccio diverso, come ad esempio:

All'inizio di un nuovo sprint, converti le storie utente in script automatici dallo sprint precedente, OPPURE;
Converti le storie utente all'interno dello stesso sprint.

Qualsiasi consiglio / i sarebbe molto apprezzato. Grazie in anticipo.

— ghiandaia
fonte

4

Si prega di non inviare la stessa domanda su due diversi siti di scambio di stack. Per favore cancellane uno.

— R Sahu,

2

Cross postato su sqa.stackexchange.com/questions/27017/… .

— R Sahu,

13

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

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

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

L'agilità organizzativa è limitata dall'agilità tecnica

In altre parole, quando sei lento ad apportare modifiche al tuo prodotto, non importa come strutturi i tuoi team, la tua organizzazione o quale struttura adotti, sarai lento a rispondere alle modifiche.

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

Se rinvii il test a un'altra iterazione, rimarrai sempre indietro. Rendendo più difficile cambiare la direzione del prodotto in quanto è più difficile riformattare e salvaguardare il comportamento esterno del prodotto. Avere qualsiasi test manuale ripetitivo è la chiave per rallentarti, automatizzarlo!

Molti tester ti diranno che non dovresti iniziare il test end-to-end fino a quando l'interfaccia del prodotto non si sarà stabilizzata. Non aspettare, invece fai buon uso di PageObjects e assicurati che i tuoi test siano mantenibili e rendili responsabilità dello sviluppatore crearli e correggerli.

— Niels van Reijmersdal
fonte

Non sono d'accordo sul primo "dovrebbe". La definizione di done è qualcosa che il team Scrum deve elaborare da solo. Se il team considera importanti i test automatizzati, li includerà come parte della loro definizione. Tuttavia, il processo stesso non dice che devono, o addirittura che dovrebbero. È qualcosa che dipende interamente dalla squadra e non esiste una risposta giusta, sbagliata o preferita.

— aroth

@aroth Sono d'accordo con te, ma in quasi tutti i casi costruisci un prodotto software più grande che vuoi aggiungere test al DoD. Perciò penso che sia bello dire alle persone che dovresti, almeno seriamente pensarci. Come tester credo che i test alla fine da parte di un team separato siano i primi passi per Wagile. Sì, ci sono situazioni e / o casi in cui i test potrebbero non essere nemmeno necessari.

— Niels van Reijmersdal,

2

La cosa fondamentale è che non contrassegni una storia come completa se non hai scritto test automatici per quella storia.

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

— Ewan
fonte

Quindi se nella prima settimana di un nuovo sprint non ci sono storie utente di quello sprint in uno stato che può essere testato per la regressione, suggerisci che l'OP dovrebbe tornare a casa e non fare nulla? Non mi sembra molto efficiente ;-)

— Doc Brown,

Tester dovrebbe usare quella prima settimana per mettere in discussione la specifica "hmmmm come utente mi aspetterei musica di sottofondo sulla mia pagina web .." trovare bug in storie incomplete e generalmente creare problemi. Gli sviluppatori sono autorizzati a dire che non possono iniziare fino a quando non verranno scritti i piani di test

— Ewan,

@DocBrown: nella prima settimana di un nuovo sprint il tester ha un'incredibile quantità di lavoro da svolgere. Devono capire cosa stanno costruendo gli sviluppatori lavorando con il proprietario del prodotto e gli sviluppatori. Devono collaborare con lo sviluppatore per assicurarsi che il codice sia testabile. Possono iniziare a lavorare su un piano di test automatizzato. Possono persino iniziare a scrivere alcuni test. Se disponi di un framework di test adeguato in cui i test sono scritti con un alto livello di astrazione, puoi scriverli prima che il codice sia pronto.

— Bryan Oakley,

1

Idealmente, dovresti scrivere test automatici nello stesso sprint in cui è scritto il codice. Il codice non deve essere considerato "fatto" fino a quando non sono stati scritti i test automatici e alla fine di uno sprint è necessario portare il codice in uno stato "fatto".

Dovresti iniziare il processo il primo giorno dello sprint collaborando con lo sviluppatore per comprendere il codice e aiutarlo a comprendere le tue esigenze di tester. Ad esempio, se stai creando pagine Web, puoi aiutarle a comprendere la necessità di aggiungere identificatori univoci per ogni elemento di pagina con cui devi interagire.

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

— Bryan Oakley
fonte

0

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

— Martin Maat
fonte

1

Ciò non funziona con strumenti di test dell'interfaccia utente come il selenio. È necessaria un'interfaccia utente funzionante e stabile per poter creare i test.

— Doc Brown,

@DocBrown: non penso sia necessariamente vero. Se mi dai una specifica per una nuova pagina Web, posso iniziare (e forse finire!) A scrivere test automatici prima che la pagina venga scritta. Devi semplicemente collaborare con lo sviluppatore in modo che entrambi siano d'accordo su quale sia la struttura della pagina, quali siano gli ID elemento e così via.

— Bryan Oakley,

0

Puoi fare entrambe le cose, ma in genere desideri indirizzare i test di regressione con i test di automazione. Ciò significherebbe che farei il manuale fino a quando non sarai sicuro che sia abbastanza solido per essere un test di regressione. Questo potrebbe essere nel mezzo di uno sprint per alcune funzionalità e potrebbe essere in uno sprint futuro per altre funzionalità.

— cane bastardo
fonte

0

Come affermato in un'altra risposta , quando si verificano i test dovrebbe far parte della definizione di done . Tuttavia, non sono d'accordo con alcune di quelle risposte, quindi volevo espandermi con le esperienze che ho incontrato.

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

Quello che consiglierei sarebbe di fare un po 'di approccio ibrido. Per la tua definizione di fatto, direi che i test manuali dovrebbero far parte dello Sprint in cui è codificato il lavoro. Sai che funziona e che eventuali bug possono essere immediatamente segnalati, possibilmente corretti, prima che lo Sprint sia finito in modo da poter 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 molto da fare, puoi impostare i tuoi test automatizzati che possono essere eseguiti come parte del processo di compilazione per prevenire errori di regressione.

— krillgar
fonte

Non ho mai visto uno sprint in cui non ci fosse già molto da fare sugli attuali obiettivi dello sprint il primo giorno. Scrivere test automatizzati richiede collaborazione e pianificazione e ciò dovrebbe iniziare nella prima ora del primo giorno dello sprint.

— Bryan Oakley,