En tant que responsable de l'assurance qualité travaillant sur des projets Agile depuis deux ans et demi, il s'agit d'une question vraiment difficile et je n'ai pas encore toutes les réponses.
Je travaille au sein d'une "triplette" (deux développeurs qui programment en binôme + un AQ) et je participe à l'attribution des histoires et à l'estimation lors des réunions de planification au début des itérations de deux semaines. Comme adrianh l'a mentionné plus haut, il est essentiel que les AQ fassent entendre leur voix lors de la planification initiale du sprint. Cela peut être difficile, surtout si vous travaillez avec des développeurs à la personnalité très forte, mais les AQ doivent s'affirmer au sens propre du terme (c'est-à-dire sans agressivité ni force, mais en cherchant respectueusement à comprendre la vérité/le responsable et les développeurs/experts techniques tout en se faisant comprendre). Je préconise de produire les tâches d'assurance qualité en premier lieu lors de la planification afin d'encourager une mentalité axée sur les tests - l'assurance qualité peut avoir à se mettre littéralement en avant pour que cela soit adopté. C'est à l'opposé de la façon dont beaucoup de gens pensent que le développement de logiciels fonctionne, mais cela rapporte des dividendes pour plusieurs raisons ;
-
L'AQ est entendue et n'est pas reléguée à la question "comment allez-vous tester cela ?" après que les développeurs ont dit leur mot (mentalité de cascade).
-
Cela permet à l'AQ de proposer des idées de test qui, en même temps, vérifient la testabilité des critères d'acceptation, tandis que le responsable de la vérité est présent (j'ai bien dit qu'il est essentiel qu'il soit présent à la réunion de planification, n'est-ce pas ?
-
Il constitue la base d'une approche axée sur les tests - une fois que l'approche des tests a été énoncée et que les tâches ont été définies, les développeurs peuvent réfléchir à la manière dont ils produiront le code qui passera ces tests.
-
Si les étapes 1 à 3 sont votre seule activité TDD pour le reste de l'itération, vous faites quand même un million de fois mieux que le scénario postulé par Steve dans le premier message : "Les développeurs s'agitent en essayant d'accomplir leurs tâches. Généralement, les tâches prennent la plus grande partie du sprint à compléter. L'AQ harcèle les développeurs pour qu'ils publient quelque chose qu'ils puissent tester, les développeurs finissent par envoyer un code bogué à l'AQ un jour ou deux avant la fin du sprint et passent le reste du temps à corriger les bogues que l'AQ trouve".
Il va sans dire que cela s'accompagne de quelques réserves pour l'AQ ;
-
Ils doivent être prêts à voir leurs idées de test remises en question par les développeurs et les responsables de la vérité et à parvenir à un compromis ; l'attitude de "police de l'assurance qualité" ne fonctionnera pas dans une équipe Agile.
-
Les tâches d'assurance qualité doivent trouver un équilibre difficile pour n'être ni trop détaillées ni trop génériques (les tâches peuvent être écrites sur une carte pour être placées sur un "tableau radiateur" et discutées lors des réunions quotidiennes de stand up - elles doivent passer de "en cours" à "terminées" PENDANT l'itération).
-
Les AQ doivent se préparer aux réunions de planification/estimation. Ne vous attendez pas à pouvoir vous présenter et produire une approche de test de but en blanc pour des histoires d'utilisateurs inconnues ! Les développeurs semblent pouvoir le faire parce que leurs tâches sont souvent beaucoup plus claires - par exemple, "changer le module x pour qu'il s'interface avec le composant z" ou "remanier la méthode y". En tant qu'AQ, vous devez vous familiariser avec la fonctionnalité introduite/modifiée AVANT de planifier afin de connaître la portée des tests et les techniques de conception des tests que vous pourriez appliquer.
-
Il est presque essentiel d'automatiser vos tests et de les avoir écrits et "échoués" dans les deux ou trois premiers jours d'une itération ou au moins pour coïncider avec le moment où les développeurs ont le code prêt. Vous pouvez alors exécuter le(s) test(s) et voir s'il(s) passe(nt) comme prévu (AQ TDD correcte). C'est ainsi que vous évitez une mini-cascade à la fin des itérations. Vous devriez vraiment faire une démonstration du test aux développeurs avant ou pendant qu'ils commencent à coder, afin qu'ils sachent ce qu'ils doivent viser.
-
Je dis que 4 est "presque essentiel" parce que la même chose peut parfois être réalisée avec succès avec des listes de contrôle manuelles (j'ose dire scripts !) du comportement attendu - la clé est de partager cela avec les développeurs à l'avance ; continuez à leur parler !
En ce qui concerne le point 2 ci-dessus sur le sujet des tâches, j'ai essayé de créer des tâches aussi granulaires qu'une demi-heure à 2 heures, chacune correspondant à un élément de travail démontrable, par exemple "Ajouter des vérifications pour le mot de passe incorrect au test automatique - 2 heures". Bien que cela m'aide à organiser mon travail, les autres membres de l'équipe m'ont reproché d'être trop détaillé et, lors des réunions, j'ai soit déplacé plusieurs tâches de la veille pour les terminer, soit été incapable de déplacer des tâches parce que je ne les avais pas encore commencées. Il est donc plus utile de créer des tâches par blocs d'une demi-journée ou d'une journée (mais vous pouvez conserver votre propre liste de "micro-tâches" à réaliser en vue de l'achèvement des tâches plus importantes, que vous utilisez pour COMMUNIQUER les progrès globaux lors du stand-up).
En ce qui concerne les points 4 et 5 ci-dessus, les tests automatisés ou les listes de contrôle manuelles que vous préparez en amont ne devraient couvrir que les chemins heureux ou les critères d'acceptation clés. Une fois que ceux-ci sont passés, vous pouvez avoir prévu une tâche supplémentaire pour une dernière série de "tests exploratoires" vers la fin de l'itération pour vérifier les cas limites. Ce que les développeurs font pendant ce temps est problématique car, en ce qui les concerne, le code est "complet" à moins que et jusqu'à ce que vous trouviez un bug. Certains praticiens Agile préconisent d'aller pour les cas limites d'abord, mais cela peut aussi être problématique parce que si vous manquez de temps, vous pouvez ne pas avoir assuré que les critères d'acceptation ont été livrés. Il s'agit d'une de ces décisions finement équilibrées qui dépendent du contexte de l'histoire de l'utilisateur et de votre expérience en tant qu'AQ !
Comme je l'ai dit au début, je n'ai pas encore toutes les réponses, mais j'espère que ce qui précède vous donnera quelques conseils issus d'une expérience difficile !
