Organiser une campagne de tests applicatifs

Par expérience, nous le savons tous : le zéro-bug n’existe pas dans le champ lexical des applications informatiques.

Cependant, injecter un peu de méthode et de rigueur dans la partie testing tout au long de la vie du projet permet de minimiser les risques de dérive du planning original (et des coûts) dus à une phase de recette interminable, et d’augmenter la satisfaction des utilisateurs, et donc leur adhésion au nouvel outil.

Tout d’abord, il est essentiel de considérer cette partie comme un projet dans le projet : ce sous-projet, qui démarrera en même temps que la phase d’analyse et se terminera avant la mise en production, nécessitera la rédaction de livrables, une estimation et un suivi des charges, une livraison et un partage des résultats, un planning.

 

Mais qu’y a-t-il derrière la nébuleuse de la stratégie de tests? Suivant l’importance et l’ampleur de l’impact du projet, on peut y associer plusieurs des volets suivants :

  • les tests techniques
    • tests unitaires
    • tests environnement
    • tests de performance
    • tests de sécurité
  • les tests fonctionnels

Les tests unitaires sont généralement réalisés par l’équipe de développement. En effet, chaque développeur est garant de la qualité de son code (respect des règles de nommage, de programmation, orthographe des labels, non régression). Ils sont absolument indispensables pour la poursuite du projet dans de bonnes conditions : ils représentent un facilitateur pour les corrections suite à la recette fonctionnelle, ainsi que dans le cas d’une reprise de l’application en TMA (Tierce Maintenance Applicative).

Les tests sur l’environnement permettent de valider le comportement de l’application dans son environnement définitif, il est important que celui de test soit identique à celui de production (version de l’OS, du navigateur, des logiciels identiques). Ces tests permettent également de valider la fluidité des interactions avec les serveurs de messagerie, les bases de données, les annuaires d’entreprise…

Couplés à ces derniers, il est également possible d’effectuer les tests de performances de l’application (voir le logiciel LoadRunner). D’une part en simulant des montées en charge et en mesurant les temps de réponses (nombre de connexions, augmentation significative du volume de données), d’autre part en mesurant le temps d’affichage des principaux écrans.

Les tests de sécurité sont plus spécifiques, et requièrent souvent un protocole de tests déjà établi par l’entreprise.

Bien qu’il soit nécessaire de réajuster les scénarii de ces tests pour rester au plus proche du contexte client, la charge de rédaction est moindre. En revanche, il est important d’appliquer les abaques notoirement utilisés sur la charge de développement pour définir celle des tests techniques (généralement 20%). Afin d’inciter l’équipe à réaliser sérieusement ces tests, il est possible de demander les résultats sous forme d’un livrable.

La partie qui demande le plus d’investissement est l’incontournable recette fonctionnelle.

En effet, elle va demander une réelle organisation et doit être planifiée dès le démarrage du projet. Cette phase doit être bornée ; elle a nécessairement un début et une fin. Le meilleur moyen pour éviter toute dérive est de définir ce qui mettra fin à cette période : la durée? le délai? Le seuil d’acceptation du nombre de bugs? Le périmètre?

Questions qui amènent tout naturellement le sujet du cahier de recette : si celui-ci est rédigé de manière claire, intuitive, et dans la mesure du possible exhaustive, il sera simple de se référer à ce document pour valider la conformité de l’application par rapport à l’attendu. De même, il devient aisé d’associer une charge à chaque cas de tests, et ainsi de définir la charge globale prévisionnelle pour dérouler le document. Le cahier de recette est le miroir des spécifications fonctionnelles, élément clé de tout projet informatique. On comprend dès lors le cheminement suivant :

Attention cependant à permettre plusieurs niveaux de lecture du cahier de recette : en effet, après plusieurs livraisons suite à des corrections, il devient illusoire de penser que celui-ci sera déroulé dans son intégralité. Dès lors, il est important de mettre en exergue les scénarii qui portent sur les fonctionnalités indispensables, et qui permettent également de tester la non-régression.

Il peut parfois être aussi intéressant d’automatiser certains de ces tests. Le paramétrage peut être long et laborieux, mais si le scénario doit être répété de nombreuses fois, l’utilisateur est très vite gagnant en terme de temps. De nombreux logiciels existent déjà, de type Selenium pour Firefox ou HP Functional Testing Agent pour Chrome.

Et en pratique? Le cahier de recette est prêt. Il faut maintenant fournir tous les éléments qui permettront aux utilisateurs identifiés de le dérouler efficacement : un serveur dédié à la recette (ce qui laisse à l’équipe de réalisation la latitude de poursuivre les développements sereinement sur l’environnement had hoc), des comptes de tests créés dans une base annuaire elle aussi dédiée, avec les comptes de messagerie associés (un par rôle applicatif), une base de données qui contiendra les données de référence (données métier, souvent paramétrables, définies par le client).

Comme tout projet, il convient d’assurer un suivi précis et de l’avancement et des résultats des tests, et de mettre en place une communication efficace. Des applications comme Mantis Hub ou Visual Studio Team Foundation Server sont prévues pour saisir et gérer les anomalies ou les demandes d’évolution avec une granularité de qualification très fine, ce qui facilite la compréhension et l’arbitrage si nécessaire. De plus, elles sont collaboratives, toutes les parties peuvent intervenir à distance et chaque action est tracée. Les exports permettent de personnaliser le reporting des données des résultats.

——————————————

Si vous ne devez lire que ça, voici en résumé les bonnes pratiques à adopter pour définir une stratégie de tests réaliste et efficace :

  • estimer les charges de tests et planifier la recette dès le démarrage du projet,
  • définir les intervenants et s’assurer de leur disponibilité le moment venu,
  • rédiger le cahier de recette en parallèle des spécifications fonctionnelles (“miroir”),
  • préparer la recette (PC, comptes de tests, messagerie, données de référence…),
  • borner clairement la phase de recette (un début et une fin),
  • assurer un suivi précis de l’avancement.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.