Développer son processus de tests en investissant sur l’automatisation : le test au plus près du code et de l’expérience fonctionnelle

QualNet, les tests automatisés, manuels, fonctionnels et techniques : une histoire qui ne date pas d’hier.

QualNet est éditeur de logiciels depuis 25 ans maintenant. Nos produits ont évolué, leur usage a grandi et notre stratégie de test avec !

Dans cet article, nous retraçons les grandes étapes qui nous ont permis de professionnaliser et perfectionner notre stratégie de test.

Depuis sa fondation en 1997, QualNet a vu son processus de test s’étoffer et se complexifier.
Il est ainsi passé par plusieurs phases, cherchant à améliorer son efficacité tout en suivant les évolutions de méthodes et solutions.

 

Etape 1 : Réalisation de tests par les développeurs

Cette première étape a duré de la création de QualNet jusqu’en 2014. Les tests se basaient alors sur l’expérience des développeurs et sur le retour d’expérience des chefs de projet a posteriori. Concrètement, nous n’avions pas de ressources spécialement dédiées à la réalisation des tests. Les tests étaient intégrés dans le processus de développement.

Etape 2 : Professionnalisation des tests

La seconde étape (2014-2019) représente l’établissement d’un processus de tests à part entière lors de la mise en place de la méthodologie SCRUM. Nous avons professionnalisé la fonction de testeurs, en dédiant des ressources à cette mission et en outillant notre chaine de production logicielle.

Les tests développeurs, qui perdurent, sont désormais accompagnés de tests fonctionnels réalisés par les collaborateurs du processus « Concevoir ». Ils interviennent à la fois pendant la validation des développements (tests manuels – TM) et en fin de sprint, juste avant la sortie du package (tests exploratoires – TEX). L’essentiel des échanges entre testeurs et développeurs se fait à l’oral, et l’avancée d’un développement est suivie via notre outil de suivi de bugs.

Les premiers tests automatisés (Tests automatiques – TA) sont créés. Ces TA vérifient plusieurs fois par jour la stabilité des applications Intraqual en exécutant plusieurs milliers de scénarios fonctionnels en quelques heures. Ces scénarios sont écrits en langage GHERKIN par les testeurs fonctionnels, implémentés et maintenus avec un outillage “maison” par les développeurs.

• Les tests fonctionnels sont répartis entre les développeurs (tests développeurs) et les testeurs fonctionnels (TM et TEX).
• Les tests automatiques (TA) sont implémentés et vérifient plusieurs fois par jour la non-régression de nos outils.

Etape 3 : La maturité de notre processus de tests

Les TM bénéficient d’une traçabilité formelle complète au travers des plans de tests détaillés. Les échanges entre testeurs et développeurs sont tracés (observations, questions et décisions) dans notre outil de suivi de bugs.

Les TEX ont été revus et dépassent le SCRUM. Toutes les parties prenantes internes, parfois externes, sont sollicitées afin de recueillir leurs impressions à la sortie de projets importants.

Le périmètre couvert par nos TA a augmenté. Ils atteignent cependant une volumétrie critique et ont aujourd’hui vocation à être revus et optimisés (voire repris sous une autre technologie).

La modernisation de notre code et de nos pratiques de codage a permis l’ajout des Tests Unitaires (TU). Ces tests, centrés sur le comportement du code en lui-même, viennent compléter les TA qui eux manipulent l’interface utilisateur.

 

Etats des lieux d’un patrimoine de tests automatisés

QualNet est aujourd’hui doté d’un patrimoine de tests automatisés, variés et joués quotidiennement, présentant plusieurs avantages :

1. Les tests automatisés (TA et TU) permettent de gagner un temps conséquent lors des contrôles de non-régressions et sont garants de la stabilité de nos outils.
2. Ce patrimoine continue d’évoluer et de s’étoffer. Avec les nouvelles pratiques et technologies, de nouveaux types de tests viennent compléter ceux en place, tandis que ceux déjà utilisés sont enrichis progressivement.
3. Les équipes gagnent en expérience permettant ainsi d’optimiser et affiner la manière dont ils sont utilisés.

 

Cependant, plusieurs axes d’améliorations se dégagent :

1. Le code varie selon les pans fonctionnels et une partie du code supporte peu les tests automatisés.
2. Les TA et l’outillage associé ont atteint une taille critique et impliquent une maintenance coûteuse.
3. La quantité de TM est encore importante malgré les avancées en automatisation.

 

Tendance actuelle : des tests davantage automatisés

Plus d’automatisation, plus de tests, plus vite, moins chers, bien répartis… Les tendances actuelles visent à fournir une couverture de tests aussi complète que possible (sans parler d’exhaustivité), ainsi qu’une efficience de mise en place et de maintenance.

Le monde du test a vu l’émergence depuis plusieurs années de méthodes et d’outils permettant de tester un logiciel sous toutes ses coutures, depuis les tests de code purs (TU), jusqu’aux tests d’ergonomie (tests UI/UX). Certains de ces outils permettent même à des personnes sans compétence de développement d’écrire et implémenter des tests automatisés.

L’avenir des tests pour QualNet

L’histoire des tests pour QualNet ne s’arrête pas là et de nouvelles pages restent à écrire.

Notre but est à la fois d’améliorer la qualité des solutions (en limitant les régressions logicielles) et d’optimiser les coûts de cette qualité. Pour cela, une veille logicielle régulière est entreprise, via la participation à des événements tels que les Journées Françaises du Test Logiciel (JFTL), la lecture d’articles dédiés à ce sujet, ou encore des benchmarks d’outils et solutions.

Cette veille nous amène des pistes de réflexion, comme l’automatisation de notre chaîne de tests, ou la revue de notre outil de suivi de bugs. Quels choix seront faits ? Ce sera l’objet d’un futur article !

 

Glossaire des tests :

TM : Le Test Manuel est réalisé manuellement par des testeurs expérimentés qui utilisent et testent le produit de la même manière que les utilisateurs finaux, à partir d’un plan de tests défini en amont.

TA : le Test Automatique correspond à un scénario fixe joué par un automate

TEX : Le Test Exploratoire est un test manuel sans le support d’un plan de tests.

TU : Le Test Unitaire est un test isolant des parties du code et en vérifiant le bon fonctionnement. Les différentes fonctionnalités sont ainsi découpées et testées indépendamment les unes des autres, morceau par morceau.

GHERKIN : Gherkin est un langage que l’on utilise pour définir des tests. Les scénarios sont écrits suivant une structure « Etant donné [contexte], quand [action], alors [résultat] »