Blog ENI : Toute la veille numérique !
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici

Versant métier

Introduction

La connaissance du métier est un des versants les plus forts dans le test, à telle enseigne qu’une personne qui n’a aucune vision sur le test saura trouver des anomalies à forte valeur ajoutée tandis qu’un Testeur professionnel sans connaissance métier saura s’organiser, mais il devra partir à la pêche aux informations pour commencer à savoir ce qu’il faut chercher…

Ce chapitre va répertorier quelques pratiques qui viendront vous aider dans l’obtention d’un meilleur produit par des pratiques qui vont permettre la maîtrise du métier.

Définition du Prêt (DoR)

Avez-vous déjà eu entre les mains une US où on ne comprenait pas trop ce qui était demandé et encore moins ce qui devrait être testé ? Établir conjointement une liste de critères qui viennent aider le PO et l’équipe de réalisation à avoir des US suffisamment claires pour que l’implémentation soit la plus fluide possible et que son acceptation par le PO se fasse du premier coup (voir « First Pass Yield ») est une bonne idée !

Parmi les éléments que l’on peut trouver dans une Définition du Prêt (Definition of Ready - DoR), on trouvera des critères tels que :

  • l’US possède une description claire et compréhensive ;

  • les dépendances avec les autres US sont définies ;

  • l’US possède une valeur métier ;

  • l’US est priorisée et ordonnée dans le backlog du sprint selon la priorité métier ;

  • la complexité en nombre de point de l’US est définie par l’équipe Scrum ;

  • les tâches liées à l’US sont identifiées ;

  • le DoD de l’US est défini et les critères d’acceptance de l’US sont rédigés ;

  • l’US est petite et est comprise par toute l’équipe Scrum ;

Ces différents éléments peuvent être synthétisés par l’acronyme INVEST :

images/03DP01.png

Figure 1 : une bonne US est "INVEST"

  • Indépendante : les US à réaliser ne devraient pas dépendre d’autres US et créer des situations de blocage ;

  • Négociable : le périmètre d’une US devrait pouvoir être adaptable pour réduire la durée de réalisation en cas de besoin, mais toujours conserver le DoD ;

  • Valeur ajoutée : si l’US ne sert à personne, elle ne sera jamais réalisée !

  • Estimable : si l’équipe de réalisation ne comprend pas l’US, elle ne pourra jamais l’évaluer ;

  • Succincte : si l’US est trop longue à comprendre ou à réaliser, il vaut mieux la découper ;

  • Testable : si l’US...

Clarté d’une US

L’IEEE donne quelques pistes pour aider à avoir des spécifications ou des US claires [IEEE830] :

  • Correctes : une personne du métier n’irait pas à l’encontre de cette US.

  • Sans ambiguïté :

  • Complètes : tous les cas sont examinés, ou on peut estimer que l’US est explicite et que tout ce qui n’est pas dit n’est pas à faire.

  • Cohérentes : toujours les mêmes mots pour désigner les mêmes choses.

  • Testables : si on peut créer des tests pour la vérifier et que les tests répondent aux attentes du PO, c’est un bon indice de clarté.

IEEE830 et agilité

Tous les critères et détails fournis dans ce standard sont pertinents. Il répond à des questions simples telles que la valeur d’une...

Test des US

1. Ingénierie des critères d’acceptation des US

Pour fiabiliser la production des US, il faut renforcer la présence des critères d’acceptation (le franglais courant parle de « test d’acceptance ») des US en incluant dans le DoD les conditions nominales sous lesquelles l’US sera acceptée et les situations alternatives les plus critiques qui doivent passer ; en termes de scénarios et de données de tests (voir Optimisation des tests par les valeurs - chapitre Versant industriel du test).

Exemple de test d’acceptation basique pour un service web

Dans le cas du comportement d’une IHM en relation avec un service web, le PO indiquera ce qui sera affiché pour le cas nominal (qu’il définira), mais aussi en cas de non-réponse du backend.

Concept de test

Le PO pourra, avec l’aide de l’équipe, fournir à l’issue du Sprint Refinement la façon dont la spécification pourra être testée :

- par une revue de code,

- par un test unitaire,

- par un test d’intégration,

- par un test d’un sous-système ou bout-en-bout,

- ou par n’importe quelle idée (voir la section Créativité du chapitre Facteur de succès) pour y parvenir au plus tôt et à moindre coût.

a. Définition du Terminé (DoD)

Parmi les éléments que l’on peut trouver dans une Définition du Terminé (en anglais Definition of Done - DoD) de Scrum, on trouvera des critères tels que :

  • développements terminés et présents dans l’outil de gestion de versions de l’équipe ;

  • tests unitaires effectués avec taux de couverture supérieur à X % ;

  • revue de code effectuée ;

  • indicateurs de métrique de code Sonarqube corrects ;

  • critères d’acceptations OK ;

  • modules déployés dans la plateforme ;

  • documentation d’exploitation à jour ;

  • documentation de spécification à jour ;

  • tests de sécurité OWASP OK ;

  • pas de fuite de mémoire.

Ces critères seront détaillés au chapitre Versant technique du test.

DoD Kard

Sur le site https://coach-agile.com, un jeu de cartes est disponible...

Le Produit

Dans le film « Steve Jobs » (voir https://fr.wikipedia.org/wiki/Steve_Jobs_(film)), on peut voir le moment où Steve Jobs prend la main pour le développement des produits Macintosh d’Apple. Il donne l’impulsion à ses équipes sur sa vision du produit en répondant à ses intuitions sur ce qu’il doit être.

Que cette vision soit intuitive ou très formalisée, cela ne dépendra que du contexte : la connaissance du fonctionnement d’un avion de chasse F16 aura un niveau de formalisme et de documentation nécessairement plus poussée qu’une idée innovante à l’état de prototype.

Cependant, il y a une composante qui prend vite le pas dans une activité de test, c’est la connaissance du produit et du métier sous-jacent et c’est la responsabilité du Testeur de découvrir toujours un peu plus du métier dans lequel baigne le produit : cet aspect est critique pour la réalisation de Tests Exploratoires (voir le chapitre Versant industriel du test).

Cette composante doit être assurée :

  • par une stratégie de gestion de la connaissance (voir chapitre Facteurs de succès) autour du produit à partir :

  • du métier concerné par le produit ;

  • de l’écosystème des utilisateurs ;

  • des besoins du client/PO ;

  • des spécificités prévues pour ce produit ;

  • par une personnalité qui incarne les impératifs d’un produit ou d’un service, tel que :

  • les contraintes d’exploitation type ITIL (administration, support, formations, documentation…) ;

  • une vision marketing.

images/I-icone.png

MVP - Minimum Viable Product

La notion de MVP a été popularisée...

La valeur métier

Cette information permettra de prioriser l’effort d’ingénierie et de faciliter les choix en termes de test si le temps vient à manquer.

1. Modèle MoSCoW

L’IEEE propose un système de classement de l’importance des exigences basé sur les verbes anglais « shall » (doit), « should » (devrait) et « may » (pourrait) mais Kurt Bittner propose un système que la culture agile a adopté massivement :

images/03DP07.png

Figure 7 : Modèle MoSCoW [Bittner 2002]

2. Diagramme de Kano

Une autre manière de valoriser l’importance d’une US est l’approche imaginée en 1984 par Noriaki Kano (voir https://fr.wikipedia.org/wiki/Mod%C3%A8le_de_Kano) selon laquelle les fonctionnalités et produits sont répartis en trois catégories :

  • Les fonctionnalités « essentielles/basiques » : celles qui sont attendues de façon impérative, mais qui ne génèrent pas ou peu de satisfaction (ex. : un écran de login).

  • Les fonctionnalités « linéaires » : celles qui fournissent une satisfaction en rapport avec une quantité produite (ex. : le nombre de traitements à la minute dans un batch). 

  • Les fonctionnalités « excitantes » : celles dont tout le monde rêve (même si cela ne dure qu’un temps - ex. : avoir un iPhone dans les années 2000 était attractif tandis que de nos jours, cette caractéristique a pour ainsi dire rejoint le niveau « basique »).

images/03DP08.png

Figure 8 : Diagramme de Kano

Pièges des fonctions essentielles

Les fonctions essentielles posent les difficultés suivantes :

- Lorsqu’elles ne sont pas présentes, les fonctions essentielles soulèvent l’indignation du client (« Les développeurs n’ont même pas fait la base ! »).

- Lorsqu’elles sont boguées, l’utilisateur ne peut...

Production des spécifications

Selon Boris Beizer, cette partie provoque environ 8 % des anomalies d’un produit et la rentabilité des actions préventives et correctives liées aux tests sur les spécifications du produit est évidente, car elles sont situées tôt dans la génération du produit.

1. Cas des exigences et spécifications

Dans le cadre d’une stratégie de test traditionnelle, l’intérêt porté sur ce type d’artéfact tient à deux points :

  • elles font partie de la base de test [ISTQB] et sont donc la matière première des tests, et en tant que tels la qualité des tests s’en ressentira ;

  • parce qu’elles font partie du socle qui définit le produit et constitue une base tangible de la connaissance du produit (voir chapitre Facteurs de succès).

L’apparent point faible de l’agilité est que dans un tel contexte, les exigences/spécifications sont en général les Epics et US, mais la correspondance entre les Epics/US et les spécifications n’est pas 1-1 :

  • une spécification peut être décrite par plusieurs US ;

  • et une US peut couvrir plusieurs spécifications.

Du coup, lorsqu’un nouveau venu est intégré à l’équipe et qu’il n’y a pas de spécifications (le produit n’est décrit que par les Epics et US), le nouveau peut alors être formé sur les éléments qui sont à portée de main (quelques présentations générales et documents utilisateurs) et il prend le train en marche en s’imprégnant des éléments les plus chauds :

  • les US qui sont à réaliser et qu’il faut tester sur ce sprint ;

  • celles qui viennent d’être réalisées ;

  • les Epics qui sont les plus utilisées ou les plus critiques.

Le reste de l’information (qui est intangible) est alors fourni oralement lorsque le besoin se fait sentir.

Lorsque le besoin de l’existence d’un catalogue de spécifications est toutefois présent parce que :

  • les individus ne partagent pas l’information de façon efficace ;

  • des silos de compétences instaurés ralentissent...