Come adattare i test agli sprint Scrum e come scrivere le storie degli utenti in Scrum

Sono il capo del team di sviluppo di un nuovo progetto nella mia azienda. Questo è il primo progetto in cui la società utilizzerà Scrum. Abbiamo un SDLC a cascata / iterativo. I BA scrivono documenti sui requisiti, passano a dev e test, dev iniziano a svilupparsi e rilasceranno ai test nelle iterazioni. I tester impiegano molto tempo per testare una versione in base alla quale gli sviluppatori continuano lo sviluppo ma anche correzioni di bug per la versione corrente. Ho alcune domande

1. In uno sprint con diciamo 5 storie, quando rilasci per i test? È appena una storia è completata da dev o dopo che tutte le storie sono state completate, ma prima della fine dello sprint, dando il tempo necessario per testare.
2. Se il BA scrive le storie degli utenti, quali dovrebbero essere i dettagli. Tradizionalmente ci vuole molto tempo per scrivere una specifica con tutto il layout dell'interfaccia, il comportamento, il testo ecc. Da finalizzare. Immagino che la mia domanda sia come scrivere storie che siano implementabili e verificabili.
3. Il nostro team di test non è tecnico. Quanto è importante disporre di test automatici dell'interfaccia utente per Scrum. L'interfaccia utente si basa su WPF.

Ho una solida esperienza di sviluppo con metodi agili (TDD, recensioni di codici, refactoring ecc.) Ma nuovo per la mischia.

modifica: Per iterazioni intendo che se ci sono 100 requisiti potremmo rilasciare ai test una volta completati i requisiti 30, 35, 35 anziché attendere il completamento di tutti i 100 requisiti.

Se i test sono separati dallo sviluppo, hai due team di scrum separati. È una cattiva idea far lavorare una mano all'altra.

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

In uno sprint ... quando rilasci per il test?

Al termine dello sprint. Totalmente fatto. Ciò significa che hai effettuato i test delle tue unità e sei sicuro che funzioni. Al termine del team di sviluppo, lo si rilascia ad altri team per "test" o "implementazione" o qualsiasi altra cosa accada nell'organizzazione.

Immagino che la mia domanda sia come scrivere storie che siano implementabili e verificabili.

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

Quanto è importante disporre di test automatici dell'interfaccia utente per Scrum.

Essenziale. Completamente richiesto per qualsiasi sviluppo dell'interfaccia utente. Gli sviluppatori devono eseguire tutti i test da soli prima di essere consegnati al "team di test". Se c'è un'interfaccia utente, devono testarla. Se non è presente l'interfaccia utente, non è richiesto il test automatico dell'interfaccia utente. È richiesto il test ed è necessario testare un'interfaccia utente. I test automatici sono le migliori pratiche attuali.

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

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

1. Nella tipica Scrum non esiste una fase di test separata, perché i test formali dovrebbero avvenire durante l'intero sprint. Quando uno sviluppatore termina una User Story, la risorsa QA dovrebbe già aver preparato i suoi casi di test e iniziare i test a quel punto. Se i loro casi di test superano, accettano la user story e passano a quella 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à. Ulteriore sviluppo dovrebbe seguire le linee guida TDD per garantire che il test di regressione sia il più rapido e indolore possibile.

2. È una buona idea per i BA scrivere storie utente, ma per un controllo più dettagliato e specifico, le User Story possono accompagnare i documenti sui 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 attualmente soddisfa tutti gli aspetti di tale esigenza, la storia dell'utente viene soddisfatta. Le storie utente possono essere costituite da storie utente figlio e attività assegnabili. Potrebbero esserci sovrapposizioni in Attività per più storie utente.

3. I test automatici dell'interfaccia utente possono essere una buona cosa, ma personalmente ritengo che sia più importante uno sforzo maggiore sui metodi TDD e una copertura del test unitario al 100% di tutta la business logic. La maggior parte dei team di sviluppo software non sembra riuscire a raggiungere il 100% di copertura della logica di business, quindi secondo me i test UI automatizzati sarebbero una perdita di tempo prezioso che potrebbe essere utilizzata per scrivere più unit test per BL. Secondo me è un lusso non un bisogno.

1. In Scrum, dovresti produrre un incremento software potenzialmente spedibile alla fine di ogni sprint. Di conseguenza, Scrum promuove il concetto di intero team o team interfunzionale in cui deve essere presente nel team ogni abilità necessaria per condurre una determinata storia utente.

   Nel mio progetto attuale, poiché una storia completamente testata fa parte della nostra definizione di fatto, abbiamo integrato tester nei team. Durante i primi giorni di uno sprint, mentre gli sviluppatori iniziano a lavorare sui primi user story, i tester prepareranno scenari di test e configureranno alcuni dati di test. Non appena lo sviluppatore di una delle storie utente è finito, lo testeranno.

2. Questa è una delle maggiori difficoltà di Scrum IMO. Devi trovare la giusta quantità di specifiche necessarie per ottenere una user story implementabile e testabile. Troppe analisi iniziali, documentazione e specifiche risulteranno in un piano rigido che si rivelerà inevitabilmente sbagliato nel corso dello sprint. Al contrario, una user story che non è stata chiaramente definita ed espressa dal Product Owner porterà a una saturata larghezza di banda di comunicazione tra gli sviluppatori e l'OP durante lo Sprint e ritardi nello sviluppo mentre l'OP prende decisioni sulle user story a metà dello sprint .

   Nel nostro caso, abbiamo definito la giusta quantità di dettagli affinché una user story sia 1 / una descrizione sotto forma di "come ... voglio ... così che ..." e 2 / una serie di accettazione criteri. Raramente realizziamo modelli dell'interfaccia utente in anticipo, ciò può accadere durante le pianificazioni degli sprint, ma sono più schizzi che vengono successivamente scartati.

3. Nella mia esperienza, il test automatico dell'interfaccia utente richiede molto tempo ed è estremamente fragile. Ci sono modi per farlo in WPF, ma pondererei attentamente il costo di mantenimento di tali test con i vantaggi prima di procedere in quel modo.

Lavorare in iterazioni sempre più brevi rende tutti questi passaggi sempre più costosi. Puoi ridurre questi costi seguendo una regola stupida e semplice: riduci le dimensioni dei lotti a metà, cambia il modo in cui lavori per renderlo comodo, ripeti fino a quando non sei felice.

Prendi 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 testando tutte e 5 le storie, la dimensione del lotto è di 5 storie. Taglialo a metà. Nel prossimo sprint, lavora prima sulle 3 storie più urgenti, preparandole per i test il prima possibile. Mentre i tester stanno testando quelle 3 storie, le altre 2 possono essere pronte per essere testate. Ciò causerà alcuni dolori della crescita. Cambia il tuo modo di lavorare per renderlo più comodo.

Ad esempio, più persone lavoreranno insieme su ogni storia, quindi prova più accoppiamenti e vedi se questo ti aiuta a lavorare in modo più costante. O, forse, i tester troveranno problemi nella storia 2 che distraggono alcuni programmatori mentre stanno cercando di lavorare sulla storia 5, quindi incoraggia i programmatori e i tester al prossimo sprint a discutere in precedenza come testare una delle storie nel "primo batch "in modo che i programmatori abbiano meno probabilità di commettere un errore che un tester può facilmente intercettare con un test.

Potrebbero essere necessari alcuni sprint per risolvere i grandi problemi associati ai tester che testano una piccola serie di storie mentre i programmatori lavorano alla successiva serie di storie. Quando diventa comodo, tagliare di nuovo la dimensione del lotto a metà. E di nuovo. Entro un anno o giù di lì, il team proverà comodamente storie mentre i programmatori credono 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 il "quanti dettagli i BA dovrebbero scrivere per le storie?" problema.

A proposito: per consentire ai tester di ridurre i tempi di consegna, dovranno adottare un po 'di automazione, attraverso una combinazione di apprendimento su come automatizzare e programmatori che li aiutano ad automatizzare. Mentre provi a ridurre le dimensioni del batch, scoprirai quando è necessario risolvere questi problemi. Non aggiungere automazione solo perché un libro dice che ne hai bisogno.

Spero che ti aiuti.

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

In uno sprint con diciamo 5 storie, quando rilasci per i test? È appena una storia è completata da dev o dopo che tutte le storie sono state completate, ma prima della fine dello sprint, dando il tempo necessario per testare.

Per ogni grande user story, dovrebbe essere suddiviso in molte attività secondarie e quando le attività secondarie sono completamente eseguite dallo sviluppatore, dovrebbero essere rilasciate al controllo qualità per essere testate immediatamente. Il difetto deve essere corretto dopo il test per tali sottoattività completare il test.

Se il BA scrive le storie degli utenti, quali dovrebbero essere i dettagli. Tradizionalmente ci vuole molto tempo per scrivere una specifica con tutto il layout dell'interfaccia, il comportamento, il testo ecc. Da finalizzare. Immagino che la mia domanda sia come scrivere storie che siano implementabili e verificabili.

In Scrum, le storie degli utenti dovrebbero essere in qualsiasi formato purché si verifichino conversazioni che circondano le storie e non dovrebbero essere completate o statiche. Una piccola storia, chiamata semplicemente una user story, è 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 l'utente concordi è importante. Queste sono attività di PO.

Il nostro team di test non è tecnico. Quanto è importante disporre di test automatici dell'interfaccia utente per Scrum. L'interfaccia utente si basa su WPF

L'applicazione dei test di automazione in Scrum è un'attività piuttosto difficile. Perché tutte le funzioni sono implementate in modo incompleto e non molto stabile per consentire al controllo qualità di implementare il caso di test tramite alcuni strumenti di auto-test. Dovrebbe essere fatto per uno sprint chiamato: regressione.