Integrazione del QA all'interno di sprint agili [duplicato]

Question

Integrazione del QA all'interno di sprint agili [duplicato]

#1 da (2 voti)
#2 da (2 voti)

1

Ho lavorato in "Agile" per un po 'e sto lavorando per orientarmi maggiormente verso una nuova società. Uno dei problemi che ho sempre incontrato è l'effettiva integrazione del QA all'interno dello sprint.

Abbiamo fatto meglio a portare le storie al QA prima e ad accorciare il ciclo di feedback, ma nell'esempio di uno sprint di 2 settimane era sempre inevitabile che le ultime storie arrivassero a QA in ritardo nello sprint, quindi il QA sarebbe finire i test all'interno dello sprint ma cosa fa lo sviluppatore? Hanno finito e hanno consegnato tutte le loro storie, a meno di tutto ciò che torna dal QA / UAT. Come ci assicuriamo che non si stiano solo giocherellando con i pollici per l'ultimo giorno? 2 giorni di uno sprint?

agile sprint qa

posta Kaitlyn2004 25.02.2015 - 17:39

fonte

2 risposte

Leggi altre domande sui tag agile sprint qa

Come mantieni i pattern (anti) del software organizzati? [chiuso] C # se affermazioni

score 2 · Answer 1

Gli sviluppatori e il controllo qualità devono lavorare entrambi fino alla fine dello sprint.

Gli sviluppatori possono trascorrere l'ultimo giorno / poche ore lavorando sul feedback del QA, eseguendo i propri test unitari, revisionando o refactoring il codice, ecc. presumendo che non ci sia abbastanza tempo per inserire storie dal backlog.

Il QA, naturalmente, passerà l'ultima volta nel test di sprint, con un feedback alla fine che passerà allo sprint successivo.

Se alla fine dello sprint non c'è davvero nulla da fare, le persone possono prendersi un meritato pranzo lungo, magari iniziare a raccogliere pensieri per la retrospettiva sugli sprint, o una pianificazione ad alto livello per il prossimo sprint. Anche la revisione del codice (sviluppatori) e il test (QA) non fanno mai male.

score 2 · Answer 2

Se lo stai facendo bene, il carico di sviluppo verso la fine dello sprint dovrebbe essere più leggero. Se non funziona, lo sviluppo risolve i bug e cerca di chiudere i racconti.

Alcune opzioni sono:

Preparazione per il prossimo sprint. Mi piace che il team abbia una buona idea di cosa potrebbe essere nel prossimo sprint e pensi alle storie e ai probabili compiti. In questo modo lo sprint planning non è una grande sorpresa per loro.
Giorni dell'innovazione: scegli un argomento pertinente, esegui ricerche e presentalo. Questo può funzionare se guidato e può essere una buona occasione per spingere il prodotto in avanti e dare anche agli sviluppatori la possibilità di brillare.
Gli sviluppatori eseguono test case - i team dovrebbero essere cross-funzionali, giusto? Se c'è un collo di bottiglia per il QA, perché non tutto il team lavora per spostarlo?