Criteri di accettazione per casi limite

Sono un product owner di una squadra agile. Io quando faccio i test di accettazione PO di solito prendo nota di provare alcuni casi limite. Non è raro per me scoprire qualcosa e poi lo riporto agli sviluppatori. Mi rifiuto da uno degli sviluppatori quando rifiuto le sue storie. Dice che è ingiusto dal momento che non specifico i casi limite e come il programma dovrebbe rispondere nei criteri di accettazione, poiché tende a programmare solo ciò che descrivo nella storia. L'ho incoraggiato a chiedermi mentre si imbatte in eventuali casi limite durante la codifica, ma pensa che non sia il suo lavoro pensare attraverso i casi limite, è mio e dovrei fare nuove storie per il prossimo sprint.

A mia difesa, non conosco il suo progetto per la storia fino a quando non l'ha implementata, quindi è difficile iterare tutte le possibilità (la configurazione sarà in un DB o in un file delle proprietà?). Per semplicità, diciamo che abbiamo una storia per aggiungere divisione a un'app calcolatrice. Nel mondo ideale di SCRUM, sarebbe mio dovere aggiungere una "gestione dello scenario diviso per zero" ai criteri di accettazione o dovrebbe lavorare attraverso quei casi mentre si sviluppa in modo che l'app non implichi il 5/0? Per essere chiari, in questo caso non accetterei se l'app si bloccasse duramente su 5/0, ma passerei se registra, stampa DIV0 o qualsiasi altro modo per gestire l'errore ... purché non non andare in crash.

Penso che la risposta sia che entrambi dovreste pensare al vostro set di casi limite. Come sviluppatore dovrebbe gestire casi limite specifici per i dati come l'app si arresta in modo anomalo da qualsiasi input dell'utente, 5/0 rientra sicuramente in questa parte dello spettro. Lo sviluppatore dovrebbe chiederti di cosa pensi possa essere un messaggio di errore appropriato quando l'input fornito come parte dell'interazione dell'utente porta a qualcosa di non valido.

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

Il messaggio importante che ritengo sia necessario trasmettere e ricevere 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 la squadra è responsabile, non un dato membro.

Il team deve lavorare insieme anziché avere un tipo di atteggiamento / mantra "Non il mio lavoro, non la mia responsabilità".

I criteri di accettazione si presentano sotto forma di:

• Accettazione commerciale
• Accettazione della garanzia di qualità

In genere, l'accettazione aziendale risponde generalmente alla domanda:

• La funzione che è stata implementata fa quello che voglio che faccia?

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

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

Entrambe le serie di requisiti devono essere riviste prima di iniziare qualsiasi lavoro della storia in modo che possa verificarsi una stima e un impegno formali per l'unità di lavoro. Fatto ciò, è possibile lavorare sulla funzione / storie. A questo punto tutti sono chiari su ciò che deve essere consegnato sia dal punto di vista commerciale che tecnico.

La storia raggiunge l'accettazione definitiva una volta che i membri del team aziendale e di controllo della qualità sottoscrivono la storia. Ciò dovrebbe avvenire durante l'iterazione sia per l'accettazione delle attività commerciali sia per l'accettazione della garanzia della qualità. Questa è la definizione di done (DoD) che segnala che può essere avviato un lavoro aggiuntivo sulla trama.

Eventuali nuove scoperte possono essere registrate come difetti o picchi di trama aggiuntivi. In un mondo perfetto ciò non accadrà mai, ma in realtà di solito c'è una certa quantità di "scoperta" che si verifica quando si lavora su un film / storia. Questo è naturale

Il team dovrebbe collaborare (business, QA, sviluppatore) per eliminare qualsiasi tipo di esigenza di scoperta nebulosa. Se questo è agile, dovrebbero essere tutti seduti allo stesso tavolo per favorire la comunicazione e la rapida risoluzione di eventuali domande. Dovrebbe andare qualcosa del genere:

QA:

"Ehi, sviluppatore, dovremmo gestire questo particolare scenario. Ho scoperto che se immetto questi dati ottengo un errore."

DEV:

"Questo non era coperto da alcun requisito, ma possiamo aggiungere alcune funzionalità aggiuntive per coprire questo. OK, uomo d'affari, come ti piacerebbe che l'applicazione si comportasse in questo caso?"

ATTIVITÀ COMMERCIALE:

"Mostriamo il nostro messaggio di errore standard e lasciamo che l'utente riprovi per questo scenario. Quanto ulteriore sforzo sarà quindi?"

DEV:

"Sarà facile, solo un'ora o due in più. Posso impegnarmi per questa iterazione. QA per favore aggiorna i tuoi criteri di accettazione per questo scenario, non abbiamo bisogno di una storia aggiuntiva per questo. Grazie!"

O se è molto un lavoro, una nuova storia viene aggiunta al backlog. Il team può ancora accettare la storia originale in quanto soddisfa tutti i requisiti originali e quindi riprendere la storia del picco nella prossima iterazione.

Scrivere software che si comporti 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 ulteriori requisiti non funzionali nella specifica dei requisiti che affermano esplicitamente questo requisito e fornisci ai tuoi sviluppatori un esempio del processo di test in modo che possano applicare tale processo da soli prima di inviare il loro finale codice per la revisione.

I test di accettazione dovrebbero comunque essere una parte vitale di qualsiasi documento sui requisiti. Se un requisito non specifica anche i suoi criteri di accettazione, non è realmente un requisito; è un desiderio.

Quello che è successo qui è che hai scoperto il valore . Il valore di input non è stato pensato quando è stata scritta la storia (e i 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.

Quello che faremmo nella mia squadra è:

1. Crea un bug che dettaglia il comportamento atteso e reale.
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 o meno questo bug è la prossima cosa più importante da fare. Può essere o meno abbastanza importante da risolvere, ma è importante che il suo valore sia preso in considerazione.

Ovviamente, devi ancora trovare un modo per incoraggiare gli sviluppatori (e te stesso) ad esplorare questi casi limite in anticipo. Se il tuo team di sviluppo non sta trascorrendo del tempo a scomporre storie, incoraggiali a tenere una sessione di pianificazione dettagliata prima di iniziare a lavorare su di loro.

Alcune osservazioni:

... quando rifiuto le sue storie

Non conosco la cultura o il processo del tuo lavoro, ma per me rifiutare una storia è un passo grave. Se fossi lo sviluppatore, genererei anche un respingimento in quanto si tratta di un'azione registrata che si riflette male su di me e sulla squadra.

Dice che è ingiusto poiché non specifico i casi limite.

Non è ingiusto da parte sua aspettarsi che tu conosca tutti i casi limite. Ma allo stesso tempo, non è giusto aspettarsi quello da lui. Ogni cambiamento ha dei rischi e quando vengono scoperti i problemi è necessario collaborare in gruppo per affrontarli.

Non conosco il suo design per la storia fino a quando non l'ha implementata

Non dovresti conoscere il design. Può essere utile conoscere il progetto al fine di formulare ipotesi iniziali su quali storie siano più facili o più difficili per la gestione degli arretrati. Ma evita di intrappolare lo sviluppatore nel tuo progetto quando scrivi storie. Ti succhia tutto il divertimento quando sei semplicemente una tastiera ad attivazione vocale per l'OP.

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 lo sviluppatore includa il tempo nella storia per la riparazione della copertina dei casi scoperti. Cavolo, rendilo parte di ogni user story. Questo è facilmente difendibile tramite l'obiettivo di 0 nuovi bug introdotti. Il problema è che lo sviluppatore non lo sta pianificando al momento. Ed è fuori tempo quando scopri i problemi. Ci vorrà del tempo in entrambi i modi, quindi inseriscilo nella storia in cui è visibile durante la pianificazione.
• Dopo il test (e grazie per il test comunque), invia allo sviluppatore un elenco di problemi rilevati. La risoluzione di tali problemi andrà contro la condizione di soddisfazione dei "casi limite fissi".
• Se qualcosa rimane non risolto o viene scoperto troppo tardi, decidi se la storia deve essere spinta in base al fatto che il caso d'uso possa essere soddisfatto. Si verificano problemi noti e soluzioni alternative. Li ho divulgati nelle note di rilascio e creare nuove storie per risolverli.
• Se nel processo c'è un particolare punto critico che genera il pushback, allora cambia il tuo processo! Dopotutto, il miglioramento del processo fa parte di Scrum. Ad esempio, se il tuo sviluppatore si arrabbia quando rifiuti la storia, allora suggerisci alla squadra un cambiamento nel processo in modo che il rifiuto non attivi le correzioni. Esegui i test e le correzioni prima di Fine e Rifiuto.
• Collabora con il team e ciò che hanno prodotto e sfruttalo al meglio. Non fanno un lavoro perfetto e nemmeno tu. Quindi programmalo. I miei team sono stati di solito devops, quindi abbiamo una storia utente di Supporto non pianificato ogni scatto per problemi emergenti ... pianificazione per i non programmabili.

I requisiti dovrebbero essere chiari e concisi. Se non lo sono, succede esattamente cosa ti è successo. È colpa tua e la cosa peggiore che puoi fare quando specifichi i requisiti è assumere delle cose.

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

Ma in questi casi, vorrei solo colmare le lacune mancanti e passarle allo sviluppatore. Dopotutto, si verificano bug nei requisiti.