Criteri di accettazione per Edge Case

Penso che la risposta sia che entrambi dovresti pensare al tuo set di casi limite. Lui come sviluppatore dovrebbe gestire casi limite che sono specifici dei dati come l'arresto anomalo dell'app da un dato input dell'utente, il 5/0 cade sicuramente in questa parte dello spettro. Lo sviluppatore dovrebbe chiederti cosa pensi che sarebbe un messaggio di errore appropriato quando l'input fornito come parte dell'interazione dell'utente porta a qualcosa di non valido.

La tua porzione dello spettro è il lato commerciale delle cose. Come dovrebbe comportarsi la calcolatrice se l'account dell'utente non è autorizzato a utilizzare il pulsante divide? Come dovrebbe comportarsi quando l'account è autorizzato a utilizzare l'operazione Mod ma non ha accesso alla funzione di divisione?

Il messaggio importante che ritengo sia necessario trasmettere e avere l'accettazione da parte di tutti i membri del team è che siete tutti nella stessa squadra. Se il prodotto non è completo, il prodotto è non completo e il team è da incolpare, non un membro dato.

Il team deve lavorare insieme piuttosto che avere un tipo di atteggiamento / mantra "Non è il mio lavoro, non è mia responsabilità"

I criteri di accettazione si presentano sotto forma di:

• Accettazione aziendale
• Accettazione dell'assicurazione della qualità

In genere l'accettazione aziendale di solito risponde alla domanda:

• La funzione che è stata implementata fa ciò che voglio che faccia?

La funzione avrà una serie di requisiti orientati al business, come se premessi questo pulsante mi aspetto che questa azione si verifichi. Elencherà gli scenari di attività previsti e il comportamento previsto, ma non coprirà i casi tutti possibili.

Si prevede che i requisiti aziendali debbano essere definiti prima di un'iterazione in modo che l'assicurazione della qualità possa sviluppare qualsiasi requisito tecnico non aziendale. La garanzia della qualità dovrebbe sviluppare casi distruttivi e casi limite, se necessario.

Entrambi i gruppi di requisiti dovrebbero essere rivisti prima di iniziare qualsiasi lavoro sulla storia, in modo che possa essere stimata una stima e un impegno formale per l'unità di lavoro. Una volta fatto, è possibile elaborare la funzione / le storie. A questo punto, tutti sono chiari su ciò che deve essere consegnato sia dal punto di vista aziendale che tecnico.

La storia raggiunge l'accettazione definitiva una volta che i membri del team aziendale e dell'assicurazione qualità firmano la storia. Ciò dovrebbe accadere durante l'iterazione sia per l'accettazione commerciale che per l'accettazione della garanzia di qualità. Questa è la definizione di done (DoD) che segnala che è possibile avviare un ulteriore lavoro sulla trama.

Eventuali nuovi risultati possono essere registrati come difetti o picchi aggiuntivi della storia. In un mondo perfetto questo non accadrebbe mai, ma in realtà di solito c'è una certa quantità di "scoperta" che si verifica quando si lavora su una caratteristica / storia. Questo è naturale.

Il team dovrebbe collaborare (business, QA, sviluppatore) per eliminare qualsiasi tipo di richiesta di scoperta nebulosa. Se questo è agile, dovrebbero essere tutti seduti allo stesso tavolo per favorire la comunicazione e una rapida risoluzione a qualsiasi domanda possa sorgere. Dovrebbe andare in questo modo:

QA:

"Hey, Developer we should handle this particular scenario. I've discovered that if I input this data I get an error."

DEV:

"That wasn't covered in any requirement, but we can add some additional functionality to cover this. OK, Hey Business Person, how would > you like the application to behave for this case?"

BUSINESS:

"Let's show our standard error message and let the user try again for this scenario. How much additional effort will then be?"

DEV:

"It will be easy, only an extra hour or two. I can commit to for this iteration. QA please update your acceptance criteria for this scenario, we don't need an additional story for this. Thanks!"

O se è un lavoro molto, una nuova storia viene aggiunta al backlog. Il team può ancora accettare la storia originale in quanto soddisfa tutti i requisiti originali, quindi riprende la storia degli spike nella successiva iterazione.

Scrivere un software che si comporta in modo robusto di fronte a input errati o ambigui è una parte essenziale del lavoro di uno sviluppatore di software.

Se i tuoi sviluppatori non la vedono in questo modo, includi requisiti non funzionali aggiuntivi nella specifica dei requisiti che specificano esplicitamente questo requisito e fornisci ai tuoi sviluppatori un esempio del tuo processo di test in modo che possano applicare tale processo prima invio del loro codice finale per la revisione.

I test di accettazione dovrebbero essere comunque una parte vitale di qualsiasi documento di requisiti. Se un requisito non indica anche i suoi criteri per l'accettazione, non è davvero un requisito; è un desiderio.

Quello che è successo qui è che hai scoperto valore . Il valore di input non è stato pensato quando è stata scritta la storia (ei criteri di accettazione) o quando è stato scritto il codice. Se non fa parte dei criteri di accettazione, non hai davvero una base per rifiutare la storia.

Ciò che faremmo nel mio team è:

1. Crea un bug con i dettagli del comportamento previsto ed effettivo.
2. Aggiorna i criteri di accettazione in modo che il nuovo requisito trovato sia documentato.
3. Dai la priorità al bug insieme a tutte le altre storie e bug nella prossima iterazione.

Il vantaggio qui è che sei costretto a considerare se correggere questo bug è la prossima cosa più importante da fare. Potrebbe essere o non essere abbastanza importante da risolvere, ma è importante che il suo valore sia considerato.

Ovviamente, devi ancora trovare un modo per incoraggiare gli sviluppatori (e te stesso) a esplorare questi casi limite in anticipo. Se la tua squadra di sviluppo non sta passando del tempo a scomporre le storie, incoraggiali ad avere una sessione di pianificazione dettagliata prima di iniziare a lavorarci.

Alcune osservazioni:

...when I reject his stories

Non conosco la tua cultura lavorativa o processo, ma per me rifiutare una storia è un passo severo. Se fossi lo sviluppatore, genererei anche il respingimento, poiché è un'azione registrata che riflette male su di me e sulla squadra.

He says its unfair since I don't specify the edge cases.

È ingiusto da parte sua aspettarsi che tu conosca tutti i casi limite. Ma allo stesso tempo, è ingiusto che tu te lo aspetti. Ogni cambiamento ha dei rischi e, man mano che vengono scoperti i problemi, è necessario lavorare insieme come una squadra per affrontarli.

I don't know his design for the story until after he implements it

Non dovresti conoscere il design. Può essere utile conoscere il design al fine di formulare ipotesi iniziali su quali storie sono più facili o più difficili per la gestione del backlog. Ma evita di intrappolare lo sviluppatore nel tuo progetto quando scrivi storie. Ti prende tutto il divertimento quando sei semplicemente una tastiera a comando vocale per il PO.

Sembra che voi ragazzi dovreste lavorare sul miglioramento dei processi e fare un po 'di team building. Alcune cose che potrei suggerire per il processo:

• Suggerisci che gli sviluppatori includano il tempo nella storia alla copertina che fissa i casi limite scoperti. Diamine, rendilo parte di ogni storia utente. Questo è facilmente difendibile attraverso l'obiettivo di 0 nuovi bug introdotti. Il problema è che il dev non lo sta pianificando al momento. Ed è fuori dal tempo in cui scopri i problemi. Ci vorrà del tempo in entrambi i casi, quindi mettilo nella storia in cui è visibile durante la pianificazione.
• Dopo il test (e grazie per il test a proposito!), invia al dev un elenco di problemi rilevati. La fissazione di tali questioni andrà contro la condizione di soddisfazione "casi limite".
• Se qualcosa rimane non fissato o viene scoperto troppo tardi, decidi se la storia deve essere spinta in base al fatto che il caso d'uso possa essere soddisfatto. Succedono problemi noti e soluzioni. Li ha divulgati nelle note di rilascio e creare nuove storie per risolverli.
• Se c'è un particolare punto critico nel processo che genera il pushback, quindi cambia il tuo processo! Dopo tutto, il miglioramento dei processi è parte di Scrum. Ad esempio, se il tuo sviluppatore si arrabbia quando rifiuti la storia, allora suggerisci al team una modifica in corso in modo che il rifiuto non scateni le correzioni. Esegui test e correzioni prima di Fine e Rifiutati.
• Lavora con il team e ciò che hanno prodotto e fai il miglior uso possibile. Non fanno il lavoro perfetto e nemmeno tu. Quindi pianificalo. I miei team sono di solito degli sviluppatori, quindi abbiamo una User story di Supporto non pianificato ogni sprint per problemi emergenti ... pianificazione per l'in-plan-able.

I requisiti dovrebbero essere chiari e concisi. Se non lo sono, allora succede esattamente quello che ti è successo. È colpa tua e la cosa peggiore che puoi fare quando si specificano i requisiti è di assumere le cose.

Esempio specifico, circa la divisione per zero. Se non hai specificato che vuoi registrare l'errore, non lamentarti se lo sviluppatore ne stampa 100 come risultato.

Ma in questi casi, vorrei semplicemente colmare le lacune mancanti e passarle allo sviluppatore. Dopo tutto, i bug nei requisiti si verificano.