La QA dans une organisation Agile

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 l’hyper digitalisation et de la forte utilisation de 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.
‍

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 la notion “Agile”. S’il existe de nombreuses définitions, nous pouvons 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 : l’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.
• 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 le traditionnel Cycle en V ne permet pas. 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é des partie prenantes du projet et à la maitrise des coûts. En effet, plus tôt un ajustement est identifié dans la chaine de production, moins il sera coûteux en termes de temps, de budget et d'image.

Le rôle de la QA (Quality Assurance) est donc triple :

• Remonter les risques fonctionnels le plus tôt possible et de façon continue.
• Définir des tests pertinents pour assurer et valider la qualité du produit.
• Apporter une valeur ajoutée grâce à ses feedbacks en tant que "premier utilisateur".
  ‍

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 le produit en tant que premier utilisateur. Toutefois, nous n’avons pas répondu à la question essentielle : comment l’intégrer au sein des processus Agiles ?

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 à 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, 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 rapide 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 la 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 tardifs et d’améliorer ainsi la qualité du code.  

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.
• Facilité de la mise en place de l’automatisation au sein du projet.
• Facilité de la maitrise des délais de livraison  

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 des étapes :

• 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 facilite la clarté et l’intégration des tests manuels et automatisés.  
• 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.
• 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é.

Pour conclure, l’Agilité ne peut fonctionner que si la qualité reste l’affaire de tous !
Il est primordial de consacrer du temps à la QA mais aussi de l’intégrer le plus en amont possible tes et donc impliquer tes équipes QA dans le processus de développement. L'objectif ne consiste plus seulement à trouver des bugs et des défauts, mais à les prévenir dès le début du cycle afin d’optimiser le testing, contrôler tes coûts et livrer un produit de qualité qui réponds au mieux au besoin de tes utilisateurs.

Pour cela, nous proposons d'associer la mise en place des deux méthodes :

• Le Shift Left Testing
• Le Behavior Driven Development (BDD)

‍

Ce qu'il faut retenir d'intégrer la QA dans une organisation Agile :

• Il est important d'intégrer l'équipe QA dès le début des réflexions : conception, build, validation
• Le QA a la responsabilité de remonter les risques fonctionnels le plus tôt possible et de façon continue.
• Il définit des tests pertinents pour assurer et valider la qualité du produit.
• Il apporte une valeur ajoutée grâce à ses feedbacks en tant que "premier utilisateur".