Aujourd’hui, je m’entretiens avec Marc, ingénieur qualité sur un projet d’application web de gestion piloté par Scrum.

Ingénieur qualité et Scrum ? S’agit-il d’une chimère ?

Dans les méthodologies classiques, le terme ‘ingénieur qualité’ a un sens bien précis. Les habitués de ces méthodologies ne reconnaitrons d’ailleurs peut-être pas l’ingénieur qualité qu’ils connaissaient. Quant aux utilisateurs de Scrum, ils pourront éventuellement être quelque peu choqués par ce terme.

Qu’en est-il donc ? Pour le savoir, donnons la parole à Marc.

Dans le vif du sujet…

Karim : Bonjour Marc. Tu travailles en tant qu’ingénieur qualité sur des projets en Scrum ?

Marc : En effet, je suis chargé de vérifier que soient respectées les exigences fonctionnelles, et les exigences de performances applicatives.

K. : Je suis plutôt étonné, Marc. J’ai rarement entendu parler d’un tel poste dans des projets Scrum.

K. : Qu’est ce qui a motivé la création de ce poste ?

M. : Plein de choses, Karim… Tout d’abord, c’était la qualité, ou plutôt le manque de qualité, de nos applications web en production. Avant que j’arrive, on dénombrait une dizaine de bugs critiques. D’autre part, l’équipe fonctionnelle avait besoin d’être accompagnée, et aidée sur le pilotage du projet par les tests, conduits sous FitNesse. La croissance en taille de nos équipes nécessitait la présence d’une personne pour garantir le respect des exigences de qualités sur nos projets.

K. : Je résume pour nos lecteurs. Agir de façon préventive, en détectant les anomalies au plus tôt pendant le sprint. Conduire le changement au sein du projet. Être le garant de la performance de l’application.

K. : Concrètement, comment travailles tu sur le terrain ?

M. : Tout d’abord, je pars des besoins fonctionnels. En fait, la responsabilité de chaque site est assurée par responsable produit. Cette personne a pour rôle de définir les éléments fonctionnels susceptibles d’améliorer les ventes de son site. Mon premier travail a été de mieux cerner les besoins des responsables fonctionnels, en les aidant à rédiger des récits utilisateurs sous FitNesse. J’ai aussi développé un automate capable de tester la surface complète d’un site, et de détecter les éléments manquants, comme des images du catalogue produit.

K. : Marc, est-ce que cela a été facile à mettre en place ?

M. : Au début, j’ai été pris un peu avec une certaine légèreté (sourire de Marc). Mais, la vision des responsables produit a changé lorsqu’ils se sont aperçu qu’ils pouvaient valider, en 1 clic, le bon fonctionnement d’un récit utilisateur. Le récit utilisateur devient ainsi un test exécutable. Responsable des besoins fonctionnels, l’équipe produit a rapidement compris les gains de productivité apportés par la rédaction des cas d’utilisation sous cette forme. Auparavant, les tests d’intégration étaient effectués de façon manuelle. L’introduction de FitNesse a permis de les automatiser.

K. : Mais, vous testez quoi exactement avec vos récits utilisateurs ?

M. : Nous testons le domaine et les IHM avec le même récit utilisateur. Pour les IHM, nous utilisons WatiN, un automate de test pour les applications web. WatiN est un projet open source développé en .NET.

K. : Très intéressant ! Tu fais d’une pierre deux coups.

M. : Eh oui, Karim ! En plus, la prise en main de FitNesse se fait de façon naturelle. Mais, je les accompagne sur la rédaction de leurs récits, afin d’assurer une certaine cohérence.

K. : Ton travail s’arrête au niveau des fonctionnels ?

M. : Bien-sûr que non ! Je travaille aussi avec l’équipe de développement. Mais, au début, c’était plutôt difficile.

K. : Pourquoi ?

M. : Les habitudes, l’absence d’une culture des tests a provoqué une résistance au changement énorme. Je pense.

K. : Comment travailles tu avec eux ? À quel niveau interviens tu ?

M. : Tout d’abord, j’écris les fixtures !

K. : Qu’est-ce que c’est ?

M. : C’est le code qui permet d’associer les récits utilisateur avec le code à tester.

K. : Tu fais encore d’autres choses ?

M. : J’adapte à nos besoins les règles de validation de code sous FxCop. J’aide l’équipe à bien écrire les tests unitaires, et surtout à rendre l’implémentation testable. Eh oui, Karim ! La qualité doit être continue !

K. : Tu faisais autre chose avec FitNesse ?

M. : En fait, certains bugs subsistent à chaque itération, ou disparaissent pour mieux réapparaître plus tard. Pour marquer le coup, je les baptise d’un sobriquet un peu ridicule comme Goldorak ou Nono. Je référence l’anomalie sous FitNesse, j’enregistre le scénario sous WatiN, et je le mets à disposition de l’équipe de développement. Elle peut ainsi elle-même vérifier que l’anomalie est bien corrigée. Tant que l’anomalie persiste, inlassablement, je reviens vers les développeurs. La qualité est quelque chose de non négociable.

K. : Comment as-tu mesuré ton action au sein de ce projet ?

M. : C’est simple Karim ! À mon arrivée, 10 anomalies critiques détectées… actuellement, 0 anomalies détectées ! Et une couverture de code qui est passée de 40 à 70 %.

K. : Pas mal ! Finalement, j’ai l’impression que le rôle d’un ingénieur qualité est finalement très différent, selon que l’on soit en Scrum, ou dans une approche classique en cascade.

M. : En cascade, l’ingénieur qualité valide le bon fonctionnement de l’application. Il reste spectateur, ou souvent cantonné à un rôle documentaire. En agile, il est sur le pont ; il agit sur toutes les phases du projet ; il est une des clés de réussite dans l’évolution des équipes.

K. : C’est une grande nouvelle, une petite révolution pour les ingénieurs qualités.

K. : Marc, si tu devais avoir un regret, ce serait lequel ?

M. : Attend ! Je réfléchis. Je n’ai pas pu tester les anciennes applications. Souvent, le mauvais design du code m’en a empêché !

K. : C’est l’âme du testeur qui ressort ! Marc, je te remercie pour cet entretien bistrot.

De l’ingénieur qualité au lead tester…

Nous le voyons, la spécification par les récits utilisateurs redéfinit et valorise le rôle de l’ingénieur qualité, qui devient un membre à part entière de l’équipe, un véritable lead tester. Les récits utilisateurs deviennent des test automatisés, et guident les développements. Ils rapprochent les fonctionnels et les développeurs.