ScopeMaster-dix-tests-pour-de-grandes-histoires-d'utilisateurs

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 »

Arrière-plan

Probablement mal compris

Nous avons analysé plus de 100 000 user stories et constaté que la longueur moyenne d’une story est de 12 mots. Mathématiquement, il existe plus de 80 milliards de permutations de 12 mots. Cela signifie qu'il existe une manière presque infinie pour les lecteurs de mal interpréter les user stories.

De mauvaises histoires d'utilisateurs entraînent des retouches excessives (± 125 fois)

Nous avons également estimé qu’en moyenne, chaque mot d’une user story mène à 125 termes de codage. Cela signifie qu’une erreur (pouvant conduire à un malentendu) entraînera des retouches considérables une fois le codage commencé.

L'augmentation du travail à distance signifie que nous sommes plus dépendants de l'écrit. Trouver les bons mots est important.

Tests de clarté automatisés

La plupart des user stories sont sujettes à des interprétations erronées. ScopeMaster® effectue une analyse linguistique détaillée de chaque mot de la user story afin de détecter la ou les significations fonctionnelles. Le moteur d'analyse est spécifiquement conçu dans le but de lever l'ambiguïté des user stories de logiciels (détecte les modèles d'objet verbe sujet dans le texte). C’est la base sur laquelle le moteur d’analyse effectue « le nec plus ultra en matière de tests de décalage à gauche ».

Le moteur d'analyse effectue également des centaines de vérifications linguistiques pour détecter les phraséologies et les termes ambigus susceptibles de conduire à une mauvaise interprétation de la user story. Ces tests sont issus des enseignements de certains des plus grands experts mondiaux en matière d'exigences. (C'est un peu comme si toutes vos user stories étaient examinées par des experts).

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.

Tests de concision automatisés

ScopeMaster® effectue une analyse détaillée des mots de chaque user story, mettant en évidence l'utilisation excessive de mots inutiles.

Test des exigences statiques

ScopeMaster® exécute des centaines de tests sur chaque user story. C'est comme SonarQube mais pour les user stories.

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é

Tests automatisés de détection des utilisateurs

L'analyseur ScopeMaster® détecte les utilisateurs candidats dans chaque histoire. ScopeMaster mettra en évidence les instances d'histoires sans utilisateur. En option, vous pouvez indiquer à l'analyseur quel est le mot « utilisateur » dans votre histoire.

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.

Génération de tests automatisés

Grâce à la « connaissance » de l'intention fonctionnelle de votre user story, le moteur ScopeMaster® propose des scénarios de tests et des cas de tests essentiels qui peuvent être utilisés comme base pour les tests fonctionnels. Les tests générés par ScopeMaster sont 100% alignés sur la fonctionnalité de la user story. Ils couvrent à la fois les tests positifs et négatifs. Ils peuvent être considérés comme les tests minimaux indispensables à réaliser. C’est un gain de temps majeur pour les professionnels des tests.

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.

Arrière-plan

L'unité de taille de base est le Point de fonction cosmique qui est une norme ISO pour la taille. Commencez votre parcours d'apprentissage avec cette mise à jour, guide pour logiciel de mesure.

Une première estimation du CFP est très utile, car à mesure que les détails des exigences seront connus, cette estimation se rapprochera d'une mesure plus précise.

Applicable universellement

Pour ceux qui hésitent à estimer ou à mesurer la taille (fonctionnelle) des exigences, considérez ce qui suit. La taille minimale d'une user story est de 2-3 CFP. Le coût typique du développement d’un CFP est de $200 – $2000. Le temps nécessaire pour estimer la taille est d'environ 10 minutes par CFP manuellement ou 2 minutes à l'aide de l'automatisation. Connaître la taille est extrêmement précieux pour déterminer combien coûtera le projet, combien de temps il prendra et plus encore. Les activités « connaître la taille » et « effectuer le dimensionnement » réduisent l'incertitude et améliorent la qualité.

Estimation automatisée de la taille

ScopeMaster a été conçu à l'origine dans le but principal de déterminer la taille fonctionnelle (points de fonction COSMIC et IFPUG) à partir des exigences logicielles. Les estimations de taille de ScopeMaster ont été validées comme étant généralement inférieures à 15% d'une taille déterminée manuellement. Non seulement cela réduit le travail de dimensionnement, mais cela permet également d'introduire le dimensionnement technique formel à ceux qui ignorent actuellement l'existence de techniques aussi précieuses.

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.

Contrôles de cohérence automatisés

Après avoir analysé le texte individuel de chaque story, le moteur ScopeMaster croise toutes les user stories au sein d'un ensemble (ou backlog). Il identifie chaque occurrence de types d'objet et les présente sous forme de tableau afin que les incohérences puissent être facilement et rapidement repérées.

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.

Vérification automatisée de l'exhaustivité

Le moteur d'analyse ScopeMaster identifie toutes les occurrences d'un type_objet dans un ensemble de user stories. Il effectue ensuite une analyse CRUD. pour identifier les histoires potentiellement manquantes. ScopeMaster suggère même quelle pourrait être l'histoire manquante.

Avoir une compréhension complète de la portée complète d’un projet dès le début de son cycle de vie est extrêmement précieux pour les chefs de projet.

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.

Vérification automatisée de l'unicité

Le moteur d'analyse ScopeMaster identifie toutes les occurrences d'un type d'objet (et l'intention fonctionnelle associée) dans un ensemble de user stories. Lorsqu'il y a deux histoires qui effectuent la même opération CRUD sur un objet, celles-ci sont mises en surbrillance.

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.

Vérification automatisée du langage technique

Le moteur d'analyse ScopeMaster recherche des centaines d'expressions techniques et autres terminologies inappropriées pour les user stories.

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.

Témoignages d'utilisateurs agiles

De nombreux Agilistes utilisent le Liste de contrôle INVESTIR critères pour les user stories initialement par Bill Wake :

jeindépendant
Nnégociable
Vprécieux
Estimulable
Scentre commercial
Testable

Méfiez-vous d'utiliser INVEST

L'auteur original souligne qu'INVEST est un sous-ensemble incomplet d'attributs.
Il ne reconnaît pas que les histoires des utilisateurs peuvent être interdépendantes.
Cela nécessite que les histoires soient orientées utilisateur.
Il n’insiste pas pour autant que les histoires soient sans ambiguïté.
Il ne reconnaît pas les dangers de travailler sur une compréhension incomplète de la portée.
Cela n'encourage pas une analyse disciplinée (dénomination cohérente, orientée utilisateur, concision)
Il n'est pas nécessaire que les histoires soient mesurables (bien qu'il fasse référence à Estimable, il s'agit d'un critère très vague).

La création originale d'INVEST mentionne également que les tâches doivent être traitées différemment et l'acronyme SMART appliqué :

Spécifique
Mesurable
Réalisable
Réaliste
Limité dans le temps

J'ai toujours trouvé les contrôles SMART efficaces et adaptés aux tâches, mais pas pour les user stories.

Pourquoi devrions-nous écrire de meilleures user stories ?

Comme tout type de travail de connaissance, la rédaction des user stories (ou exigences logicielles) est sujette aux erreurs. Ces erreurs doivent être corrigées avant le développement du logiciel, sinon elles deviennent très longues et coûteuses à résoudre une fois qu'elles sont résolues. Il est plus probable qu'improbable qu'une user story écrite par une seule personne risque d'être mal interprétée par ses lecteurs.