Agile et Scrum pour les QA Engineers: Ce que Vous Devez Vraiment Savoir

L'Agile et Scrum définissent comment les ingénieurs QA travaillent dans la plupart des équipes produit. Le framework détermine quelles cérémonies vous attendez, comment les tests s'intègrent dans un sprint de deux semaines, et ce que "terminé" signifie dans un cycle de livraison itératif.

Waterfall vs Agile : pourquoi ça compte

L'ancienne façon de construire des logiciels était le Waterfall : d'abord les exigences, ensuite le design, ensuite le développement, ensuite le QA, ensuite la release. Chaque phase se terminait avant que la suivante commence. Le QA arrivait à la fin, après que tout était construit.

Le problème : au moment où le QA trouvait un bug, il était là depuis des mois. Le corriger signifiait revenir sur des décisions d'architecture dont personne ne se souvenait clairement. Les releases étaient risquées parce que de larges lots de changements non testés sortaient d'un coup.

L'Agile est la réponse à ça. Au lieu d'une grande release après des mois de travail, vous construisez et livrez en petits incréments, typiquement des cycles de deux semaines. Le QA fait partie de chaque cycle, pas d'une phase après.

Ça change ce à quoi ressemble le travail d'un ingénieur QA. Vous testez les fonctionnalités au fur et à mesure qu'elles sont construites, pas après que tout est terminé. Vous êtes dans les réunions de planification, pas uniquement dans les réunions de test. Votre feedback influence les décisions de design avant que le code soit écrit.

Le framework Scrum

L'Agile est un ensemble de valeurs et de principes. Scrum est le framework spécifique que la plupart des équipes utilisent pour le mettre en oeuvre. Quand quelqu'un dit "on travaille en Agile", il veut presque toujours dire Scrum.

Rôles

Propriétaire du product backlog : la liste priorisée de tout ce que l'équipe va construire. Le PO décide ce qui est construit et dans quel ordre, en fonction de la valeur métier. Ce n'est pas un rôle technique, mais il doit comprendre ce dont les utilisateurs ont besoin et l'expliquer assez clairement pour que les développeurs puissent le construire.

Facilite le processus. Anime les cérémonies, lève les blocages, protège l'équipe des interruptions externes. Ce n'est pas un manager ; il n'assigne pas le travail. Plus un coach de processus.

Généralement 5 à 9 personnes : développeurs, ingénieurs QA, parfois UX. L'équipe est multifonctionnelle et collectivement responsable de la livraison d'un logiciel fonctionnel.

Dans Scrum, le QA fait partie de l'équipe de développement, pas à part. Vous n'êtes pas "le département QA qui révise le travail des développeurs". Vous êtes un membre de l'équipe avec un ensemble de compétences spécifiques qui contribue à un objectif commun.

Artefacts

La liste complète des fonctionnalités, correctifs de bugs et travaux techniques que l'équipe pourrait réaliser. Le PO en est propriétaire et la priorise. Les éléments en haut sont les plus importants et les plus détaillés. Ceux en bas sont vagues. Ils seront affinés quand ils se rapprocheront du sommet.

Le sous-ensemble du product backlog que l'équipe s'engage à terminer lors d'un sprint. Créé pendant le Sprint Planning.

Le format standard pour les éléments de backlog :

En tant que [type d'utilisateur],
Je veux [un objectif],
Afin de [une raison].

Exemple :

En tant qu'utilisateur enregistré,
Je veux filtrer les éléments par statut,
Afin de voir rapidement uniquement les éléments en cours.

Les user stories décrivent l'intention, pas l'implémentation. Comment le construire est la décision de l'équipe.

Les conditions spécifiques qu'une story doit remplir pour être considérée comme terminée. Écrits par le PO, validés par le QA.

Exemple :

Given je suis sur la page des éléments
When je sélectionne "En cours" dans le filtre de statut
Then seuls les éléments avec le statut "En cours" sont affichés
Then les éléments avec d'autres statuts ne sont pas visibles
Then la sélection du filtre persiste si je rafraîchis la page

Ce sont vos cas de test. Quand tous les critères d'acceptation passent, la story est terminée.

Un accord d'équipe sur ce que "terminé" signifie. Comprend généralement : code écrit, code revu, tests écrits, tests passants, déployé en staging, documentation mise à jour.

La contribution du QA à la DoD est généralement : tests automatisés écrits et passants en CI, tests exploratoires manuels terminés, aucun bug critique/haute priorité ouvert.

Le cycle de sprint

Un sprint est une période de temps fixe, généralement deux semaines, pendant laquelle l'équipe construit un ensemble de fonctionnalités. Le cycle se répète.

Sprint Planning (début de sprint)

L'équipe sélectionne des éléments du product backlog pour le sprint. Les éléments sont décomposés en tâches, estimés et assignés.

• Poser des questions de clarification sur les critères d'acceptation
• Identifier les scénarios de test manquants auxquels le PO n'a pas pensé
• Signaler les éléments qui n'ont pas assez de détails pour être testés (les renvoyer pour affinage)
• Estimer l'effort de test. Si une story prend 3 jours à développer, combien de temps faudra-t-il pour la tester ?

Daily Standup (tous les jours, environ 15 minutes)

Trois questions par personne :

1. Qu'est-ce que j'ai fait hier ?

2. Qu'est-ce que je fais aujourd'hui ?

3. Est-ce que j'ai des blocages ?

Court, concentré, pas de résolution de problèmes. Si quelque chose nécessite une discussion plus approfondie, elle se passe après le standup avec les personnes concernées.

Sprint Review (fin de sprint)

L'équipe présente le travail terminé aux parties prenantes : le PO, les managers, parfois les clients. Seul le travail qui respecte la Definition of Done est présenté.

Sprint Retrospective (fin de sprint)

L'équipe réfléchit au processus, pas au produit. Qu'est-ce qui s'est bien passé ? Qu'est-ce qui ne s'est pas bien passé ? Qu'est-ce qu'on change au prochain sprint ?

Trois catégories : Garder ce qui fonctionne bien, Arrêter ce qui ne fonctionne pas, et Commencer ce qu'on devrait essayer.

C'est là que le QA soulève souvent des problèmes de processus. Les tests tournent trop lentement en CI. Les développeurs cassent l'environnement de test sans prévenir. Les stories arrivent dans le sprint sans critères d'acceptation.

Entre le Planning et la Review : le sprint lui-même

Un flux QA typique pendant un sprint :

Tester en parallèle avec le développement, pas après, est la différence fondamentale avec le Waterfall.

Cycle de vie d'un bug dans Scrum

Quand vous trouvez un bug :

1. Logguez-le avec des étapes de reproduction claires, le comportement attendu vs. réel, la sévérité

2. Liez-le à la story dans laquelle il a été trouvé

3. Discutez avec le développeur. Est-ce un bug ou une mauvaise compréhension des exigences ?

4. Priorisez avec le PO. Les bugs critiques bloquent le sprint ; les bugs mineurs peuvent aller dans le backlog

• Critique : bloque les fonctionnalités principales, perte de données, problème de sécurité. À corriger maintenant.
• Haute : fonctionnalité majeure cassée, sans contournement. À corriger ce sprint.
• Moyenne : fonctionnalité partiellement cassée ou contournement possible. À corriger au prochain sprint.
• Faible : problème cosmétique, inconvénient mineur. Va dans le backlog.

Termes clés que vous entendrez dans une équipe Scrum

| Terme | Signification |

|-------|--------------|

| Backlog refinement | Réunion régulière pour réviser et détailler les prochains éléments du backlog |

| Velocity | Combien de story points une équipe termine par sprint en moyenne |

| Story points | Une mesure relative de l'effort (pas des heures). 1, 2, 3, 5, 8, 13. |

| Epic | Une grande fonctionnalité décomposée en plusieurs stories |

| Spike | Une tâche d'investigation limitée dans le temps (recherche, preuve de concept) |

| Dette technique | Travail différé pour maintenir la velocity, qui doit être remboursé à terme |

| Blocage | Quelque chose qui empêche l'avancement, nécessite une attention immédiate |

| Limite WIP | Nombre maximum de choses en cours à la fois (évite le changement de contexte) |

Kanban : quand vous le verrez à la place de Scrum

Certaines équipes utilisent Kanban plutôt que Scrum. La différence : pas de sprints. Le travail circule en continu. Un tableau avec des colonnes (À faire, En cours, En test, Terminé) suit l'état.

Rôle QA dans Kanban : prendre les stories dans "En cours" quand les développeurs les marquent prêtes, déplacer en "En test", puis en "Terminé" quand elles passent. Pas de cérémonies, pas de cycles fixes. Plus adapté au travail de maintenance et aux correctifs de bugs qu'au développement de fonctionnalités.

Ce que les recruteurs demandent vraiment

Parlez des cérémonies auxquelles vous avez participé, quel était votre rôle dans chacune, et donnez un exemple concret. "Je faisais partie d'une équipe en sprints de 2 semaines. J'assistais aux daily standups, testais les stories au fur et à mesure qu'elles sortaient du développement, et participais aux rétrospectives. Dans un sprint, j'ai soulevé le problème que les stories arrivaient sans critères d'acceptation et on a introduit une étape d'affinage qui l'a résolu."

"Je commence à écrire les cas de test lors du Sprint Planning, avant le démarrage du développement. Quand une story est marquée prête pour les tests, je ne pars pas de zéro. Je teste aussi les stories individuellement au fur et à mesure qu'elles sont terminées, pas en lot à la fin."

"Un bug est un comportement qui diverge des critères d'acceptation documentés. Une exigence manquante est un comportement non couvert par aucun critère d'acceptation. L'application fonctionne comme spécifié, mais la spécification était incomplète. Les exigences manquantes retournent au PO ; les bugs retournent au développeur."