Toutes mes missions se sont révélées être dans un environnement AGILE. Pourtant la première fois que j’ai été confronter aux critères d’acceptance au sein d’un projet c’était il y a un an pour le compte d’un client : ING Direct. Je dois avouer que pour la première fois je découvrais ce que ca donnait de travailler pour un client en SCRUM de façon aussi rigide. C’était la totale: les Sprint, daily meeting, sprint review, story mapping, story sizing,  sprint feedback, sprint démo et les critères d’acceptance…etc. Je me propose dans cet article de donner un retour d’expérience sur l’utilité des critères d’acceptance.

Lorsque le code est axé  sur les critères d’acceptation, il est plus simple et direct.

Les critères d’acceptation sont des tests simples qui nous indiquent quand nous avons fini d’implémenter une fonctionnalité.

Savoir quand nous avons fini de construire une fonctionnalité est extrêmement important pour les développeurs car nous ne sommes pas toujours sûrs de la robustesse d’une fonctionnalité.

De peur que le code ne tombe plus tard, nous sommes sans cesse entrain de vouloir le rendre plus robuste – ce qui nous amène souvent à surcharger les dev dans un domaine, en prenant le temps nécessaire pour donner aux autres zones l’attention qu’elles méritent. Savoir quand nous en avons fini avec une caractéristique nous aide à passer à la suivante avec confiance.

Les critères d’acceptation traduisent la façon dont l’utilisateur évalue une caractéristique. Il peut être consigné comme une déclaration conditionnelle sur le dos d’une carte sous forme d’une petite histoire, ou il peut être automatisé avec un outil de test d’acceptation comme FIT, FitNess, SpecFlow, Cucumber, etc. Ces outils nous aident à créer des tests d’acceptation sous une forme  qu’un ordinateur peut exécuter tout en restant facile à lire pour un non-développeur. En l’occurance chez ING j’utilisais CucumberJS pour l’automatisation des critères d’acceptation.

Mais il y a un autre avantage majeur à coder les critères d’acceptation. Ils permettent au developpeur de garder à l’esprit la fonctionnalité à livrer et de rester axé sur la fourniture de quelque chose d’utile à nos utilisateurs. Cela met donc les tests d’acceptation au bon niveau d’abstraction.

Créer les bons tests pour le code est primordial. Si les tests sont trop fins, nous écrirons probablement des tests dépendant de l’implémentation. Si elles sont trop larges, nous risquons de manquer des cas limites et d’autres conditions exceptionnelles. Du coup lorsque nous écrivons notre test d’acceptation autour des critères d’acceptation d’une feature et que notre test passe, nous savons que notre feature est terminée.

Tout comme la littérature, le code peut avoir tendance à divaguer lorsqu’il devrait être succinct. Lorsque le code est axé sur l’acceptation de certains critères d’acceptation, il est plus simple et direct. Nous consacrerons donc beaucoup moins d’efforts à la création de codes erronés et mettrons beaucoup plus d’efforts dans un code qui fournit de la valeur à nos utilisateurs. Nous nous retrouverons également avec un système plus assertif, plus simple à tester et à étendre.

Un autre aspect important des critères d’acceptation est qu’il nous aide à écrire du code qui produit un résultat observable, ce qui signifie qu’il est généralement plus testable et modulaire. Les critères d’acceptation traduise directement ce qui rend une caractéristique précieuse pour l’utilisateur. Garder à l’esprit les critères d’acceptation lorsque nous construisons une fonctionnalité nous aide à rester concentrés sur la production de code qui apporte de la valeur.

« Comment saurons-nous que nous avons terminé? » est la question que nous devrions toujours poser avant de commencer à construire une fonctionnalité. Définir cela à l’avance garantit que tout le monde commence sur la même page.

Pour formaliser les critères d’acceptation, les products owner utilisent souvent une structure inspirée du language Gherkin dédié à la description de comportements logiciels. C’est le:  GIVEN-WHEN-THEN (Étant Donné – Quand – Alors) :

• GIVEN : l’état du logiciel avant l’exécution de la user story
• WHEN : un événement qui déclenche un processus
• THEN : l’état du logiciel après l’exécution

Considéron une user story concernant un formulaire de connexion : “ÉTANT DONNE que je suis sur la page de connexion ET que j’ai entré un login et un mot de passe dans le formulaire ET que le login et le mot de passe correspondent à un utilisateur enregistré, QUAND je clique sur le bouton “Se connecter” ALORS j’arrive sur la page d’accueil du site.

Le rôle d’un critère d’acceptation n’est pas de proposer une solution technique : il doit être écrit du point de vue de l’utilisateur.

Une astuce pour vous aider à écrires des critères d’acceptations, commencez par vérifier si ils correspondent à la définition SMART :

• Specific  : compréhensible, facile à reproduire
• Measurable : quantifiable et observable
• Achievable : possible à réaliser (sans complexité excessive)
• Relevant :  approprié à la user story en question
• Time bound  :  avec un moment d’application circonscrit dans le temps