Critères d'acceptation pour les cas Edge

Je suis chef de produit dans une équipe agile. Lorsque je fais des tests d'acceptation de commande d'achat, je prends généralement note d'essayer certains cas extrêmes. Il n'est pas rare que je découvre quelque chose, puis je le remets aux développeurs. Je suis repoussé par l'un des développeurs lorsque je rejette ses histoires. Il dit que c'est injuste puisque je ne spécifie pas les cas marginaux et comment le programme devrait répondre dans les critères d'acceptation, car il a tendance à coder uniquement ce que je décris dans l'histoire. Je l'ai encouragé à me demander alors qu'il se heurte à des cas marginaux lors du codage, mais il pense que ce n'est pas son travail de réfléchir aux cas limites, à la mienne et je devrais faire de nouvelles histoires pour le prochain sprint.

Pour ma défense, je ne connais pas sa conception de l'histoire jusqu'à ce qu'il l'implémente, il est donc difficile de parcourir toutes les possibilités (la configuration se fera-t-elle dans une base de données ou un fichier de propriétés?). Par souci de simplicité, disons que nous avons une histoire à ajouter à la division d'une application de calculatrice. Dans le monde SCRUM idéal, m'incomberait-il d'ajouter un "scénario de division par zéro" aux critères d'acceptation ou devrait-il travailler sur ces cas au fur et à mesure de son développement pour que l'application n'implose pas en 5/0? Pour être clair, dans ce cas, je n'accepterais pas si l'application plantait durement sur 5/0, mais je passerais si elle enregistre, imprime DIV0, ou toute autre façon de gérer l'erreur ... tant qu'elle ne le fait pas ne plante pas.

Je pense que la réponse est que vous devriez tous les deux penser à votre propre ensemble de cas de bord. En tant que développeur, il devrait gérer les cas particuliers qui sont spécifiques aux données, comme l'application se bloque à partir d'une entrée utilisateur donnée, 5/0 tombe certainement dans cette partie du spectre. Le développeur doit vous demander ce que vous pensez être un message d'erreur approprié lorsque l'entrée donnée dans le cadre de l'interaction de l'utilisateur conduit à quelque chose de non valide.

Votre portion du spectre est l'aspect commercial des choses. Comment la calculatrice doit-elle se comporter si le compte de l'utilisateur n'est pas autorisé à utiliser le bouton de division? Comment devrait-il se comporter lorsque le compte est autorisé à utiliser l'opération Mod mais n'a pas accès à la fonction de division?

Le message important que je pense que vous devez transmettre et être accepté par tous les membres de l'équipe est que vous faites tous partie de la même équipe. Si le produit n'est pas complet, le produit n'est pas complet et l'équipe est à blâmer, pas un membre donné.

L'équipe doit travailler ensemble plutôt que d'avoir un type d'attitude / mantra «pas mon travail, pas ma responsabilité».

Les critères d'acceptation se présentent sous la forme de:

• Acceptation commerciale
• Acceptation de l'assurance qualité

En règle générale, l'acceptation de l'entreprise répond généralement à la question:

• Est-ce que la fonctionnalité qui a été implémentée fait ce que je veux qu'elle fasse?

La fonctionnalité aura un certain nombre d'exigences qui sont orientées métier, comme si j'appuie sur ce bouton, je m'attends à ce que cette action se produise. Il énumérera le ou les scénarios commerciaux attendus et le comportement attendu, mais il ne couvrira pas tous les cas possibles.

On s'attend à ce que les exigences commerciales soient définies avant une itération afin que l'assurance de la qualité puisse développer toute exigence technique sur les exigences non commerciales. L'assurance de la qualité doit développer des cas destructifs ainsi que des cas marginaux au besoin.

Les deux ensembles d'exigences doivent être examinés avant de commencer tout travail d'histoire afin qu'une estimation et un engagement formels puissent se produire pour l'unité de travail. Une fois cela fait, la fonctionnalité / les histoires peuvent être travaillées. À ce stade, tout le monde est clair sur ce qui doit être livré à la fois d'un point de vue commercial et technique.

L'histoire est définitivement acceptée une fois que les membres de l'équipe commerciale et d'assurance qualité ont signé l'histoire. Cela doit se produire pendant l'itération pour l'acceptation de l'entreprise et l'acceptation de l'assurance qualité. Il s'agit de la définition de terminé (DoD) qui indique que des travaux supplémentaires peuvent être commencés.

Toutes les nouvelles découvertes peuvent être enregistrées en tant que défauts ou pics d'histoire supplémentaires. Dans un monde parfait, cela ne se produirait jamais, mais en réalité, il y a généralement une certaine "découverte" qui se produit lorsque vous travaillez sur un article / une histoire. C'est naturel.

L' équipe doit travailler ensemble (entreprise, assurance qualité, développeur) pour hacher tout type d'exigences de découverte nébuleuse. Si c'est agile, ils devraient tous être assis à la même table pour favoriser la communication et la résolution rapide de toutes les questions qui pourraient survenir. Cela devrait ressembler à ceci:

QA:

"Hé, développeur, nous devrions gérer ce scénario particulier. J'ai découvert que si j'entre ces données, j'obtiens une erreur."

DEV:

"Cela n'était couvert par aucune exigence, mais nous pouvons ajouter des fonctionnalités supplémentaires pour couvrir cela. OK, Hey Business Person, comment aimeriez-vous que l'application se comporte dans ce cas?"

ENTREPRISE:

"Montrons notre message d'erreur standard et laissons l'utilisateur réessayer pour ce scénario. Combien d'efforts supplémentaires seront alors?"

DEV:

"Ce sera facile, seulement une heure ou deux supplémentaires. Je peux m'engager pour cette itération. QA veuillez mettre à jour vos critères d'acceptation pour ce scénario, nous n'avons pas besoin d'une histoire supplémentaire pour cela. Merci!"

Ou si c'est beaucoup de travail, une nouvelle histoire est ajoutée à l'arriéré. L'équipe peut toujours accepter l'histoire d'origine car elle répond à toutes les exigences d'origine, puis reprendre l'histoire de la pointe lors de la prochaine itération.

Écrire un logiciel qui se comporte de manière robuste face à une entrée incorrecte ou ambiguë est une partie essentielle du travail d'un développeur de logiciel.

Si vos développeurs ne le voient pas de cette façon, incluez des exigences supplémentaires non fonctionnelles dans la spécification des exigences qui énoncent explicitement cette exigence et fournissez à vos développeurs un exemple de votre processus de test afin qu'ils puissent appliquer ce processus eux-mêmes avant de soumettre leur version finale. code pour examen.

Les tests d'acceptation devraient de toute façon être une partie vitale de tout document d'exigences. Si une exigence ne précise pas également ses critères d'acceptation, ce n'est pas vraiment une exigence; c'est un souhait.

Ce qui s'est passé ici, c'est que vous avez découvert la valeur . La valeur d'entrée n'a pas été prise en compte lorsque l'histoire (et les critères d'acceptation) ont été écrits ou lorsque le code a été écrit. Si cela ne fait pas partie des critères d'acceptation, vous n'avez pas vraiment de base pour rejeter l'histoire.

Ce que nous ferions dans mon équipe, c'est:

1. Créez un bug détaillant le comportement attendu et réel.
2. Mettez à jour les critères d'acceptation afin que la nouvelle exigence trouvée soit documentée.
3. Prioriser le bogue avec tous les autres histoires et bogues dans la prochaine itération.

L'avantage ici est que vous êtes obligé de déterminer si la correction de ce bogue est la prochaine chose la plus importante à faire. Il peut ou non être suffisamment important pour être corrigé, mais il est important que sa valeur soit prise en compte.

Bien sûr, vous devez toujours trouver un moyen d'encourager les développeurs (et vous-même) à explorer ces cas limites à l'avance. Si votre équipe de développement ne passe pas de temps à décortiquer les histoires, encouragez-les à avoir une session de planification détaillée avant de commencer à travailler dessus.

Quelques observations:

... quand je rejette ses histoires

Je ne connais pas votre culture ou votre processus de travail, mais pour moi, rejeter une histoire est une étape difficile. Si j'étais le développeur, je générerais également un recul car c'est une action enregistrée qui me fait du mal et à l'équipe.

Il dit que c'est injuste puisque je ne précise pas les cas marginaux.

Il est injuste de sa part de s'attendre à ce que vous connaissiez tous les cas extrêmes. Mais en même temps, il est injuste que vous vous attendiez à lui. Chaque changement comporte des risques et, à mesure que des problèmes sont découverts, vous devez tous travailler en équipe pour les résoudre.

Je ne connais sa conception de l'histoire qu'après l'avoir mise en œuvre

Vous ne devriez pas avoir à connaître le design. Il peut être utile de connaître la conception afin de faire des suppositions initiales sur les histoires qui sont plus faciles ou plus difficiles à gérer pour l'arriéré. Mais évitez de piéger le développeur dans votre conception lorsque vous écrivez des histoires. Il aspire tout le plaisir lorsque vous êtes simplement un clavier à commande vocale pour l'OP.

Il semble que vous devriez travailler à l'amélioration des processus et faire du team building. Certaines choses que je pourrais suggérer pour le processus:

• Suggérez au développeur d'inclure du temps dans l'histoire pour que la couverture répare les cas de bord découverts. Heck, faites-en partie de chaque user story. Ceci est facilement défendable via l'objectif de 0 nouveaux bogues introduits. Le problème est que le développeur ne le prévoit pas actuellement. Et il n'a plus de temps lorsque vous découvrez des problèmes. Cela va prendre du temps de toute façon, alors mettez-le dans l'histoire où il est visible lors de la planification.
• Après vos tests (et merci pour les tests d'ailleurs), envoyez au développeur une liste des problèmes découverts. La résolution de ces problèmes ira à l’encontre de la condition de satisfaction des «cas d’arrêt définitif».
• Si quelque chose reste non corrigé ou est découvert trop tard, décidez si l'histoire doit être poussée selon que le cas d'utilisation peut être rempli. Des problèmes connus et des solutions de contournement se produisent. Les divulguer dans les notes de publication et créer de nouvelles histoires pour les corriger.
• S'il y a une zone rugueuse particulière dans le processus qui génère un refoulement, changez votre processus! Après tout, l'amélioration des processus fait partie de Scrum. Par exemple, si votre développeur se fâche lorsque vous rejetez l'histoire, suggérez à l'équipe un changement de processus afin que le rejet ne déclenche pas de correction. Faites les tests et les correctifs avant Terminé et Rejeté.
• Travaillez avec l'équipe et ce qu'elle a produit et faites-en le meilleur usage possible. Ils ne font pas un travail parfait et vous non plus. Alors planifiez cela. Mes équipes sont généralement devops, nous avons donc une histoire utilisateur de support non planifié à chaque sprint pour les problèmes émergents ... la planification pour les imprévus.

Les exigences doivent être claires et concises. Si ce n'est pas le cas, il se passe exactement ce qui vous est arrivé. C'est votre faute, et la pire chose que vous puissiez faire lorsque vous spécifiez des exigences est de supposer les choses.

Vous exemple spécifique, sur la division par zéro. Si vous n'avez pas spécifié que vous souhaitez enregistrer l'erreur, ne vous plaignez pas si le développeur imprime 100 en conséquence.

Mais dans de tels cas, je ne ferais que combler les lacunes manquantes et les transmettre au développeur. Après tout, des bogues dans les exigences se produisent.