Tests d’acceptation

Les tests d'acceptation du résultat sont définis avec les utilisateurs et passés pendant l'itération.

Bénéfice

Définir les tests avec les utilisateurs et les passer pendant l'itération donne un critère de qualité partagé, en contournant l'obstacle du Stress de l'engagement forcé où la date et le périmètre sont fixés sans dire ce qui sera vérifié.

Mise en pratique

Les tests s'écrivent avant de réaliser la story, avec ceux qui vont s'en servir : ils servent de conversation autant que de vérification.

Recommandation

Les écrire dans les mots des utilisateurs et sur des exemples concrets : un test qu'ils ne peuvent pas lire ne les engage pas.

Antipattern

• Constatation : sous prétexte de couvrir le besoin, on multiplie les tests d'acceptation jusqu'à en faire une recette exhaustive.
• Risque : leur écriture et leur maintenance coûtent plus qu'ils ne rapportent, et on finit par les désactiver.
• Réduction du risque : peu de tests, choisis sur les cas qui comptent pour l'usage, et revus quand le besoin change.

Avec l'IA ?

• Constatation : L'IA génère facilement des jeux de tests nombreux et bien formés à partir d'une story.
• Risque : Les tests décrivent ce que le code fait plutôt que ce que les utilisateurs attendent ; l'acceptation n'est plus discutée avec eux.
• Réduction du risque : Faire venir les cas des utilisateurs eux-mêmes ; l'IA peut les mettre en forme, pas décider de ce qui est acceptable.

Pratiques en relation

• Définition de fini
• Voix des utilisateurs