Communiquer les tests d'acceptation aux développeurs

Quand et sous quelle forme le directeur de produit fournit les critères de tests d'une histoire d'utilisateur ?

Aujourd'hui j'ai défini des tests d'acceptation [1] pour des histoires d'utilisateur[2]. C'est mon boulot de directeur de produit[3] de préciser les critères qui permettront de s'assurer qu'une histoire est complète. C'est un exercice indispensable si on veut automatiser les tests d'acceptation. Si on n'automatise pas cela reste tout de même très important.

Par exemple pour l'histoire "En tant que participant à un projet, je démarre une tâche du plan", des critères de test que j'ai identifiés sont :

  • on ne peut démarrer une tâche que si elle est dans l'état "prête"
  • seul celui à qui la tâche est affectée peut la démarrer
  • la date est enregistrée lorsque la tâche est démarrée

Comme on le voit, ces critères portent souvent sur des règles de gestion et sur des attributs du modèle métier.

2 points à noter sur ces tests d'acceptation :

  • Les histoires d'utilisateur sur lesquelles j'ai travaillé sont sélectionnées dans le sprint courant qui a déjà commencé. Cela veut dire que les développeurs ont déjà commencé à travailler sur certaines. C'est trop tard : pour une histoire, l'équipe avait fait des choix que j'ai remis en question. Il est préférable que les tests d'acceptation d'une histoire existent avant que le développement de cette histoire ne commence. Ce que je vais essayer pour les prochains sprints, c'est d'avoir préparé ces tests d'acceptation avant que le sprint ne commence [4]
  • Comme je ne suis pas toute la journée avec le reste de l'équipe, la communication passe par un support écrit[5]. Pas de document formel, l'objectif est seulement d'initier une conversation avec les développeurs ou les testeurs chargés d'automatiser les tests.

Notes

[1] ça s'appelait Customer tests dans la première version de XP. On disait aussi Functional Tests. Maintenant on emploie plutôt Acceptance tests. En France on parle dans un autre contexte de test de recette. Pour éviter les confusions, je préfère utiliser test d'acceptation

[2] user stories

[3] product owner

[4] c'est à dire que je définis les tests d'acceptation pendant le sprint n pour une histoire développée dans le sprint n+1

[5] sur un wiki

Commentaires

1. Le vendredi 09 février 2007, 12:02 par Matthieu

Le principe est donc, pendant le sprint n, de prévoir à peu près quelles user stories seront traitées dans le sprint n+1, et de préparer les tests d'acceptation correspondant.
S'ils sont prêts, est-ce une bonne idée de les montrer à l'équipe pendant la réunion de planification de sprint ? (pour améliorer la compréhension)

Au niveau pratique, est-ce que vous avez trouvé un bon outil pour automatiser ces tests d'acceptation ?

Et enfin une autre question un peu plus transverse : comment sont traitées l'IHM et l'ergonomie dans un projet scrum ? est-ce que les user stories en parlent ? est-ce que les tests d'acceptation en parlent ?

2. Le vendredi 09 février 2007, 22:55 par claude aubry
est-ce une bonne idée de les montrer à l'équipe pendant la réunion de planification de sprint ?
oui
est-ce que vous avez trouvé un bon outil pour automatiser ces tests d'acceptation ?
je n'en ai pas utilisé
comment sont traitées l'IHM et l'ergonomie dans un projet scrum ?
comme d'habitude. Ce n'est pas traité par Scrum
est-ce que les user stories en parlent ? est-ce que les tests d'acceptation en parlent ?
non, ils en sont indépendants
3. Le samedi 10 février 2007, 23:24 par Avangel

Bonsoir,

Je termine bientôt mon Master pro IHM à Toulouse, et ce que j'en retiens c'est que les activités IHM sont à placer au même rang que toutes les autres activités nécessaires à la réalisation d'un projet de part en part. Néanmoins, les activités autour de la conception d'IHM de qualité sont coûteuses en temps et en expertise.

A mon avis, une approche intéressante consiste simplement à intégrer un concepteur IHM/ergonome au sein de l'équipe, qui s'occuperait de ces activités à temps plein, tout en communiquant en permanence à l'équipe son expertise pour les guider dans la réalisation d'une IHM de qualité.

Reste à voir comment mêler conception IHM (très basée sur du prototypage basse fidélité évalué de façon itérative) et développement "classique"...

4. Le lundi 12 février 2007, 10:39 par Matthieu

En fait j'essaie de faire un parallèle avec nos projets classiques, pour lesquels ce que veut le client est généralement exprimé sous forme d'une spécification fonctionnelle détaillé (SFD), qui décrit chaque écran et son ergonomie avec :
- une maquette de l'écran
- la description des infos affichées : qu'est-ce que c'est, d'où ça vient, les filtres, les tris
- les actions possibles (clic sur bouton, sélection dans une liste,...), les règles de gestion associées, et les infos sur la navigation (quel écran on affiche après...)

En scrum je vois relativement bien comment les règles de gestion métier sont transmises aux développeurs (user stories, tests d'acceptation, présentation par le directeur de produit en début de sprint puis explications orales au fil de l'eau), mais il me manquait la partie IHM/ergonomie.
Je me suis d'abord dit que le client devait laisser à l'équipe de dev le soin de définir les écrans et leur ergonomie.
C'est d'ailleurs intéressant car ça évite d'avoir des écrans très chers à développer pour une plus-value très relative, et la présence du directeur de produit au moment du dev garantit la correspondance de l'IHM avec les attentes du client.
Ce qui m'inquiétait, c'est l'estimation des user stories : les choix ergonomiques peuvent faire varier sensiblement le coût d'une fonctionnalité, et si on manque d'infos au moment de l'estimation celle ci peut être faussée

Mais en fait je raisonne sûrement de manière trop abstraite : dans la pratique, si une user story appelle une IHM et une ergonomie complexes, ça transparait forcément dans sa description, même si on n'en parle pas directement

5. Le mercredi 14 février 2007, 14:24 par Camille Bloch

Cette vision ne s'applique pas à tous les projets (malheureusement).

Dans notre cas, nous sommes dans un contexte industriel, où les IHM d'outils tiers (dans notre cas, le configurateur d'un système) ne sont pas du tout spécifié, pas même par l'équivalent des user stories.

Dans notre société, il y a plus une culture du fonctionnel que de l'IHM. Les clients (interne ou externe) ne prennent pas part à la conception de l'IHM (lorsque nous leur présentont une "spec", ils la lisent même pas...)

Dans ces conditions, nous devons inclure une composante visuel dans l'expression des besoins. L'outils existe déjà (il est en dev depuis plus de 6 ans maintenant) et nous essayons d'appliquer SCRUM dans ce contexte.

Et en effet, l'estimation d'une user story pose problème quand dans l'équipe nous n'avons pas tous la même vision des composant IHM existant.

Je pense qu'il n'y a pas de réelle solution, si ce n'est en faisant tourner au maximum l'équipe sur chaque sprint pour "distribuer" les connaissances.

6. Le lundi 19 février 2007, 00:19 par Avangel

Il y a une idée reçue autour de l'IHM dont on nous a appris à nous méfier : une IHM sophistiquée a tendance à coûter plus en développement, et on en voit pas l'intérêt. Bien sûr, c'est complètement vrai si ce qui rend l'IHM sophistiquée se limite à des gadgets graphiques "pour faire joli" et qui n'apportent rien à l'utilisabilité du logiciel.

En revanche, il a des techniques d'interaction plus coûteuses à mettre en place, mais qui vont permettre aux utilisateurs de gagner beaucoup en efficience, et là il ne faut pas passer à côté : ce sont rapidement des milliers d'heures d'économisées à l'échelle du nombre d'utilisateurs.

Quant au fait de faire passer des écrans IHM dans une spec, je suis complètement contre : ça revient à faire du Big Design UpFront de l'IHM, et on en revient aux principes fondamentaux des méthodes Agiles. D'ailleurs, ça ne plaît pas à bon nombre de mes profs :)

Je pense que dans le cas de tâches utilisateur complexes, il est vraiment important de consacrer du temps à la conception d'une IHM de qualité. Dans un tel cas, une solution simple consiste à créer une User Story dédiée à la conception+réalisation de cette IHM. Même si ce n'est pas une fonctionnalité au sens propre, elle aura de la valeur pour le client : c'est ce qui doit déterminer la légitimité d'une User Story.

7. Le lundi 19 février 2007, 11:24 par Stéphane Boisson

Avangel: Qu'est-ce qui ne plait pas à bon nombre de tes profs?

8. Le mardi 20 février 2007, 08:24 par Avangel

Pardon, à la relecture, c'était ambigü :) Ce qui ne leur plaît pas, c'est que je prône de ne pas faire du BDUP sur l'IHM, mais au contraire de la concevoir et la réaliser de façon itérative. Il y a dans le monde IHM un courant de pensée qui dit qu'une fois l'interface entièrement conçue, maquettée et testée, son développement n'est qu'un détail.

C'est comme ça qu'ils payent des sociétés spécialisées une fortune pour 6 mois de boulot à produire un prototype sur une plateforme spécialisée, et que dans la foulée ils font le développer par un autre sous-traitant. Moralité de l'histoire, la version finale ne vaut plus grand chose comparée au prototype : une autre plateforme de développement, des gens qui ont des compétences différentes, etc.

9. Le mardi 20 février 2007, 11:25 par Matthieu

Une petite précision tout d'abord : je n'ai encore jamais eu l'occasion de travailler avec un ergonome. Sur toutes les applications que j'ai connues l'IHM a été conçue par des gens qui, comme moi, n'ont pas de compétences particulières dans ce domaine.
J'ai donc du mal à voir ce qu'il y a exactement derrière la phrase "une fois l'interface entièrement conçue, maquettée et testée, son développement n'est qu'un détail", car ça ne m'évoque qu'une maquette html avec quelques liens statiques permettant de naviguer entre les pages, qui donne un bon aperçu mais ne prétend pas montrer tous les aspects ergonomiques.

Pour en revenir à la conception de l'IHM en mode agile, je pense que c'est la même problématique que pour la conception technique : il vaut mieux considérer l'ensemble de l'application au début pour faire des choix généraux et structurants qui resteront pertinents au fil de l'avancement du projet, mais faire la conception détaillée au fur et à mesure de chaque itération, pour profiter au mieux du feedback des itérations précédentes.

Par exemple si certaines demandes des utilisateurs sont impossibles à gérer en client léger, il vaut mieux s'en rendre compte tout de suite et partir directement sur du client riche ou du client lourd que devoir changer en cours de projet. Par contre d'autres choses, comme par exemple le niveau de richesse et de complexité des écrans (un écran complexe ou plusieurs écrans simples), peuvent être ajustés en cours de projet en utilisant le feedback sur un écran pilote.

Et quand je parle de feedback je pense à celui des utilisateurs bien sûr (est-ce que c'est vraiment pratique et intuitif à utiliser), mais aussi à celui de l'équipe de dev (est-ce que c'est couteux à faire, est-ce que ça pose des problèmes techniques particuliers).

C'est la combinaison de ces 2 feedbacks qui devraient permettre au directeur de produit de généraliser, de restreindre à certains écrans, voire d'abandonner certains choix ergonomiques.

Enfin bon, c'est comme ça que j'imagine les choses... ;o)

10. Le mardi 20 février 2007, 13:59 par Stéphane Boisson

Pour info, InfoQ a publié un article interessant:

Agile User Interface Development
www.infoq.com/articles/ag...