Discussion :

[zaboug]

Bonjour à tous,

je débute un projet Scrum (premier sprint activé la semaine prochaine) et je suis en train de commencer à rédiger les tests d'acceptation pour les premières stories.
Mais je me heurte à un problème pour la première story qui est une story technique concernant la mise en place de l'architecture (projet web multi couche type JPA - Hibernate et peut être spring) : je ne vois pas comment écrire un test d'acceptation sur ce genre de story !
D'où ma question : est-il possible d'écrire des tests d'acceptation pour une story technique et si oui, avec quelle méthode? (car j'ai du mal à imaginer un "given ... when ... then ..." sur de l'architecture )
Si non, on se contente des tests unitaires j'imagine...

tout conseil sera bon à prendre
merci d'avance !

[Drawingrom]

Bonjour,

Difficile à dire, les US devraient normalement pas couvrir de points purement techniques. Certes, la mise en place de l'architecture technique est un poste de cout qu'il peut être souhaitable de faire apparaitre mais par essence un backlog n'est pas fait pour ça.

Je pense que tu peux te contenter de rédiger des tests d'acceptation pour des items fonctionnels. Ces tests couvriront également la partie technique.

Tu peux coder des tests d'intégration qui permettront de valider ton architecture et d'assurer la non régression pendant le projet mais ce ne sera pas vraiment des tests d'acceptation. Ils n'ont pas de valeur fonctionnelle.

[zaboug]

Merci.
ça confirme un peu ce que je pressentais...

[tchize_]

l'architecture ne devrait pas faire partie du backlog. Elle va apparaitre dans le sprint sous forme de tâches, mais son cout sera répartis sous forme de cout sur les user stories qui en dépendent. Ainsi, il ne faut pas avoir de user stories qui dépendent d'une autre. Une US c'est un besoin concret du client. Evidement, si le client a comme besoin concret "je dois pouvoir me connecter à l'application avec du JPA"

Exemple: J'ai trois user stories du type "Je dois pouvoir stocker et afficher un ensemble de metadatas sur les document". Inévitablement si vous n'avez "rien" d'existant, cette story impliquera la création de DAO (ici via JPA), peut -être de spring pour la configuration etc. Donc, du coup, la US aura pas mal de points de complexité. Une deuxième US similaire aura les mêmes complexité.

Une fois la première réussie et validée, on peut décement supposer que la deuxième deviendra plus facile (car elle a des tâches en commun avec la première qui sont déjà réalisée) mais il faudra attendre que cette réalisation de le première soit faite pour diminuer le cout associé à la deuxième. C'est pour ça qu'on réévalue régulièrement au niveau du backlog en attente les couts, la buisness value et donc au final la rentabilité de la story

A noter qu'on peux aussi prendre le temps avec le client une semaine avant le premier sprint de mettre en place une architecture de base. Mais mieux vaut éviter de trop la détailler (par expérience on a tendance à mettre dedans plain de trucs qui sont au final inutle et, inversément, d'oublier des trucs qui seront au final nécessaire, tout ça parce que le backlog, ca change au cours du temps )

[zaboug]

je comprends bien ce que vous dites et suis assez d'accord avec vous.
Cela dit, je m'interroge : pourquoi les stories techniques existent s'il ne faut pas les utiliser?
J'applique Scrum pour la première fois après l'avoir étudié d'abord dans le livre de Claude Aubry [1], et ensuite en suivant une formation de 3 jours avec ce même Claude Aubry. Et que ce soit dans le livre ou dans la formation, on a vu qu'il y a trois types de stories :

• user story
• story technique
• défaut

Mais du coup je m'interroge, dans quel cas on peut avoir une stroy technique ?

[1] : SCRUM - Le guide pratique de la méthode agile la plus populaire.

[hegros]

Tu peux toujours te débrouiller pour écrire des TA techniques après tout des tests c'est surtout du détails. Tu peux par exemple écrire un test qui dit que l'architecture doit être fonctionnelle sur du Windows ou sur du Linux ou sur du 32 bits ou 64 bits avec tel ou tel service pack Et tu peux l'écrire en given/when/then

Par exemple

Soit un système Windows 7 en 64 bits
Et un composant Spring/Hibernate version truc
Lorsque l'architecture est déployée
Alors l'ensemble des composants est opérationnel et communique.


Pour les tests unitaires c'est probablement plus lourd cependant cela reste implémentable et ressemblerait à ton Given/When/Then. En gros, dans le given tu charges une VM qui va bien pour le When tu déclenches ton installateur et dans le Then tu vérifies que tout est bien installé

La véritable problématique avec ce genre de tests c'est que cela à un coût non négligeable et qu'il faille donc découper en story technique plus petite.