Le constat de départ

L’équipe est devenue agile depuis 2 mois, les sprints font 2 semaines chacun, les spécifications fonctionnelles ont disparu, les meetings de lancement de sprint, les mêlées quotidiennes et les réunions de fin de sprint permettent à l’équipe d’échanger et de s’améliorer au fil du temps. Problème, la qualité s’est dégradée et les retours utilisateurs et les cas de support se multiplient.

En effet, au cours d’un sprint de 2 semaines, les développeurs commencent par développer. Les BA/Testeurs profitent donc de ce temps pour travailler avec le Product Owner sur les use-cases des prochaines évolutions prévues dans le backlog. La transition agile a fait disparaître les spécifications habituelles du cycle en V. On donne maintenant aux devs une liste de use cases (scénarios Gherkin) qui ont une nomenclature imposée.

Les BA/Testeurs reçoivent généralement une première version testable au début de la deuxième semaine. Cela laisse très peu de temps pour faire des aller-retours si des anomalies sont relevées au cours de la campagne.

Les testeurs ont leur cahier de test prêt avant de recevoir le premier livrable car ils ont travaillé les nouvelles fonctionnalités de ce sprint en amont. Pendant le sprint, les nouvelles fonctionnalités sont testées en priorité afin de faire des retours aux développeurs. Une fois les nouveautés sécurisées, le BA/Testeurs peuvent maintenant faire une campagne de non régression mais… IL NE RESTE QUE 12H AVANT LA LIVRAISON !

Impossible d’assurer un haut niveau de qualité avec aussi peu de temps. Ce constat fréquent pose la question de comment faire de la non-régression dans le temps d’un sprint. La réponse est simple en théorie et difficile à mettre en œuvre puisque les campagnes de non-régressions ne font pas partie des sprints.

En fait, les méthodes agiles imposent, pour les tests, un changement d’état d’esprit en profondeur et des adaptations qui devraient être débutées longtemps avant la transition agile. Pour en arriver là, il faut que l’équipe modifie sa façon de travailler en profondeur et nous allons voir quelles sont les étapes de cette transformation.

Diminuer au maximum la charge de tests pour les BA/testeurs

Puisque les BA/testeurs n’ont pas assez de temps pour réaliser la campagne habituelle, il faut mettre les développeurs à contribution, en leur demandant de diminuer le plus possible la charge de tests du livrable. Pour y parvenir, ils doivent changer leurs habitudes de code de façon à inclure un maximum de tests unitaires. Souvent la transition agile leur impose de passer en mode TDD (Test Driven Developpement) qui préconise de concevoir en premier les Tests Unitaires et d’écrire ensuite le minimum de code pour que tous les tests soient verts.

Voici un graphique qui montre bien le total changement d’état d’esprit :

Les BA/Testeurs n’aurons déjà plus qu’à se focaliser sur les tests fonctionnels et d’intégrations. Tests de chaîne, Tests aux limites, Tests de charge, Tests de l’interface. Ainsi les nouvelles fonctionnalités bénéficieront d’une très bonne couverture de test (Test Unitaires + Tests Manuels).

Combiner scénario Gherkin, Spec et cas de test

La cible d’une équipe agile en termes de tests est le « Zéro non-reg ». Cela ne signifie pas qu’il ne faut pas faire de tests de non-régression mais que la non régression devrait être totalement automatisée. Autrement dit, l’équipe devrait se consacrer uniquement aux tests des nouvelles fonctionnalités et à leur automatisation pour les prochaines campagnes. Ce point n’est souvent pas bien mis en avant par les coachs agiles alors que rattraper le passif constitue l’un des enjeux cruciaux de la mise en application.

L’objectif est qu’à la fin de chaque sprint, les scénarios Gherkin qui ont servi de spécifications à l’équipe soient ajoutés à l’ensemble des tests qui sont joués lorsque l’on décide de lancer une campagne de non-régression. Ainsi la base de test sera toujours à jour en incluant les dernières fonctionnalités développées.

Mais qu’est-ce qu’un scénario Gherkin ? Un scénario rédigé avec la méthodologie Gherkin est la description d’un comportement applicatif en 3 courtes phrases.

GIVEN : Qui décrit l'état initial de l'application
WHEN : Qui décrit un événement ou un moment précis
THEN : Qui précise la réaction du SI à l'événement décrit dans le WHEN

En utilisant cette méthode, il est possible de spécifier quasiment toutes les évolutions. Parfois, il faut un grand nombre de scénarios mais chacun reste assez simple et peut être traité par un unique développeur.

Pour bien comprendre, prenons l’exemple d’une évolution pour ajouter du Tiering dans un pricer (Prix différents en fonction de familles de client). Pour une telle évolution, il y aurait évidemment un grand nombre de use cases (création de l’interface de paramétrage, possibilité d’assigner un client à une famille de clients, vérification que le trader a le droit de modifier les prix de cette paire de devises, identifier la famille d’un client, etc.). Etant donné que le but ici est de présenter des concepts et pas de rédiger une spec, nous nous focaliseront sur le cœur de l’évolution, envoyer le bon prix au bon client. Voici un scénario Gherkin possible :

Tiering : Send the right price to the right client
GIVEN : Automatic contribution is ON for on
WHEN : The trader receives a request for quote from a client
THEN : Automatic price for client on is sent to the client
Examples :
| Maturity | Currency | ClientCategory |
| 1 Month | EUR/USD | GOLD |
| 6 Months | USD/AUD | PREDATOR |
| 2 Years | GBP/CAD | PLATINUIM |

Dans cet exemple les objets entre crochets sont des paramètres. Après le scénario, il est possible de donner une liste des différentes valeurs possibles pour multiplier les use cases sans réécrire 25 fois le même cas avec une variante. La maintenance du référentiel en est grandement facilitée.

Ici, le test sera joué 3 fois mais il n’y a pas de limite au nombre de combinaisons, mises à part les problématiques de temps de traitement.

Avec cet ensemble de use cases, le développeur sait ce qu’il a à faire. Les scénarios Gherkin servent de base de discussion entre les membres de l’équipe et remplacent les spécifications fonctionnelles. L’avantage de cette méthode de spécifications est que ce use case peut être automatisé facilement. Le cas de test sera ensuite ajouté à la base des tests de non-régression qui sera jouée lors des sprints à venir.

SpecFlow, Cucumber et les autres : une solution

Dans l’exemple ci-dessus, après avoir finalisé l’évolution, l’équipe de développeurs va coder la mise en place du pré requis « Automatic contribution is ON » en mettant l’application dans l’état souhaité. Pour cela des outils comme Cucumber ou SpecFlow sont particulièrement adaptés.

Cucumber est un outil open-source initialement écrit en Ruby mais qui supporte maintenant tous les langages majeurs grâce à de nombreuses implémentations. SpecFlow est ainsi l’implémentation .Net accessible en C#. Le principe de Cucumber est de prendre en input des scénarios Gherkin et de les exécuter en utilisant MSTest, NUnit, xUnit et MbUnit.

En codant l’ensemble des phrases qui composent les use cases, l’équipe dispose à la fin d’un cas de test automatisé que l’on peut nourrir avec des listes de variations possibles des paramètres pour obtenir le niveau de couverture souhaité.

Ce bout de code sera conservé et il permettra de développer beaucoup plus rapidement tous les uses cases des futures évolutions qui commencent par « Automatic contribution is ON ». Si notre exemple a été développé, on imagine facilement à quel point il sera aisé de coder le use case suivant pour une autre évolution (Cancel RFQ).

Cancel RFQ
GIVEN : Automatic contribution is ON on
WHEN : The trader receives a request for quote from a client
THEN : Trader can cancel RFQ by clicking on the "CANCEL" button
Examples :
|Currency|
|EUR/USD|
|GBP/JPY|

Les phrases en gras n’auront en effet pas à être recodées. L’équipe n’aura qu’à reprendre le cas de test précédent et l’adapter. Il faudra toutefois coder la dernière phrase, qui sera ajoutée aux phrases déjà en stock.

Normalement, plus on automatise de phrases, plus la création de nouveau cas de test est automatique.

Une mise en application parfois difficile

Tout ça c’est bien beau mais ça impose un gros effort à l’équipe pour être mis en place. La première chose c’est sans doute de prévoir le temps pour cette automatisation après le développement des nouvelles fonctionnalités. En règle générale, les équipes de développeurs ont pour objectif d’être prêt à livrer à la fin du sprint : il faut, avec l’aide du coach agile, trouver comment intégrer la prise en compte de l’automatisation dans le déroulé global.

Un autre problème lors de la mise en place d’un tel fonctionnement est de trouver le temps et le budget pour rattraper l’existant. Une application qui a 5 ans peut facilement avoir une base plus de 4000 tests de non-régression. En plus des sprints, il faut donc que l’équipe arrive petit à petit à diminuer les fonctionnalités non couvertes par les tests auto. En attendant de disposer d’un tel outil, l’équipe a plusieurs solutions :

• Externaliser la non-régression pour qu’elle soit faite en même temps que le sprint (SG à Bangalore, Natixis à Porto)
• Faire une semaine sans sprint à une périodicité fixe pour consacrer l’ensemble de l’équipe aux tests de non-reg. Tout le monde s’arrête et teste !
• Diminuer la couverture des tests. C’est malheureusement souvent la solution retenue.

Conclusion

En synthèse, ce qu’il faut retenir c’est qu’une équipe agile doit (dans l’idéal) mettre en place des méthodologies de code (Tests Unitaires + TDD) afin de diminuer la charge des tests au cours des sprints. Elle doit ensuite industrialiser l’automatisation des cas de tests des nouvelles fonctionnalités pour que le scope testé soit toujours plus grand. Une fois la non-régression totalement automatisée, il sera possible de la faire tourner toutes les nuits comme les GAFA.

En définitive mettre en place une méthodologie agile est une cible séduisante mais coûteuse, à la fois dans la mise en place et dans la maintenance. Nous aurions ainsi pu parler des prochains problèmes à régler pour notre équipe, et ceux là sont de taille : le rattrapage de l’existant et la maintenance du référentiel de test.

Deux points extrêmement chronophages et importants pour l’équipe et qui feront peut-être l’objet d’un prochain article. Stay tuned !