
Commencer les tests de user story
Pour la plupart des activités logicielles, les user stories sont un bref rappel des conversations entre le propriétaire du produit, le développeur et le testeur. Bien que les user stories soient très courtes, le formulaire est souvent utilisé à mauvais escient, ce qui conduit à des ambiguïtés, à des discussions et à des remaniements inutiles. Dans cet article, nous expliquons comment tester les user stories afin que vous puissiez garantir que vos user stories sont de haute qualité et réduiront les retouches et raccourciront les délais.
J'ai participé à un débat considérable en ligne sur la validité même de la réflexion sur la qualité des user stories. Si vous acceptez que des user stories claires sont utiles à un projet, alors le concept de test de user story devrait avoir du sens pour vous.
Apprenez ces dix tests pour rédiger de superbes user stories.
1. Effacer
Vos user stories doivent être clair et sans ambiguïté. Le propriétaire du produit, le développeur et le testeur doivent tous avoir une compréhension commune de ce qui doit être livré à partir du texte de l'histoire. Lorsque vous écrivez vos histoires, supposez que si elles peuvent être mal interprétées, elles le seront. Assurez-vous également que vos histoires incluent toutes les fonctionnalités nécessaires (à l’exclusion de la navigation).
Conseil: Concentrez-vous sur l'intention fonctionnelle de la user story, par exemple « En tant qu'utilisateur_inscrit, je peux mettre à jour mon profil »
2. Concis
Gardez-les courts. Les histoires n’ont pas besoin d’être longues pour transmettre la signification fonctionnelle essentielle. Une ou plusieurs phrases courtes peuvent suffire. N'oubliez pas que les critères d'acceptation sont complémentaires à l'histoire.
Conseil : évitez les descriptions sur la navigation, les détails d'implémentation, les critères d'acceptation et les attributs d'objet.
Conseil : évitez les détails d'implémentation.
Conseil : Séparez les critères d'acceptation de la user story principale.
3. Orienté utilisateur
Une histoire doit être écrite du point de vue de l'utilisateur. La recommandation agile typique est le format :
Comme un Type d'utilisateur Je veux effectuer_quelque chose de sorte que raison
Dans certains cas, le type d'utilisateur Il peut s'agir d'un autre logiciel, ou peut-être même d'un périphérique interagissant avec le logiciel, tel qu'un capteur.
Conseil: N'écrivez jamais vos histoires du point de vue du développeur.
Conseil: Évitez le terme général utilisateur, utilisez plutôt des étiquettes riches et cohérentes pour le type ou le rôle d'utilisateur, telles que Utilisateur enregistré ou visiteur_non authentifié
4. Testable
Une histoire peut être testable si elle contient des déclarations claires de fonctionnalité. Utilisez des expressions qui déduisent le mouvement, le stockage et la récupération des données. Des exemples d'histoires testables incluent des expressions telles que "mettre à jour le profil", "afficher le rapport de ventes“, "envoyer un e-mail". Écrire vos histoires de cette façon garantira que l’intention fonctionnelle principale est claire. Cela constitue la base à partir de laquelle des scénarios de test peuvent être générés. La suite complète de tests dépendra généralement de critères d’acceptation détaillés supplémentaires.
Conseil: Les critères d'acceptation détaillés sont complémentaires à la user story principale, n'intègrent pas de critères d'acceptation dans le texte de la user story.
5. Mesurable
Je fais ici référence à la mesurabilité de la taille, en particulier à l'aide du Point de fonction COSMIQUE (CFP) comme base de dimensionnement. Il s'agit d'une norme ISO mature de deuxième génération, adaptée à tous les types de travaux logiciels. Les user stories ne peuvent être mesurées que si elles contiennent une ou plusieurs expressions claires de tous les mouvements de données qui seront nécessaires et mesurés. La mesurabilité facilite considérablement la planification et l’assurance qualité. La taille fonctionnelle n’est pas le seul attribut mesurable d’une user story, mais c’est l’un des plus importants (car elle est très étroitement liée à l’effort pour la construire).
Conseil: Le fait de ne pas mesurer la taille ajoute de l'incertitude au travail de votre logiciel.
Conseil: Découvrez la méthodologie de dimensionnement COSMIC à partir de ce guide.
6. Cohérent
Utilisez des mots cohérents pour les deux types_utilisateurs et types_objets à travers un ensemble de user stories. Une dénomination cohérente réduira la confusion, les défauts, les retouches et le gaspillage. Les systèmes complexes et les environnements riches en jargon ont tendance à donner au même utilisateur ou au même objet des termes différents par les membres de l'équipe.
7. Terminer
Les exigences manquantes sont l’une des principales causes d’échec des projets logiciels. La taille de la plupart des projets augmente à mesure que des besoins supplémentaires deviennent apparents. Cette augmentation de la portée entraîne davantage de travail, davantage de retouches, des délais allongés, des dépassements de budget et, dans certains cas, un échec du projet. Bien que l'approche Agile décourage un travail initial excessif, un travail de cadrage initial est essentiel. Recherchez attentivement les exigences manquantes lorsque vous rédigez vos user stories.
8. Unique
Toutes les exigences doivent être uniques. Les exigences dupliquées sont un problème qui a tendance à être plus répandu dans les projets de plus grande envergure.
9. Précieux
Toutes les user stories doivent être utiles à « l’entreprise ». Il convient de remettre en question la valeur et l’importance de chaque user story, afin que seules les fonctionnalités les plus importantes soient fournies. Si une user story ne peut pas être attribuée à un résultat commercial mesurable, elle peut ne pas avoir de valeur et devrait peut-être être délimitée. La valeur financière réelle de l'histoire peut être difficile à mesurer, en utilisant la taille fonctionnelle (CFP) comme base de valeur (en particulier pour la mesure de la valeur gagnée EVM).
10. Sans conception
Les user stories ne doivent pas faire référence à la technologie utilisée pour les diffuser. Ce niveau de détail peut être inclus en complément de la user story pour aider à fournir un contexte sur la « manière » dont elle doit être livrée. Ceci est particulièrement adapté aux aspects non fonctionnels de la manière dont la fonctionnalité sera réalisée.
Recommandation
Laissez ScopeMaster tester vos user stories pour vous, importez simplement et appuyez sur le bouton vert, son analyse linguistique intelligente évaluera la qualité et fera des recommandations pour améliorer vos user stories.

Conclusion
À mesure que nous nous dirigeons vers le travail à distance, notre dépendance à l’égard de l’écrit dans le développement de logiciels augmente. Passez du temps à trouver les bons mots. Des user stories de bonne qualité sont la base d’un logiciel de qualité. Vous devez tester les user stories avant de commencer à coder, pour éviter de perdre du temps.
Chacun de ces 10 tests représente un attribut de qualité d’une bonne user story. Vous pouvez l'utiliser comme liste de contrôle à exécuter sur chaque user story que vous écrivez. Tester les user stories rapportera des dividendes importants en réduisant les retouches, en réduisant la dérive de la portée et en réduisant la volatilité de la portée. Et si vous souhaitez le faire plus rapidement, essayez ScopeMaster, il fait le gros du travail des tests de user story.