Changer sa vision des tests dans les projets agiles
Dans un monde en plein bouleversement digital, demandant une réactivité accrue des applications aux nouveaux business modèles, de plus en plus d’entreprises adoptent aujourd’hui des modèles de développement Agile. En effet l’Agilité est reconnue pour accorder une importance particulière à la flexibilité et à la réactivité. Il est cependant parfois complexe de mettre en place une bonne stratégie de test adaptée à ce type de méthodologie. Cette phase est pourtant essentielle à la qualité globale du projet. Le testing Agile ne doit pas être considéré comme une phase séparée du projet mais doit faire partie intégrante du cycle de développement. Tout comme le développement agile, le testing doit se faire de manière incrémentale et intégré de façon continue.
Définir une stratégie de test
Elément essentiel au démarrage du projet, la stratégie de test doit définir, de manière globale, comment les tests vont être menés pour atteindre les objectifs définis. Elle permet de planifier les tests en une succession d’étapes, avec des objectifs clairs, et de définir les méthodes et les moyens pour y parvenir.
Elle doit être définie au début du projet, dès la phase d’initialisation en s’appuyant sur les récits utilisateurs de haut niveau (fournis par le business). De ces récits utilisateurs sont déduites les exigences fonctionnelles qui guideront l’écriture des cas de test tout au long du projet.
A chaque itération du projet, la stratégie de test est revue et ajustée en fonction du contenu de l’itération précédente (ce qui est terminé) et de celle à venir (ce qu’il reste à faire). De cette manière la stratégie est affinée tout au long du projet, pour la rendre plus précise, tout en gardant une certaine souplesse propre à l’agilité.
Quelle place dans l’équipe pour le testeur
De par sa position centrale, le testeur doit être proche du Product Owner (voir jouer lui-même ce rôle) et de l’équipe de développement. Ainsi à chaque nouvelle itération, il dispose des informations qui lui permettent de définir de manière pertinente le type de cas de test et la manière de le réaliser (en s’appuyant notamment sur les quadrants de test définis par Brian Marick).
Les itérations sont souvent courtes et nombreuses. Pour assurer qualité et fiabilité à travers les différentes itérations et gagner un temps précieux, une partie des tests doit être automatisée. On distingue deux grandes familles de tests automatisés, les tests de recette (liés à l’interface) et les tests unitaires (liés à la technique).
Pour les tests de recette, un outil permettant d’enregistrer une suite d’actions exécutables à volonté est privilégié. Ainsi à la fin de chaque itération, les tests des itérations précédentes peuvent être de nouveau exécutés pour s’assurer qu’aucune régression fonctionnelle n’est présente.
Pour les tests unitaires, une plateforme d’intégration continue est choisie pour garantir une meilleure conception de l’application. Les tests unitaires sont exécutés plusieurs fois par jour pour assurer la qualité, la conformité des nouveaux développements et la non-régression des fonctions du code.
Bien qu’il puisse paraitre fastidieux, Il est important de ne pas voir le testing comme une lourdeur administrative. En l’insérant dans le cycle de vie de chaque itération du projet, il est synonyme d’un résultat de qualité.
Une approche adoptée par les équipes Fujitsu
Supportée par une équipe d’experts en Agile Testing, Fujitsu se présente comme un acteur répondant aux besoins toujours plus exigeants des projets digitaux des entreprises en pleine transformation.
Grâce à l’utilisation de plateformes d’intégration continue, d’automatisation des tests métiers et du savoir-faire méthodologique de ses équipes, Fujitsu dispose du savoir-faire pour délivrer des solutions de haute qualité proposant une approche de testing adaptée à la réalité et au besoin d’agilité.
Les experts de Fujitsu sont également à disposition des clients pour les aider à mettre en place des stratégies de tests et des outils adaptés à la réalité des projets agiles.