Établir une stratégie de test Agile
Tester, vous avez dit tester ?
Tentez l’expérience : allez voir une équipe, qu’elle fonctionne en suivant des principes agiles ou non, et posez-lui cette simple question : « C’est quoi un test ? ». Il y a fort à parier que vous obteniez des réponses très variées, peut-être même autant de réponses que de personnes. Certains vous parlerons de tests unitaires très orientés technique, d’autres auront en tête la recette utilisateur, ou encore des notions d’automatisation, et suivant à qui vous vous adressez on vous parlera peut-être même de tests de sécurité ou de montée en charge. Or, toutes ces réponses sont correctes. Tester recouvre effectivement toutes ces réalités et bien plus encore. L’idée générale reste de vérifier que le comportement constaté est bien conforme à celui attendu, tant d’un point de vue technique que d’un point de vue fonctionnel.
Une autre idée importante à garder en tête est de se dire que, plus on réduit le délai entre la réalisation d’un item et son test, moins cher coûtera la modification de l’item en question, que cette modification soit liée à un bug ou à une mauvaise compréhension du besoin.
En effet, il est beaucoup plus aisé (et donc beaucoup plus économique) de reprendre du code rapidement après sa création, et les modifications à apporter sur des items déjà en production sont, quant à elles, extrêmement coûteuses si l’on prend en compte, par exemple, les coûts d’interruption de service ou en terme d’image de marque.
Le test Agile
Il faut donc tester et tester tôt. D’ailleurs, si l’on se réfère au framework Scrum, le framework Agile le plus largement répandu, le résultat d’un sprint (c’est-à-dire l’incrément logiciel) est potentiellement livrable. Elle doit être possible si d’un point de vue métier cela a du sens de l’envoyer directement en production. Notre incrément doit donc avoir été testé et validé pendant le sprint de sa création.
Cette injonction de Scrum est très intéressante et permet d’apporter rapidement de la valeur à nos utilisateurs, mais il n’est pas toujours possible de la respecter à la lettre. La disponibilité des acteurs, la dépendance avec d’autres équipes, l’intégration d’éléments logiciels, la disponibilité des environnements… autant de raisons qui peuvent nous empêcher d’avoir un incrément logiciel réellement déployable en production. Il faut évidemment essayer de mettre en place toutes les conditions nécessaires pour se rapprocher autant que possible de cet objectif de mise en production en fin de sprint, mais, le temps que ces conditions soient remplies, il faut bien s’organiser pour tester nos réalisations. Et quoi qu’il en soit, il reste vrai qu’il faut tester le plus tôt possible.
L’atelier de stratégie de test
Il est donc important de se poser la question, au début de notre projet, ou lors de la mise en place de notre organisation Agile, de la stratégie de test qui sera appliquée, c’est-à-dire basiquement de répondre à la question : qui teste quoi, et quand ?
Pour ce faire, je vous propose d’organiser un atelier de définition de la stratégie de test. Les différents acteurs du projet participeront, et l’objectif sera de remplir le tableau suivant, en se servant entre autres des règles et des possibilités offertes par nos organisations, ou des compétences, envies et expériences des acteurs du projet :
Type de test : test unitaire technique, test fonctionnel, test de bout en bout, test de performance… listez dans cette colonne l’ensemble des tests de manière chronologique. Ainsi, pour un item donné, on aura de haut en bas l’ensemble des types de tests qu’il aura à passer.
Cible du test : sur quel type d’item ce test va-t-il porter ? User story, classe, use case… quelle est la nature, la granularité de l’item testé ?
Acteur : la personne qui va, manuellement, effectuer le test, c’est-à-dire vérifier que le comportement obtenu est bien conforme au comportement attendu.
Déclencheur : quel est l’événement qui déclenche le test ? La fin du développement d’un item, la fin du sprint, la livraison sur un environnement donné… ? Cette colonne va nous permettre de répondre au « quand ».
Environnement : dans quel environnement ou sur quelle machine le test doit-il s’effectuer ?
Entrants : jeux de données, cas de tests, critères d’acceptation… quels sont les éléments indispensables à la réalisation du test ?
Automatisé O/N : est-ce que ce test a vocation à être automatisé ? L’automatisation de test est un enjeu majeur quand on parle de qualité. Elle permet de garantir la robustesse de notre code et est une option quasi obligatoire dans un contexte Agile. En effet, l’approche itérative nous permet de livrer fréquemment, ce qui implique, tout aussi fréquemment, de procéder à des tests de non régression. L’automatisation nous permet d’éviter l’inflation de ces tests en en contrôlant les coûts.
Acteur : qui automatise le test. Souvent, la même personne qui a effectué le test manuellement.
Outil : quel outil allez-vous utiliser pour automatiser ce test ?
Et ensuite ?
Maintenant que cet atelier est fait, comment s’assurer que notre stratégie est effectivement suivie et qu’elle ne reste pas qu’une note d’intention ? Un certain nombre d’éléments peuvent nous aider à l’application concrète de nos décisions.
Tout d’abord, nous pouvons mettre à jour nos différentes Definition of Ready et Definition of Done qui nous permettent d’énoncer les conditions nécessaires pour dire qu’un travail peut être commencé ou l’ensemble des choses réellement faites quand on dit qu’un travail est fini. Ainsi vont s’ajouter à la Definition of Ready les différents entrants (par exemple : je ne commence pas un travail tant que je n’ai pas les jeux de données de test nécessaires), et à la Definition of Done (par exemple : quand j’indique que le travail sur une User Story est terminé, cela signifie que j’ai automatisé les tests sur les critères d’acceptation).
Ensuite, le management visuel va nous aider à éviter que notre stratégie de test ne reste qu’un ensemble de documents aussi vite oubliés qu’ils ont été écrits. Déjà, le résultat de notre atelier de stratégie de test ainsi que nos différentes Définition of Ready et Definition of Done doivent être affichés au mur avec le reste de notre management visuel. Il est ainsi facile de s’y référer à tout instant, par exemple pendant les Daily Scrum Meetings où l’équipe pourra prendre l’habitude de vérifier que ce qui est fait est bien conforme avec ce qui était prévu.
D’autre part, on va pouvoir étendre notre tableau de suivi pour mettre l’emphase sur certaines pratiques de tests. Ainsi, en lieu et place de nos colonnes “A faire”, “En cours”, “Terminé” on va pouvoir détailler notre colonne “En cours” en y ajoutant les différents tests qui doivent être réalisés durant le sprint, comme dans l’exemple ci-après :
Une stratégie évolutive
« L’adaptation au changement plus que le suivi d’un plan », ça vous rappelle quelque chose ?
La quatrième valeur du manifeste agile doit bien évidemment s’appliquer à notre cas, et la stratégie de test qui est ici notre plan doit être régulièrement mise à l’épreuve. En effet, ce que l’on a pensé en tout début de projet était peut-être séduisant sur le papier, mais si ça se trouve, irréaliste pour tout un tas de raisons techniques ou organisationnelles. D’un autre côté, on n’a peut-être pas pensé à tout depuis le début, ou bien on peut découvrir de nouvelles pratiques ou de nouveaux outils en cours de route.
Pour que notre stratégie de test reste effective, il faut donc régulièrement la challenger, par exemple pendant nos rétrospectives, pour nous assurer que la stratégie et les pratiques sont toujours alignées. Ainsi nous pourrons continuer à tester nos produits de manière efficiente, ce qui reste la clé majeure de la construction de produits fiables et de qualité.
© Néosoft
Toute reproduction interdite sans autorisation de l’auteur.