L’évolution du métier de testeur au travers de la nouvelle certification ISTQB/CFTL Testeur Technique Agile

Fin 2019, l’Assemblée Générale de l’ISTQB a voté un nouveau syllabus : Testeur Technique Agile, qui est disponible en français sur le site du CFTL, et sera prochainement proposé par les organismes de formation. Il s’agit d’une certification de niveau avancé comme montré sur le schéma suivant.

Schéma des certifications ISTQB/CFTL disponibles en français à avril 2020

Ce syllabus est une contribution forte et à jour pour la qualification et la formation des professionnels des tests logiciels en 2020. Un fait remarquable, que nous détaillons dans ce blog, est la façon dont ce syllabus montre les évolutions fondamentales que le métier de testeur connait aujourd’hui. Nous pouvons les résumer à trois niveaux :

  • Le testeur au cœur de la définition/validation du besoin en Agile.
  • Le testeur porteur de la réduction de la dette technique des tests manuels et automatisés.
  •  Le testeur acteur des processus DevOps et donc des tests en continu.

Le testeur au cœur de la définition/validation du besoin en Agile

L’ingénierie des exigences en Agile est un sujet de forte actualité : après avoir fortement diminué la documentation des exigences lors du passage à l’agilité, les organisations s’aperçoivent du besoin de forme de référentiel pour maîtriser le contenu de leur applications et systèmes.

Les Epics et les User Stories constituent une information volatile : lorsqu’une User Story est réalisée dans une itération, acceptée à l’issue des tests, cette expression du besoin n’a plus qu’une valeur historique, mais cela n’en fait aucunement un référentiel d’exigences.

Le syllabus Testeur Technique Agile décrit parfaitement les bonnes pratiques actuelles :

  • les scénarios de test d’acceptation renforcent les critères d’acceptation
  • ces scénarios de test sont développés lors d’ateliers associant Analystes Métier / Product Owner, Testeurs et Développeurs (les ateliers Tres Amigos)
  • les testeurs de par leur expérience sur le système portent cette scénarisation, et sont ceux qui vont implémenter ces scénarios de tests d’acceptation

Ces bonnes pratiques sont formalisées au travers des techniques de développement et de test en Agile :

  • TDD – test-driven development (développement piloté par les tests), pour le niveau des tests unitaires automatisés
  • BDD – behavior-driven development (développement piloté par le comportement) à partir du langage Gherkin – Étant donné / Quand / Alors – d’expression des tests, et de leur automatisation
  • ATDD – acceptance test-driven development (développement piloté par les tests d’acceptation) fondé sur la scénarisation des tests d’acceptation qui définissent des exemples de cas d’usages du système. Le syllabus introduit le concept de « spécification par l’exemple »

Le point clé de ces pratiques, en particulier ATDD et BDD est qu’elles mettent en œuvre une collaboration en continu au sein de l’équipe Agile. Un autre aspect très important est la documentation vivante que constitue ces scénarios de test d’acceptation : vivante car l’exécution de ces tests garantit qu’ils soient en permanence à jour avec le système implémenté !

Ces nouvelles pratiques, qui se diffusent rapidement depuis quelques années, repositionnent le testeur : il n’est plus en bout de chaîne mais un acteur central de toutes les étapes allant de l’expression du besoin à la mise en production.

Le testeur porteur de la réduction de la dette technique des tests manuels et automatisés

Le concept de dette technique est mis en avant dans le syllabus Testeur Technique agile :

  • Au niveau du code : au travers de l’impact du refactoring du code sur la maintenance des tests
  • Au niveau des tests : l’enjeu de la réduction de la dette technique des tests pour en améliorer la maintenabilité

Intéressons-nous à la dette technique des tests qui est l’aspect le plus nouveau et qui marque une prise de conscience de l’importance du problème. La dette technique des tests concerne à la fois les tests automatisés et les tests manuels.

Dette technique des tests automatisés

Pour les tests automatisés, les problèmes induits par la dette technique constituent le pain quotidien des automaticiens de tests : accumulation et redondance partielle des mots-clés, flaky tests[1], tests pas à jour, problème d’obsolescence, de variabilité donnant des exécutions inopérantes, faux positifs, …. La liste est longue. La résolution des problèmes de dette technique des tests automatisés va dépendre de la source du problème. Par exemple :

  • Pour les mots-clés : l’action principale est le refactoring : mutualiser le code d’implémentation des mots-clés, et introduire des paramètres.
  • Pour les flaky tests : le travail est souvent une reprise du l’architecture d’automatisation, des conditions d’exécution et de l’usage des mock (les bouchons et simulateurs utilisés)
  • Pour l’obsolescence et les faux positifs : il s’agira d’un travail de maintenance, souvent assez laborieux, mais nécessaire pour conserver la pertinence des tests automatisés.

Pour les tests automatisés, les choix d’architecture d’automatisation constitue un point clé pour maîtriser la dette technique des tests.

Dette technique des tests manuels

L’obsolescence des patrimoines de tests manuels est un problème récurrent et difficile car très consommateur de temps pour les équipes de test. Lors des évolutions et des mises en production, le référentiel des tests est étendu avec de nouveaux cas de tests et certains cas de tests existants sont corrigés.  Au fil du temps, une partie du patrimoine de tests devient obsolète, car le travail de maintenance systématique de ces tests manuels est très couteux et que l’ensemble des tests manuels ne sont pas exécutés sur chaque release. De plus, la maintenance du patrimoine de tests est souvent réalisée par incréments, par des personnes différentes, ce qui va graduellement créer une hétérogénéité des cas gérés : certaines étapes de tests similaires sont décrites différemment, la granularité des tests et des étapes de test peut être très hétérogène, ainsi que les formats de rédaction. Ces problèmes, lorsqu’ils s’accumulent, sont difficiles à résorber. On voit maintenant apparaître des outils à base d’IA qui facilitent la reprise et l’optimisation des tests manuels.

Le testeur acteur des processus DevOps et donc des tests en continu

Nous ne sommes pas tous concernés par le DevOps – c’est-à-dire l’intégration continue et le déploiement continu – mais l’accélération des rythmes de mise en production est une tendance qui se développe dans de nombreuses organisations.

Le syllabus Testeur Technique Agile intègre un chapitre complet sur le rôle des tests en continu dans la livraison et le déploiement continus, mais aussi sur l’impact des pratiques d’intégration continue sur les activités de test.

Un des points clés est le rôle du test dans la définition du terminé (Definition of Done dans le vocabulaire agile), et donc le rôle central des tests pour sécuriser les processus DevOps. Ces tendances de la production et livraison du logiciel sur un rythme accéléré renforce le rôle central des tests dans le processus.

Mais c’est aussi une transformation des pratiques qui fait évoluer le rôle de testeur : à partir du moment où plus de parties prenantes (analystes métier, product owner, beta testeur, développeurs, …) sont impliqués dans les tests, que devient le rôle de testeur et de test manager ? Une des réponses se trouve dans l’émergence du rôle de test coach ou de coach QA, c’est-à-dire du partage du savoir-faire des tests auprès de l’équipe et de l’animation des activités partagées de test.

Conclusion

En conclusion, je voudrais souligner la grande qualité du syllabus Testeur Technique Agile de niveau avancé, et sa pertinence vis-à-vis de l’évolution des pratiques. L’ISTQB est ainsi bien dans son rôle de produire et maintenir des certifications de compétences qui soient actuelles, utiles et en phase avec les besoins de la profession.

Alors, vous la passez quand cette nouvelle certification ?


[1] Un « flaky test » est un test automatisé dont le résultat va être sensible aux conditions d’exécution (par exemple la charge du réseau) conduisant à des résultats incertains : le test échoue de temps en temps sans qu’il s’agisse d’une anomalie.

Publié par

Votre commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l’aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google

Vous commentez à l’aide de votre compte Google. Déconnexion /  Changer )

Image Twitter

Vous commentez à l’aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l’aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s