Comment faire une stratégie de tests pour un progiciel?

Une stratégie de tests est une étape déterminante de chaque conception de solution ERP. Cette approche favorise une meilleure gestion des risques : tester un progiciel avant son implantation permet de l'améliorer et de l'optimiser avant que les anomalies n'atteignent la production. Les enjeux sont considérables.

« En 2022, la mauvaise qualité logicielle a coûté au moins 2 410 milliards de dollars américains à l'économie des États-Unis. » Source : Consortium for Information and Software Quality (CISQ), rapport 2022

Pourquoi faire une stratégie de tests pour un progiciel?

Une stratégie de tests pour un progiciel réduit les risques d'implantation en concentrant l'effort de tests sur les portions les plus complexes de la solution, celles dont les défectuosités entraîneraient les plus grands impacts. Pour un grand projet, on retrouve généralement 15 catégories de tests. Ces catégories se regroupent en deux grandes classes : les tests de solution, qui valident les processus d'affaires et la paramétrisation, et les tests de certification technique, qui confirment la fiabilité de l'infrastructure, la performance et la sécurité.

Chaque projet est différent : chaque stratégie de tests le sera aussi. On la développe après avoir analysé l'ensemble des problématiques potentielles de la solution, puis on module la profondeur des tests selon la complexité et l'impact de chaque portion.

Tout au long de l'exécution de la stratégie, les experts en processus d'affaires et les experts en progiciels travaillent conjointement à la préparation des scénarios de tests et à leur exécution. Cette mise en commun des connaissances est essentielle : elle permet d'arriver à une paramétrisation optimale du progiciel.

Comment structurer l'exécution des tests d'un progiciel?

L'exécution des tests repose sur trois piliers : des outils spécialisés en gestion de tests, des environnements informatiques contrôlés et un soutien technique dédié. Les outils de gestion de tests permettent de contrôler les activités de chaque catégorie, d'en mesurer l'avancement, de gérer les scénarios et les résultats, de suivre la résolution des anomalies et de préparer la reddition de comptes.

Les tests sont exécutés par l'équipe de projet dans des environnements informatiques contrôlés. L’article historique PlanAxion décrit, pour les grands projets, un modèle de huit environnements en plus de l'environnement de production.

Il faut aussi prévoir un niveau de soutien technique adéquat pendant toute la durée des tests. Une équipe d'experts en infrastructure, en systèmes d'exploitation, en bases de données et en progiciels se consacre au projet : elle procède aux installations, assure l'administration et la performance des environnements, applique les rustines nécessaires, gère les copies de sûreté et rafraîchit les environnements au besoin.

Comment gérer les scénarios de tests?

Les scénarios de tests sont un actif durable : ils se réutilisent lors des projets subséquents de mise à niveau ou d'ajout de fonctionnalités, alimentent la documentation des processus d'affaires et servent de base au matériel de formation des usagers. Il est donc essentiel de les préserver et de les tenir à jour.

Il est possible d'accélérer la préparation des scénarios en ayant recours à une banque de scénarios prédéfinis. Certains éditeurs de progiciels et certaines firmes de services-conseils possèdent, dans leur capital intellectuel, des jeux de scénarios de tests qu'ils mettent à la disposition de leurs clients.

Quant à l'automatisation des tests, l'investissement n'est pas toujours opportun. La décision dépend de trois facteurs :

• la quantité de cycles de tests de régression potentiels;
• le nombre de mises en service annuelles;
• la nature des tests visés.

Qui doit contrôler les configurations et les variables de tests?

Un groupe central, indépendant des équipes de tests, doit gérer les changements à la configuration et à la paramétrisation du progiciel. Ce contrôle garantit que les modifications sont faites de façon contrôlée et répliquées de manière uniforme et concertée dans tous les environnements. Il permet aussi de documenter les différences entre les environnements de tests et de minimiser les situations où l'on n'arrive pas à expliquer pourquoi un progiciel se comporte différemment d'un environnement à l'autre.

La stratégie de tests a d'ailleurs pour objectif de contrôler toutes les variables introduites durant les différentes catégories de tests, afin d'isoler, de diagnostiquer et de résoudre les anomalies plus facilement. Les cinq variables à contrôler sont :

• L'infrastructure : garantir des environnements stables, performants et correctement administrés.
• Les progiciels : suivre les versions et les rustines appliquées dans chaque environnement.
• La paramétrisation : répliquer les configurations de façon uniforme et concertée par un groupe central.
• Les données : travailler avec des jeux de données représentatifs et des environnements rafraîchis.
• Les interfaces : vérifier les échanges avec les autres systèmes sans variable parasite.

Que retenir pour réussir votre stratégie de tests?

Une stratégie de tests réussie combine des catégories de tests adaptées au projet, des environnements contrôlés, des scénarios réutilisables et un contrôle central des configurations. En concentrant l'effort là où la complexité et les impacts sont les plus grands, et en faisant collaborer les experts d'affaires et les experts en progiciels, l'organisation améliore et optimise sa solution avant la mise en service, plutôt que d'en subir les anomalies en production.

Quels tests prioriser pour une PME québécoise?

La priorité dépend de la conséquence d’une panne, pas du nombre d’écrans à vérifier. La grille suivante propose des exemples à adapter aux processus et aux règles de votre organisation. Les résultats attendus doivent être validés avant l’exécution.

Comment rédiger un scénario d’acceptation utilisable?

Exemple fictif pour un distributeur québécois. Une commande contient deux articles, mais un seul est disponible. Le scénario précise le rôle du testeur, l’état du stock, la livraison partielle attendue, la facture et le solde restant à livrer. Ajoutez un retour et une reprise d’échange pour vérifier les exceptions. Conservez les identifiants de transactions comme preuves.

Chaque fiche contient : exigence liée, préconditions, jeu de données, étapes, résultat attendu, résultat observé, anomalie, responsable et preuve d’acceptation. Un statut « exécuté » ne signifie pas « réussi ». Les anomalies corrigées doivent être retestées.

Quels critères autorisent la mise en production?

Définissez les seuils avec le comité de pilotage avant les essais. Exemple de critères à contractualiser : tous les scénarios critiques ont réussi; aucune anomalie bloquante n’est ouverte; les données sont rapprochées; les droits sont validés; la répétition de bascule et le plan de continuité sont acceptés. Chaque exception porte un responsable et une échéance.

Ces critères s’appuient sur une logique de risque, pas sur un taux global de réussite. Un résultat de 95 % serait insuffisant si les scénarios manquants bloquent la facturation ou la production. Le nombre est ici illustratif, pas une norme.

Microsoft recommande de définir la portée, les cycles, les critères d’entrée et de sortie et l’approbation métier. Les tableaux et scénarios ci-dessus sont des propositions éditoriales à adapter, pas une certification Microsoft.

Questions fréquentes

Qu'est-ce qu'une stratégie de tests pour un progiciel?

Une stratégie de tests est une approche structurée qui planifie l'ensemble des tests à réaliser avant l'implantation d'un progiciel. Elle favorise une meilleure gestion des risques, cible les portions les plus complexes de la solution et permet d'améliorer et d'optimiser le progiciel avant sa mise en service.

Combien de catégories de tests compte un grand projet de progiciel?

Pour un grand projet, on retrouve généralement 15 catégories de tests. Elles se regroupent en deux grandes classes. Les tests de solution valident les processus d'affaires et la paramétrisation. Les tests de certification technique confirment la fiabilité de l'infrastructure, la performance et la sécurité de l'environnement.

Combien d'environnements faut-il pour tester un progiciel?

Pour un grand projet, huit environnements peuvent constituer un repère d’organisation. Ce nombre doit être adapté au produit, au contrat et aux usages simultanés de la PME. Des environnements contrôlés et rafraîchis régulièrement permettent d'exécuter chaque catégorie de tests dans des conditions stables, d'isoler les anomalies et d'expliquer les différences de comportement du progiciel d'un environnement à l'autre.

Faut-il automatiser les tests d'un progiciel?

Pas toujours. L'investissement dans l'automatisation des tests dépend de la quantité de cycles de tests de régression potentiels, du nombre de mises en service annuelles et de la nature des tests visés. Un projet qui prévoit peu de cycles de régression justifie rarement l'effort initial d'automatisation.

Faut-il toujours huit environnements pour tester un ERP?

Non. Le repère de huit environnements décrit une organisation possible pour de grands projets, pas une obligation pour chaque PME. Le nombre dépend des usages simultanés, de l’isolation nécessaire, des contraintes du produit et du contrat. Documentez les conflits entre configuration, migration, formation et acceptation avant de décider.