Come si integra il test in un processo Scrum? [duplicare]

but the business wants to know when users stories are complete

Non è fatto fino a quando il cliente non dice che è fatto: qualsiasi altra definizione di "fatto" è delirante. I test di accettazione degli utenti sono i criteri di successo per una user story: ecco perché vengono definiti "user story" e non "storie di gestione".

In genere, la definizione di fatto include più di quello che stai includendo, come test di integrazione, test di accettazione e documentazione (sia orientata allo sviluppatore che orientata all'utente). Una volta superati i test unitari, è possibile integrare la nuova funzione / componenti ed eseguire test di integrazione. Una volta integrata la funzione, si eseguono i test di accettazione. Una volta superato il test di accettazione, è possibile assicurarsi che la documentazione rifletta eventuali modifiche recenti e che la funzionalità sia stata eseguita. Un problema è che il test di accettazione non dovrebbe essere una priorità per un rilascio, ma una priorità per verificare e convalidare il completamento di una storia.

Per quanto riguarda la valutazione, la tua stima dovrebbe includere qualsiasi cosa, dalla convalida della storia dell'utente al test di accettazione. Se non si tiene conto di tutte le attività e le attività necessarie per completare, integrare, verificare e convalidare completamente la storia utente, la stima non aggiunge quel valore. Potrebbe essere una funzione abbastanza semplice da creare e testare, ma incredibilmente difficile da integrare con il tuo progetto attuale, il che significa che altre funzionalità devono essere refactored e testate nuovamente. Non tenere conto di ciò significa che il tracciamento della velocità sarà disattivato.

Consiglierei di sedere con gli utenti o con la gestione appropriata e di approfondire questo problema in modo molto più dettagliato. Lo sviluppo di software professionale significa che fai test, anche per le storie degli utenti.

Devi renderlo una priorità. È sempre più facile non risolvere il problema e continuare a scrivere più codice e offrire più funzionalità. Tuttavia questo non è un software che conta e su cui può essere contato, se parte del processo di controllo qualità non funziona.

Concentrati sui vantaggi del processo e a lungo termine. "Cambiare il tuo olio richiede tempo", ma non lo metti per sempre o all'improvviso, un giorno, si ottiene una brutta sorpresa! Quindi pianifichi manutenzione, test, qualunque cosa sia solo parte del processo di sviluppo del software. Dato che stai provando a cambiare un sistema esistente, ti consiglio di renderlo un po 'più formale all'inizio per far funzionare il processo. Concentrati sui benefici (le persone amano sentire) piuttosto che sui problemi attuali (le persone si mettono sulla difensiva e fanno domande).

Se l'organizzazione non comprende appieno lo sviluppo di software professionale, puoi istruirli o cercare un altro posto che faccia.

L'unica cosa che vorrei "RACCOMANDARE" è implementare test automatici. Per esempio; Se stai testando cose in Windows Form o C # o WPF usa White.Core per i test. Ciò ti consentirà di testare nuove implementazioni, build, funzionalità il più rapidamente possibile.

Lavoro come un tecnico di automazione e uso White.Core in C ++ / C # mentre collaudo GUI verificando le correzioni degli sviluppatori prima che l'iterazione sia terminata.

La disconnessione tra i diversi stati di done di solito è una fabbricazione del project management che vuole disperatamente credere che gli sviluppatori possano trasferire completamente il codice a risorse non di progetto per UAT e andare avanti.

Questa non è Scrum. Questo non è Agile. Questo è un Anti-Pattern Agile.

C'è un solo stato di "fatto" per una determinata user story e cioè Accettato . Uno sprint è NON fino a quando ogni story utente assegnata nello sprint non è stata portata fuori ambito per lo sprint o è stata accettata.

Ora uno sviluppatore può essere Completa con una storia utente, il che significa che è pronto per UAT, ma lo sviluppatore non è davvero libero finché la storia dell'utente non è stata accettata poiché un numero di problemi potrebbe essere trovato durante UAT che lo sviluppatore deve affrontare prima della fine dello sprint.

Tutte le fasi del design, della documentazione, dell'implementazione e di tutti i tipi di test devono essere prese in considerazione nella stima di una user story. Il QA o l'entità che deve eseguire l'UAT dovrebbe essere una risorsa di progetto durante la pianificazione dello sprint.