Yes, there are some books in french!
On trouve maintenant 4 livres en français sur Scrum. Il y a bien d’autres sur l’agilité qui parlent aussi de Scrum ou simplement l’évoquent, mais seuls ceux-ci ont un titre qui contient le mot Scrum.
Au lieu de test d'acceptation, spécification par l'exemple serait probablement plus approprié
Les tests d’acceptation (au sens agile) remplacent une spécification fonctionnelle détaillée. Avec un bénéfice essentiel : la communication est facilitée entre le métier et le développement.
Méta-modèle
Après le TDD, voici l’ATDD.
Spécification par l'exemple
Trouvé via le blog de Karl, un article publié dans le très sérieux magazine IEEE Software qui fait l’hypothèse d’une équivalence entre les tests et les exigences.
Voire même Behaviour Driven Development
Un test, c’est une expérimentation menée pour révéler des informations, ou en réponse à une question précise sur un logiciel ou un système.
Dans le cadre d’une approche agile basée sur les histoires d’utilisateur (user stories), un test d’acceptation est un test qui permet au client (ou au Product Owner) de dire s’il accepte, en fin d’itération, une histoire d’utilisateur développée par l’équipe. Un test est accroché à une story, qui en possède généralement plusieurs.
Pour décrire les tests d’acceptation, ma préférence va à une technique orientée comportement, le BDD.
…ou comment rendre inutile la rédaction de spécifications détaillées !
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 :
Janvier c'est l'époque des voeux et des prévisions
Je viens de lire les prévisions de Fred Cavazza sur le Web2.0 et les anticipations de Louis Naugès sur la bureautique2.0. Et si on faisait l’exercice pour le domaine des méthodes Agiles ?
J'ai posé quelques questions pour les partiels de décembre des étudiants et maintenant me voilà avec une pile de copies à corriger…
Cette année, mes questions étaient ouvertes et la correction n’est pas facile. Il me faut lire entre 5 et 8 pages bien remplies par étudiant. Avec une trentaine d’étudiants, ça doit faire dans les 200 pages.
Le plus souvent c’est plein de fautes d’orthographe. Dans la seule copie où je croyais ne pas en trouver, il est écrit à 2 lignes de la fin : “il … est choisit…”. Dommage, mais cela ne me gêne pas. Plus embêtant pour ma lecture, c’est que ce n’est pas toujours bien présenté ni bien écrit.
Mais j’y trouve quand même du plaisir à voir que ce que j’ai présenté a été bien compris. Et puis je découvre toujours quelques perles amusantes.
