Come adattare i test in Scrum Sprint e come scrivere storie utente in Scrum

Se il test è separato dallo sviluppo, hai due team scrum separati. È una cattiva idea avere una mano per l'altra.

I tuoi sviluppatori devono scrivere i propri test, separati da questo altro team. Devi trattare questo altro team di "test" come i tuoi clienti.

In a sprint ... when do you release for testing ?

Quando lo sprint è finito. Completamente fatto. Ciò significa che hai eseguito i test delle tue unità e sei sicuro che funziona. Una volta completato il tuo team di sviluppo, lo rilascerai ad altri team per "test" o "distribuzione" o qualsiasi altra cosa succeda nell'organizzazione.

I guess my question is how to write stories that are implementable and testable.

Questo varia da squadra a squadra. Il BA fa parte del team di sviluppo. Devi lavorare su questo come team (sviluppatori BA più) per ottenere la giusta quantità di dettagli. È uno sforzo di squadra per ottenere le informazioni giuste da BA al resto del team.

How important it is to have automated UI testing for Scrum.

Essential. Completamente richiesto per qualsiasi sviluppo dell'interfaccia utente. Gli sviluppatori devono eseguire tutti i test stessi prima vengono dati al "team di test". Se c'è un'interfaccia utente, devono testarla. Se non esiste un'interfaccia utente, non è necessario eseguire il test dell'interfaccia utente automatico. È richiesto un test e un'interfaccia utente deve essere testata. I test automatici sono la migliore pratica corrente.

Linea di fondo. Un team separato di "test" e un BA che scrive ogni piccolo dettaglio non è un'organizzazione ottimale per Scrum. Scrum significa che devi ripensare alla tua organizzazione e ai tuoi processi.

La maggior parte delle risposte che fornirò si riferiscono a un metodo Agile di sviluppo software rispetto a un metodo Iterative Waterfall. Scrum sembra essere una popolare implementazione Agile.

1. Nel tipico Scrum non esiste una fase di test separata, poiché i test formali dovrebbero avvenire durante l'intero sprint. Quando uno sviluppatore termina una User Story, la risorsa QA dovrebbe già preparare i suoi casi di test e iniziare a testare a quel punto. Se passano i loro casi di test, accettano la storia dell'utente e passano alla successiva. Una volta che tutte le User Story sono state completate e accettate, lo sprint è finito e inizi il successivo. Tutto dipende ovviamente dall'integrazione continua, quindi le modifiche allo sviluppo sono immediatamente disponibili per il controllo qualità. Ulteriori sviluppi dovrebbero seguire le linee guida TDD per garantire che i test di regressione siano il più rapidi e indolore possibile.

2. È una buona idea per BA scrivere storie di utenti, ma per un controllo più dettagliato e specifico, le User Story possono accompagnare i documenti dei Requisiti formali. La User Story dovrebbe essere scritta dal punto di vista di un singolo utente per ruolo. Esprime un'esigenza dal punto di vista dell'utente, quindi in modo abbastanza naturale se il software soddisfa attualmente tutti gli aspetti di tale necessità, allora la storia dell'utente viene soddisfatta. Le storie degli utenti possono essere composte da storie di utenti secondari e attività assegnabili. Potrebbero esserci sovrapposizioni in Attività per più storie di utenti.

3. I test dell'interfaccia utente automatizzati possono essere una buona cosa, ma personalmente ritengo che sia più importante uno sforzo maggiore sui metodi TDD e una copertura del 100% dei test unitari di tutta la Business Logic. La maggior parte dei team di sviluppo software non sembra avere una copertura del 100% di Business Logic, quindi secondo me il test automatico UI sarebbe uno spreco di tempo prezioso che potrebbe essere utilizzato per scrivere più test unitari per BL. È un lusso che non è necessario secondo me.

Lavorare in iterazioni più brevi e più brevi rende tutti questi handoff sempre più costosi. Puoi ridurre questi costi seguendo una regola stupida e semplice: taglia le dimensioni del lotto a metà, cambia il modo di lavorare per renderlo constrongvole, ripeti fino a renderlo felice.

Porta il tuo esempio di sprint a 5 piani. Se i tuoi team sono abituati a scrivere il codice per tutte e 5 le storie, quindi testare tutte e 5 le storie, la dimensione del batch è di 5 storie. Taglia quello a metà. Nel prossimo sprint, lavora prima sulle 3 storie più urgenti, preparandole a testare il prima possibile. Mentre i tester testano queste 3 storie, il resto può preparare le restanti 2 storie per i test. Ciò causerà alcuni dolori in crescita. Cambia il modo di lavorare per renderlo più constrongvole.

For example, more people will work on each story together, so try more pairing and see if that helps you work more steadily. Or, perhaps, the testers will find problems in story 2 that distracts some programmers while they're trying to work on story 5, so encourage the programmers and testers next sprint to discuss earlier how to test one of the story in the "first batch" so that the programmers are less likely to make a mistake that a tester can easy catch with a test.

Potrebbero essere necessari alcuni sprint per risolvere i grossi problemi associati ai tester che testano una piccola serie di storie mentre i programmatori lavorano alla prossima serie di storie. Una volta che diventa constrongvole, tagliare di nuovo le dimensioni del lotto a metà. E di nuovo. Entro un anno circa, il team testerà comodamente le storie poiché i programmatori ritengono di aver finito con loro e probabilmente facendo meno errori lungo la strada. Ogni storia sarà fatta prima.

Naturalmente, a questo punto, ora puoi fare la stessa cosa con i batch che il team riceve dai proprietari del prodotto o che il team spedisce all'organizzazione operativa. E così via. A questo punto, puoi affrontare "quanti dettagli dovrebbero scrivere i BA per le storie?" problema.

A proposito: affinché i tester siano in grado di ridurre i tempi di risposta, dovranno adottare un po 'di automazione, combinando l'apprendimento automatico e i programmatori che li aiutano ad automatizzare. Mentre cerchi di ridurre le dimensioni del batch, scoprirai quando è necessario risolvere questi problemi. Non aggiungere l'automazione solo perché un libro dice che ne hai bisogno.

Spero di aiutarti.

Voglio solo condividere alcune esperienze come di seguito, spero che sia utile per te.

In a sprint with say 5 stories when do you release for testing ? Is it as soon as a story is completed by dev or after all stories are completed but before end of sprint giving test the required time to test.

Per ciascuna grande storia di utenti, dovrebbe essere suddivisa in molte sotto-attività e quando le sotto-attività sono completamente svolte dallo sviluppatore, dovrebbero essere rilasciate a QC per essere testate immediatamente. Il difetto dovrebbe essere corretto dopo il test per le attività secondarie che terminano il test.

If the BA writes user stories what should be the detail. Traditionally it takes long time to write a spec with all UI layout, behaviour, text etc to be finalised. I guess my question is how to write stories that are implementable and testable.

In Scrum, le storie degli utenti dovrebbero essere in qualsiasi formato, purché le conversazioni che circondano le storie si verifichino e non siano previste che siano completate o statiche. Una piccola storia, chiamata semplicemente una user story, è una storia ben compresa e può essere implementata in uno sprint.  La priorità di una storia può essere basata sul ROI, sul valore aziendale o su qualsiasi altra cosa che l'utente è d'accordo. Questa è attività per PO.

Our test team is non-technical. How important it is to have automated UI testing for Scrum. The UI is based on WPF

Applicare i test di automazione in Scrum è un'attività piuttosto difficile. Poiché tutte le funzioni sono implementate in modo incompleto e non sono realmente stabili per consentire a QC di implementare il caso di test con uno strumento di auto-test. Dovrebbe essere fatto per uno sprint chiamato: regression.