Quels prérequis pour mettre en place une campagne de tests, en mode Agile ?

Pour mener à bien une campagne de tests pleinement efficace en mode Agile, de nombreux paramètres sont à prendre en compte. Comment préparer une campagne de tests ? Quels tests mener ? Comment les exécuter : en manuel ou automatisé ? Quelles équipes impliquer ? Les paragraphes suivants sont là pour vous aider à répondre à toutes ces interrogations.

Une campagne de tests est un investissement sur l’avenir, une assurance visant à sécuriser et pérenniser le support digital à développer. En mode Agile, cette vérité garde tout son sens, mais réclame de faire preuve de méthodologie afin d’en retirer un maximum d’efficacité.

Réunir une équipe pluridisciplinaire

Avant toute chose, il convient de regrouper différents intervenants :

• Le client : éditeur du site internet et / ou de l’application mobile et ses équipes métier (marketing, DSI, fonctions supports concernées).
• Les développeurs.
• Les testeurs : équipe interne de l’éditeur ou tiers de confiance (de préférence certifiés ISTQB®).
• Les automaticiens (pour préparer l’automatisation de certains tests à inclure dans la campagne).

Réunir ces différents participants, tant en phase de pré-codage (pour assurer la bonne interprétation des besoins fonctionnels) qu’en phase de post-codage (pour assurer le suivi jusqu’à la fin des développements et lors de la mise en production) est une nécessité.

En effet, pour garantir une campagne de tests efficace, les participants doivent se mettre d’accord sur :

• La façon de coder le support (Utilisation ou non du modèle MVC ?
• Un planning intégrant les cas de tests à mener (et le résultat attendu) à la fin de chaque sprint, pour élaborer dans son intégralité le plan de tests.
• Les jeux de données à exploiter,
• Les outils à adopter pour suivre les anomalies détectées (bug tracker), comme ceux permettant d’exécuter les tests automatisés…

Définir les cas de tests et le plan de tests

Le cœur des réunions préparatoires avec ces différents participants est bien évidemment de lister, pour chaque sprint, les tests à exécuter de façon manuelle ou automatique : tests unitaires, tests fonctionnels type bout en bout, tests de non-régression (TNR, qu’il convient d’automatiser), … ainsi que les jeux de données à utiliser (sous la forme linéaire en format xml, csv, json, excel… ou dynamique, en lien avec une base de données).

Faire matcher le planning de développement (sprint) avec le planning du plan de tests

Ce travail préalable permet de faire coïncider, à la fin de chaque sprint, les tests à mener, tout en prévoyant que les jeux de données (JDD) soient disponibles et que les outils logiciels nécessaires à l’exécution des tests automatisés soient paramétrés (écriture de scripts propres et réutilisables). Grâce à cet effort d’organisation, procédures, outils, environnement de tests et hommes seront disponibles et prêts pour mener les différentes campagnes de tests tout au long du développement, et pourrons ainsi tenir les délais…

Coordonner les processus de remontées et de corrections des anomalies

Qui dit tests, dit gestion des anomalies : les process de remontées et de corrections des anomalies doivent être établis en amont de toute campagne de tests. Il en va de la bonne gestion des corrections. Quel niveau de criticité doit impérativement déclencher des corrections ? Qui doit arbitrer ? Comment doivent être transmises les anomalies rencontrées ? …

Tirer le bilan avant d’entrer en production

Cette pratique permet de tirer, en fin de développement, le bilan des opérations menées, avant de donner le feu vert pour une mise en production du support digital. Avant d’en arriver à ce stade, il sera nécessaire de mener des tests utilisateurs (UX) et ergonomiques afin de s’assurer que dans des conditions réelles, le site internet et/ou l’application mobile remplit parfaitement ses missions, conformément au cahier des charges initial. De même ce sera l’occasion d’identifier l’ensemble des tests automatisés qui pourront être réutilisés, en production, suite à des évolutions du support ou des terminaux permettant d’y accéder (évolutions des OS, navigateurs, …).