10x - 100x plus rapide
1 000 fois plus approfondi
En moyenne, nous effectuons environ 1 000 tests par user story. Il s'agit d'une combinaison de tests statiques et dynamiques. Il s’agit d’un niveau de contrôle qui n’est pas normalement atteint avec des critiques manuelles d’histoires.
Veulent en savoir plus? Lisez les détails sur le type de tests effectués par ScopeMaster.
ScopeMaster fournit des analyses des exigences logicielles qui aident les équipes de livraison de logiciels à livrer des projets logiciels plus rapidement et avec plus de certitude.
Si cela peut être mal interprété, ce sera
Si une user story peut être interprétée différemment par les lecteurs clés (auteur, utilisateur, testeur, développeur), alors il est probable que l’un d’entre eux travaillera sur une mauvaise compréhension, générant du gaspillage et des retouches. Il est très important d’étouffer ces ambiguïtés dans l’œuf.
125 raisons de tester les user stories
Le rapport entre les mots d’une user story et le nombre de jetons de codage que nous voyons généralement est de 1:125. Une user story de 12 mots finirait probablement par devenir environ 1 500 jetons de codage, soit environ 300 lignes de code. Ainsi, pour chaque minute passée à corriger un mot ambigu dans une user story, vous gagnerez probablement 125 minutes en codage. Voilà du temps bien dépensé !
Tests d’extrême gauche
Les tests de user story peuvent sembler une idée étrange, mais ce n'est pas le cas. En fait, c'est l'une des choses les plus productives que vous puissiez faire sur un projet logiciel. C’est l’exemple même du test d’extrême gauche. Si vous souhaitez devenir un Product Owner plus performant, commencez à tester ces histoires le plus tôt possible. Les user stories sont une expression des exigences relatives aux projets logiciels agiles. Comme les autres livrables du développement logiciel, ils sont également sujets aux erreurs. Le défi particulier des user stories est qu’elles peuvent très facilement être mal interprétées, ce qui peut entraîner une perte de temps et d’efforts considérables. En fait, ils sont plus susceptibles d’être mal interprétés qu’improbables.
Comment tester les user stories
Alors comment le fait-on? Commençons par les bases. Qu'est-ce qu'une exigence logicielle d'entreprise ? :
Une véritable exigence (ou capacité) commerciale est « ce qui doit être livré pour apporter de la valeur à l'entreprise » (Robin Goldsmith). Les user stories sont les exigences fonctionnelles discrètes qui constituent cette capacité.
Et si vous ne testez pas vos user stories ?
De mauvaises user stories (ou mauvaises exigences) sont à l’origine des défauts de production 35% (Accenture, 2021). Un problème d’exigences qui n’est résolu que dans les phases ultérieures du développement/déploiement peut coûter 75 à 1 000 fois plus cher à résoudre que s’il avait été résolu avant le début du codage.
Besoin de discipline pour réduire l’ambiguïté
Lorsque nous écrivons du code, nous suivons des disciplines pour améliorer la lisibilité, réduire la complexité, augmenter la réutilisation et bien plus encore. (Pour en savoir plus, lisez l'excellent Code terminé, par Steve McConnell). La rédaction de user stories garantit également une telle discipline, notamment pour minimiser l’ambiguïté, l’incohérence et la complexité. En fait, une bonne user story peut être plutôt ennuyeuse car elle est sans ambiguïté. Soyez prêt à ajuster la façon dont vous rédigez les user stories, à adopter la cohérence et la discipline pour éliminer les ambiguïtés. Heureusement, ScopeMaster vous aidera à apprendre au fur et à mesure.
Outils associés
Jsonlint est un outil en ligne pour tester la syntaxe d'un fichier json
Validateur HTML est un outil en ligne pour tester la syntaxe HTML.
