Versant 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 :

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

Figure 1 : une bonne US est "INVEST"

Clarté d’une US

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

Test des US

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 :

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 :

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 »).

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.