Les bonnes pratiques de l’organisation QA Agile

Contexte et enjeux

Au sein d’un projet Agile, la QA (Quality Assurance) a souvent une place assez floue. D’ailleurs, si l’on s’intéresse aux références Agiles comme les méthodes Scrum ou Kanban, elle est souvent peu présente, voire inexistante.

A l’heure de hyper digitalisation, de l’explosion de l’utilisation des produits numériques, la qualité du produit est un pilier de l’expérience utilisateur.

En effet, comment répondre à ce besoin de création de valeur sans s’assurer que le produit est bien fonctionnel et utilisable par ces utilisateurs ? L’intégration de la QA au sein des organisations Agiles prend alors tout son sens en permettant notamment de valider des critères essentiels de la Definition of Done (DoD) du projet.

Pour répondre aux mieux à ce besoin, il est donc nécessaire de répondre aux questions suivantes :

Quel est le rôle de la QA dans un contexte Agile ?

Pour déterminer le rôle de la QA au sein d’un contexte Agile, il est nécessaire de définir cette notion. S’il existe de nombreuses définitions, on peut globalement définir l’Agilité avec les points clés suivants :

  • La responsabilité des équipes: on décentralise la prise de décision au sein des squads ou feature teams afin de fluidifier et accélérer la prise de décision au sein des équipes expertes sur le sujet.

 

  • Le découpage: un des objectifs de l’Agilité est de livrer au plus vite de la valeur à l’utilisateur pour le satisfaire en continu. Pour cela, il est nécessaire de découper ces apports de valeur en petites tâches pour livrer régulièrement et rapidement. Ces cycles correspondent le plus souvent à des Sprints.
Agile development
  • Mesurer la valeur apportée: l’intérêt de l’Agilité est de s’adapter aux changements de son environnement ce qui implique un droit à l’erreur que ne permet pas le traditionnel Cycle en V. Mais pour savoir si l’on est dans la bonne direction ou s’il est nécessaire de recadrer, nous devons être en capacité de pouvoir mesurer la valeur apportée au plus tôt, et si possible, dès la phase de conception.

Cette dernière valeur de l’Agilité donne toute sa place à la QA dans une organisation Agile puisque dans tout projet, on peut tous facilement s’accorder sur ce constat : le QA est le premier utilisateur du produit. Son feedback est donc essentiel à la réactivité et la maitrise des coûts. En effet, plus un ajustement sera identifié tôt dans la chaine de production, moins il sera coûteux en terme de temps, de budget et d’image.

Le rôle de la QA est donc triple :

Comment intégrer la QA au sein d'une organisation Agile ?

Nous avons donc vu l’intérêt d’intégrer la QA au sein d’une organisation Agile puisqu’il permet d’assurer la qualité du produit et d’obtenir un premier feedback sur la valeur ajoutée. Toutefois, nous n’avons pas répondu à la question essentielle : comment l’intégrer au sein des processus Agiles ?

En effet, la QA est souvent en bout de chaîne et subit tous les retards engendrés lors des autres process mis en place sur le projet. Cette situation aboutit généralement à une QA en retard ou surchargées, incapable de tester dans les temps le périmètre défini en amont. De ce fait, la QA doit à nouveau s’adapter et prioriser les tests à exécuter pour valider les nouvelles fonctionnalités/use cases :

  • Soit au détriment des tests de non régression ou exploratoires et donc de la qualité fonctionnelle délivrée à l’utilisateur. Nous rentrons, dans ce cas, dans le fameux triptyque Coût/Délai/Qualité au risque de générer une vision produit négative auprès des utilisateurs.
  • Soit en réduisant le périmètre couvert par les tests en livrant moins de valeur, moins souvent générant ainsi des feedbacks utilisateurs plus tardifs par rapport aux développements et qui ne pourront pas être pris en compte par le PO pour alimenter le backlog du produit. On perd alors les avantages de l’Agilité tout en rajoutant les contraintes du Cycle en V, à savoir l’absence de retour utilisateur pour générer rapidement de la valeur.

L’intégration de la QA en bout de chaîne ne semble donc pas l’organisation la plus optimale dans un contexte Agile.

Pour résoudre cette équation, revenons au principe même de l’Agilité et de la vision produit : livrer régulièrement de la valeur à un produit via le feedback de ses utilisateurs. Et comme nous l’avons vu précédemment, le premier utilisateur du produit, c’est le QA !

Pour rapprocher l’utilisateur au plus près du backlog, il faut donc intégrer la QA le plus en amont possible et ne plus le laisser en fin de phase. On parle alors de Shift Left Testing.

Le principe du Shift Left Testing, c’est de tester plus tôt, plus souvent afin de réduire le nombre de bugs et d’améliorer ainsi la qualité du code.

Shift Left Testing

Pour mettre cela en pratique, nous allons donc incorporer la QA dès la phase de conception en la combinant avec une approche Behaviour-Driven Development (BDD). Les avantages de cette organisation sont multiples :

  • Utilisation d’un langage technique commun compréhensible par tous les acteurs du projet (Gherkin)
  • Répartition de la phase de test sur l’ensemble du cycle de développement
  • Optimisation de la détection des risques
  • Détection des bugs plus tôt dans le cycle de développement
  • Réduction des coûts de résolution des bugs
  • Amélioration de la qualité du produit en réduisant le nombre de patchs correctifs
  • Facilite la mise en place de l’automatisation au sein du projet
  • Facilite la maitrise des délais de livraison
Behavior Driven Development (BDD)

En effet, on constate que la grande majorité des bugs sont introduits lors de la phase de codage. Si l’on attend la fin du cycle de développement pour tester, il devient de plus en plus complexe et coûteux de corriger proprement tous les bugs en même temps.

Pour mettre en place cette organisation, il est toutefois nécessaire de respecter les étapes suivantes :

1. Déterminer le langage de communication : l’objectif est de sélectionner un langage universel et pratique à tous les intervenants du projet. Pour cela, l’utilisation du langage Gherkin dans les US et les critères d’acceptation facilitent la clarté et l’intégration des tests automatisés.

2. Intégrer les phases de test au plus tôt : l’approche Behaviour Driven Development (BDD) permet de répartir la charge de test, mais aussi de tester dès le début du cycle/sprint.

3. Intégrer des tests automatisés au plus tôt : l’approche Behaviour Driven Development (BDD) implique de retester très fréquemment chaque implémentation de code. On a donc une forte reproductivité de la tâche nécessaire à la vérification de la stabilisation du code. L’automatisation permet de réduire la pression sur les équipes QA et d’obtenir un retour d’informations plus rapide sur la stabilité du code. L’automatisation des tests accélère le cycle de développement et permet de réduire le délai de mise sur le marché.

Dans un contexte Agile, il est donc primordiale d’intégrer le plus en amont possible les équipes QA.

Pour cela, nous proposons de d’associer la mise en place des deux méthodes ci-dessous :

Comment optimiser la valeur ajoutée du QA au sein d’une organisation Agile ?

La réussite d’un projet est souvent liée à la bonne répartition des ressources au bon endroit. Pour cela, il est important d’optimiser le rôle de chacun en fonction de son expertise tout au long de la vie du produit.

Si l’on découpe sommairement un cycle Agile, celui-ci contient généralement 3 phases :

  • Une phase de conception
  • Une phase de build
  • Une phase de validation

Habituellement, on cantonne donc le rôle de la QA à la phase de validation par ses tests ce qui le met en fin de chaine et l’empêche ainsi d’apporter son expertise plus en amont. Toutefois, cette remarque ne doit pas s’appliquer uniquement au QA. En effet, cette décentralisation des tâches doit s’appliquer à l’ensemble des acteurs du projet qui est composée généralement d’un Product Owner (PO), de développeurs et d’un ou plusieurs QA.

Ainsi les différentes phases ne doivent plus être la chasse gardée d’un seul intervenant comme on peut le croiser sur de nombreux projets où la conception étaient principalement assurée par le PO, la phase de Build par les développeurs et la phase de validation par le QA.

Nous allons donc analyser chacune de ces phases à son expression la plus unitaire, à savoir la user story (US). Ainsi, nous pourrons souligner l’apport de valeur ajoutée des différents intervenants dans les étapes précédemment explicitées. 

L'optimisation des rôles au sein d'un projet Agile entre PO, Développeur et QA

A. La phase de conception

Comme nous le voyons sur le schéma ci-dessus, la phase de conception peut se décomposer en 3 étapes clés :

  • Le management du risque: Pour cette étape, la cérémonie des 3 Amigos est la solution idéale à mettre en place. En plus de prévenir collectivement des risques produit/business (PO), techniques (développeur) et fonctionnels (QA) où chaque interlocuteur a son expertise spécifique, elle va permettre de faciliter toutes les étapes suivantes. Il ne faut donc pas voir cette cérémonie comme une réunion de plus ou une perte de temps, mais au contraire comme un gain de temps pour l’ensemble des autres étapes.
Optimisation phase de Conception entre PO, Développeur et QA
  • La définition des critères d’acceptation (UAT): La rédaction des critères d’acceptation va en découler ou être fait directement lors de la cérémonie des 3 Amigos. En effet, suite à l’évaluation des risques et contraintes de chacun, l’US décrite par le PO sera plus claire pour tous les intervenants et la définition des tests qui pourront valider la valeur ajoutée pour le client (apport du PO suite au cadrage fait avec ce dernier) et la valeur ajoutée pour l’utilisateur (apport du QA suite à sa vision de premier utilisateur du produit) seront implicites.
Lire la vidéo
  • La création des jeux de données: pour réaliser les tests, il est nécessaire d’anticiper la création des jeux de données afin de faciliter leur exécution ou de détecter en amont l’impossibilité « technique » de tester un critère d’acceptation si le jeu de données ne peut être anticipé ou créé. Le QA reste l’expert le plus adapté à cette étape.

B. La phase de build

Pour la phase du Build, il faut bien distinguer le design des tests de l’exécution de ces derniers. En effet, l’objectif va être d’automatiser les tâches simples qui ne demandent pas de réflexion afin de gagner du temps et d’augmenter la couverture de test.

L’apport du QA se porte alors principalement sur le design du test. En effet, le QA apporte son savoir-faire sur la rédaction des cas de test, mais surtout sur la manière d’obtenir les résultats attendus efficacement en prenant compte les contraintes de jeux de données, d’apport de la valeur ajoutée pour l’utilisateur et d’exécutions. Il sera l’acteur le plus apte à les rédiger en incorporant les jeux de données nécessaires et les éléments nécessaires à la vérification des critères d’acceptation associés à ces tests.

Optimisation phase de Build entre PO, Développeur et QA

Dans le cas de l’utilisation de l’approche Behaviour Driven Development (BDD), le QA pourra guider les développeurs dans ses développements sans que ceux-ci ne soient biaisés par les tests. En effet, ce n’est pas le développeur qui va développer, puis automatiser son test, mais le développeur qui va développer son code pour répondre au design du test rédigé par le QA.

Dans ce type d’organisation, l’utilisation du langage Gherkin permettra d’améliorer la communication et l’efficacité entre le développeur et le testeur. Ce langage aura d’ailleurs été mis en place dès la phase de conception lors de la cérémonie des 3 Amigos dans la description de l’US par le PO et la rédaction des critères d’acceptation par le QA.

Ainsi, durant la phase de Build, on aura les étapes suivantes :

  1. QA : Rédaction du test (nouvelle valeur ajoutée pour l’utilisateur)
  2. QA : Exécution du test pour vérifier qu’il échoue (1ère exécution manuelle)
  3. Dév : Ecriture du code suffisant pour que le test passe
  4. QA : Vérifier que le test passe
  5. Dév : Optimiser le code et automatiser le test (si possible)
Effort de test QA / Développeur

C. La phase de validation

Lorsque tous les tests de la phase de Build auront été passés avec succès et automatisés dans la mesure du possible, nous pourrons passer à la phase de validation.

Toutefois, la seule validation des critères d’acceptation des US n’est pas suffisante pour valider la Definition of Done (DoD) QA. Il faut vérifier que les ajouts de code n’ont pas généré de régression sur les autres US déjà développées et validées lors des précédentes phases de développement.

Pour faire ces vérifications, il est nécessaire de faire des tests de non régression (TNR) sur ces anciennes US. Comme il est impossible de tout tester, il est nécessaire de réaliser une sélection des tests à exécuter sur ce périmètre. Cette étape de sélection et de priorisation est donc une partie essentielle de l’expertise du QA. Il sera le plus compétent pour sélectionner les tests à exécuter et pour valider le périmètre de non régression.

Il pourra faire une proposition en fonction de son expérience qui sera :

  • Complété par l’expertise du développeur sur les périmètres de code qui pourraient être impactés par le nouveau code
  • Validé par le PO qui reste le garant de la Definition of Done globale du projet

Les TNR ayant été automatisés à la fin de la phase de Build où ils ont été créés, ils pourront être exécutés par les développeurs qui seront plus efficaces sur cette tâche que les QA.

Ces derniers se concentreront sur les tests n’ayant pas pu être automatisés, autrement dit, les tests de bout-en-bout permettant de valider les parcours utilisateurs complet sur le produit.

Optimisation phase de Validation entre PO, Développeur et QA

Ces TNR validés, le PO pourra checker la validation des différents critères d’acceptation et de la Définition of Done du sprint.

En Agile, le QA apporte donc son expertise tout au long de la vie du produit :

Cet apport du QA est donc bien présent dans un contexte Agile tout au long de la vie du produit, mais celui-ci sera réellement efficace si tous les intervenants du projet :

  • Sont consultés à chaque étape
  • Sont en accord avec les actions prises

L’agilité ne peut fonctionner que si la qualité reste l’affaire de tous !

PSSST 👀

Cet article vous a plu ❤️ ? N’hésitez pas à le partager pour que d’autres puissent en profiter ! Rejoignez-nous aussi sur Linkedin pour ne rien manquer et suivre notre veille sur les contenus Product & Quality !

Partager sur linkedin
Partager sur twitter
Partager sur email