Discussion :

[cedric190985]

Bonjour,
dans le cadre d'une présentation technique pour mon entreprise (et ouverte à tous via notre blog technique) je dois faire une présentation sur l'agilité et le test
Deux choses qui ne s'entendent pas vraiment si on en croit la littérature et mon expérience en entreprise. (faut faire des concessions coté processus agile et test)

Je suis à la recherche donc de documentation ou retour d'expérience à ce sujet
J'ai comme base de doc le sylabus cftl sur la certification agité test

Merci d'avance

[Luckyluke34]

Deux choses qui ne s'entendent pas vraiment si on en croit la littérature et mon expérience en entreprise. (faut faire des concessions coté processus agile et test)

Ah... j'ai plutôt l'expérience du contraire De quels types de tests parles-tu ?

Il y a des bouquins sur le sujet, à creuser peut être.

[el_slapper]

Tout dépend de ce qu'on entend par "assurance qualité". Si c'est juste tester le produit fini pour le renvoyer en fabrication, oui, c'est plus facile à mettre en place en waterfall. Si c'est mettre en place un ensemble de pratique pour s'assurer, à chaque étape, que l'on est conforme, c'est parfaitement possible en agile... à condition de s'en donner les moyens(en gros, à peine compilé et vérifié par de développeur, déjà disponible pour le testeur, que celui-ci se farcisse les tests à la main ou via des automates).

[Laurent 1973]

Si je devais parlé d'Agilité et de test dans une présentation, je ne pourrais pas ne pas parler de la pyramide de tests.

Pour cela, je te propose de lire le blog de Martin Fowler sur le sujet (http://martinfowler.com/bliki/TestPyramid.html)
Si tu as l'occasion de lire un de ses bouquins, c'est très riche d'enseignement sur le développement agile.
Et sinon, je trouve que la présentation en français de Jean-Paul SUBRA (http://softmethods.fr/la-pyramide-de-tests/) est plutôt bien faite.

Ensuite, qui dit test & agilité, forcément nous viens à l'idée le Test Driven Developpement (TDD) fortement promu par la méthode agile eXtrem Programming.
Cette technique pourrait se résumer à "écrire les tests avant de coder le logiciel".
Je te dirige aussi sur le blog de Martin (http://martinfowler.com/articles/is-tdd-dead/) sur un échange sur le sujet entre Kent Beck et David Heinemeier Hansson.
En version française plus simple, je te conseil le tutoriel de Bruno Orsier (http://bruno-orsier.developpez.com/t...DD/pentaminos/) qui permet de bien comprendre comment mettre en place le TDD.

Une bonne pyramide de tests ou développer en TDD est coûteux, ne nous cachons pas la face
Par contre, je pense que cela donne une qualité extrêmement haute au logiciel développer ainsi.
Et finalement, sur le coût de support, corrections, image de marque, ... je pense que l'on est largement gagnant.

Donc, contrairement à ce que tu as pu lire ici ou là, les tests et l'agilité font, au contraire, très bon ménage.
Par contre, cela nécessite de repenser complètement ça façon d'aborder la validation et le contrôle qualité.
Le test doit complètement faire partie du développement et pas seulement, comme en waterfall, une simple phase de contrôle avant la livraison.

[cedric190985]

Merci à tous pour vos réponses.
En fait je remarque que j'ai été très flou dans ma question

Je parlais ici bien de qualité logiciel en gros

• test d'intégration
• test système
• test d'acceptance
• mise en place d'une NR
• test d'interface (IHM/"I/O")
• gestion des retours

J'ai déjà mis en place

• un processus dans mon entreprise en m'incluant dans les sprints sans rallongés la durée
• la livraison de chaque User Story de facon indépendante (respect de INVEST)
• la mise en place d'environnement dédié (Homol/PP)
• gestion d'un retour d'anomalie

[Laurent 1973]

Là où l'Agilité change la façon de penser par rapport à du Waterfall, c'est que la qualité doit être présente à tout moment et pas seulement dans les phases de tests.

Si tu a mis en place des itérations avec une livraison potentiellement livrable en fin, tu as donc bien compris que ton logiciel doit être validé, testé, éprouvé à chaque itération.
Et pour cela, c'est très difficile de le faire en fin d’itération si cela ton produit n'est pas tester en continue, a chaque 'commit' des développeurs.
=> d'où un environnement d’intégration continue à mettre en place.

La pyramide des tests est importante justement pour pouvoir faire le plus souvent possible, les tests les moins coûteux.
Et bien sur, il faut faire en sorte que le maximum de tests (unitaire, d’intégration, fonctionnel voir même graphique) puissent se faire en automatique.

Pour assurer une logique de "potentiellement livrable" à chaque itération, il est bien que les tests manuels puissent être tous réaliser en 1 h si toute l'équipe s'y met.
Comme cela, tu peux même te permettre de les dérouler à mi-sprint, pour avoir un aperçu de l'évolution.

Si tu veux aussi parler de qualité au sens certification ISO-9001, c'est tout a fait possible aussi dans un monde agile.
Dans ma précédente entreprise, on l'avait mis en place.

En gros, on avait décris Scrum (+un peu de XP) comme notre processus de travail à respecter.
On signait un formulaire qualité au début de sprint validant le "Sprint backlog" et un autre juste avant la "review meeting" pour clôturer le sprint et la version potentiellement livrable.
On avait en plus 2-3 formulaires spécifique en cas de défaut, d’interruption de sprint (très rare, mais possible) ou d'autres impondérables.
C'était à la fois simple, pas trop contraignant pour les développeurs et la certification ISO-9001 fut obtenu sans souci, démontrant vraiment notre haute qualité de travail.

je dois faire une présentation sur l'agilité et le test
Deux choses qui ne s'entendent pas vraiment si on en croit la littérature et mon expérience en entreprise.

Je suis toujours interloqué par ce que tu dis.
Ou alors, la vision des tests de votre entreprise est très particulière.
Pour moi, l'agilité est justement des méthodes et des principes qui tends à améliorer la qualité des produits que nous développons.
Sans tests, je ne sais pas comment assurer de la qualité.

J'aimerais bien savoir ce que tu as lu au sujet de faire des concessions coté processus agile et test pour les faire cohabiter.
Pour moi, j'en vois pas, bien au contraire: les tests font totalement parties des méthodes agiles, il se renforce mutuellement.

[chikko]

Bonjour à tous,

Je suis assez d'accord avec Cédric pour dire que les cycle de développement Agile et les test ne sont pas toujours facilement compatibles ensembles.
Attention je parle ici des tests QA et non des tests automatisés que peuvent faire les développeurs.

Dans le cadre d'un processus agile en Kamban, il est facile d’intégrer le QA au processus -> les tests peuvent être fait à chaque nouvelle fonctionnalité.

En revanche avec la méthode Scrum c'est plus compliqué. En effet, le QA ne peut pas commencer à tester tant que les développeurs n'ont pas fini de développer les fonctionnalités (donc n'ont pas fini le sprint). Une fois le sprint terminé, le QA peut commencer à tester et remonter les bugs au développeurs, mais ceux-ci seront déjà dans le sprint suivant. Cela peut créer des retard de livraison, voir même invalider un sprint. Les dév souhaitent que les bugs soient remontés le plus vite possible, or ils n'arrivent qu'après la fin du sprint. Donc oui je suis d'accord pour dire que ce n'est pas évident d'intégrer les tests QA dans la méthode Scrum.

Une solution pour limiter ce problème est d'utiliser le BDD. Le BDD permet de créer des tests automatique de comportement du produit. Le QA et/ou le PO écrivent ensemble les tests BDD avant le début du sprint, puis les développeurs utilisent ces tests pour valider pendant le sprint les fonctionnalités. Les test BDD sont joués par l'intégration continue et sont écrit au format texte. Ils peuvent donc être écrit par les dév, les QA ou le PO.
Cela ne résout pas tous les problèmes, mais permet de limiter le nombre de bugs et de faciliter le travail du QA et des dév. Cela permet aussi de rapprocher les dév et le QA, ce qui ne peut être que positif !

Regarde dans cette direction tu y trouveras peut-être ton bonheur

[Laurent 1973]

Une solution pour limiter ce problème est d'utiliser le BDD. Le BDD permet de créer des tests automatique de comportement du produit. Le QA et/ou le PO écrivent ensemble les tests BDD avant le début du sprint, puis les développeurs utilisent ces tests pour valider pendant le sprint les fonctionnalités. Les test BDD sont joués par l'intégration continue et sont écrit au format texte. Ils peuvent donc être écrit par les dév, les QA ou le PO.
Cela ne résout pas tous les problèmes, mais permet de limiter le nombre de bugs et de faciliter le travail du QA et des dév. Cela permet aussi de rapprocher les dév et le QA, ce qui ne peut être que positif !

Je te rejoints complètement sur ta remarque, il faut penser autrement pour lier les tests qualités et l'agilité.
Le BDD que tu décris est une très bonne illustration de penser cette validation en amont et incluse à l’intégration continue.

Une équipe scrum ne comprend pas que des développeurs, mais le QA peux aussi en faire aussi partie.
Dans la "Definition of Done" (DoD) d'une story, la notion de validation qualité a totalement sa place.

[Luckyluke34]

En revanche avec la méthode Scrum c'est plus compliqué. En effet, le QA ne peut pas commencer à tester tant que les développeurs n'ont pas fini de développer les fonctionnalités (donc n'ont pas fini le sprint).

Je ne suis pas tout à fait d'accord avec les parties en gras. Dans notre équipe actuellement, on a un testeur intégré et il teste dès qu'une user story est prête ou même dès qu'un acceptance test est passé à Ready For Test par un développeur. Si on a bien découpé les user stories, elles sont tout à fait testables en cours de sprint. Ca fonctionne très bien chez nous. Pour les fonctionnalités prêtes en fin d'itération, on se réserve 1/2 journée finale où les développeurs arrêtent d'écrire du code (ils préparent la démo du lendemain et font d'autres tâches) pendant que le testeur peut finir ses tests.

Le QA et/ou le PO écrivent ensemble les tests BDD avant le début du sprint, puis les développeurs utilisent ces tests pour valider pendant le sprint les fonctionnalités. Les test BDD sont joués par l'intégration continue et sont écrit au format texte. Ils peuvent donc être écrit par les dév, les QA ou le PO.
Cela ne résout pas tous les problèmes, mais permet de limiter le nombre de bugs et de faciliter le travail du QA et des dév. Cela permet aussi de rapprocher les dév et le QA, ce qui ne peut être que positif !

Tout à fait. Sans aller jusqu'à du BDD, on peut comme je le disais associer à chaque user story des acceptance tests avant le début du sprint. La collaboration entre QA et dev est effectivement cruciale (d'où l'idée d'intégrer le testeur dans l'équipe pluridisciplinaire).

[cedric190985]

Rebonjour,
Déjà un grand merci pour cette échange très intéressant qui met en avant le BDD.

Méthode que je ne comprends pas du tout, à mes yeux cette méthodes ressemblent énormément au ATDD (je viens du monde du ATDD donc j'ai un penchant pour cette méthode), en effet si on regarde la structure d'une US, on va retrouver le done à la fin de chaque US et à partir de ce done, les QA/PO rédigent les cas de tests correspondant et les développeurs s'appuient sur ces cas de tests pour leur développement.
La structure du cas de test est sous la forme classique (à la différence du BDD qui doit respecter une convention), je trouve d'ailleurs cette forme plus facile à comprendre que la forme "Given When Then" surtout venant de PO non informaticien (déjà pour avoir des US correctes faut se battre alors des cas de tests c'est quasi une illusion)


Pour être transparent avec vous j'ai mis en place un processus en 4 phases que je vais détailler en sachant que j'ai une approche RBT (Risk-based testing) pour mes campagnes ((impact * fréquence) * business) et 4 envs (dev/homol/PP/Prod)


1ère phase (avant le sprint)

• préparation des US avec les PO
• échange sur la forme
• validation des mokeup
• mesure des risques
• rédaction des tests critiques P0

2ème phase (début du sprint)

• rédaction des test P1/P2/PN
• mise à jour de la NR
• préparation des JDR
• rédaction des tests automatisés
• clôture des tickets

3ème phases (pendant le sprint --> livraison en homol)
les US sont tous livrés en même temps (merci SCRUM) à la différence de Kanban ou elles sont livrés au fil de l'eau

• campagne de test d'acceptante fonctionnelle du produit

On cherche ici à passer l'ensemble des cas de tests P0 (et plus si affinité), l'intérêt est de livrer un produit en PP conforme au US
Durant cette phase seuls les QA ont accès à l'env

3ème phases (sprint terminé --> livraison en PP)

• Démo du produit en PP
• Campagne de test standard
• Tir de performance

On cherche ici à passer l'ensemble des cas de tests (acceptance fonctionnelle/UX/interface I/O)
Durant cette phase les QA/P0 ont accès à l'env

4ème phase (livraison en prod)

Entre les phases 2 --> 3 et 3 --> 4, les risques sont utilisés pour déclencher la livraison (en suivant le principe de Pareto), si la US ne passe pas les critères d'acceptante, elle est refusé pour ce sprint

Bien entendu on est ici dans un monde idéal et les US sont écrit en suivant le principe INVEST, que l'équipe QA est assez nombreuse (1 pour 5 devs) et que la vélocité ne doit pas trop élevé.
Malheureusement trop souvent les Us sont interdépendante et il est compliqué de faire admettre au PO qu'une batterie d'US doit être refusé.

[Luckyluke34]

Méthode que je ne comprends pas du tout, à mes yeux cette méthodes ressemblent énormément au ATDD

Oui, dans la démarche les deux méthodes sont très voisines et l'une emprunte à l'autre. Un article pour mieux comprendre les différences (ou les non-différences) : http://lizkeogh.com/2011/06/27/atdd-...related-stuff/

La structure du cas de test est sous la forme classique (à la différence du BDD qui doit respecter une convention), je trouve d'ailleurs cette forme plus facile à comprendre que la forme "Given When Then"

La convention est là pour faciliter l'automatisation et réutiliser les mêmes Given/When/Then dans différents tests ce qui donne des tests plus maintenables. C'est un des gros intérêts de BDD.

surtout venant de PO non informaticien (déjà pour avoir des US correctes faut se battre alors des cas de tests c'est quasi une illusion)

Je pense qu'il est illusoire de vouloir laisser la rédaction de tests BDD dans les mains du seul PO. Ca doit être un travail collaboratif avec au moins une personne technique (QA, dev).

[cedric190985]

Merci à tous pour votre aide la présentation est en cours de relecture avant publication