Testez vos progiciels

Aujourd’hui, les mises à jour d’applications dites « packagées » c’est-à-dire basées sur un ERP (ex : les progiciels SAP, Oracle/PeopleSoft, Siebel, etc...) présentent des risques identifiés et importants pour les grandes organisations. Ces organisations investissent sur des projets stratégiques de plusieurs années comportant des phases de recette fonctionnelle pour des applications dont les opérations dites « cœur de métier » dépendent fortement. Quand les applications existantes basées sur un ERP doivent être modifiées, les risques les plus importants sont liés aux écarts fonctionnels qui peuvent apparaître entre les différentes implémentations et la mise en production de cette application.

La compatibilité avec les anciennes règles métiers lors des montées de version, et surtout la continuité opérationnelle, sont essentielles quand des processus métiers clés sont modifiés ou ajoutés. Ce contexte rend difficile et risquée la mise en œuvre du test de non régression. Néanmoins, une gouvernance informatique efficace doit être entreprise et réussie. La certification continue du système d’information face aux besoins métiers qui évoluent sans cesse nécessite la mise en place d’une stratégie de test de non régression systématique.  

 

Les responsables des projets de type ERP font aujourd’hui face à des défis:

• Le scripting et l’enregistrement manuels de tests exécutables sont souvent sous estimés dans les projets ERP. Cette activité peut être une tâche difficile techniquement et coûteuse, ce qui décourage le test de non-régression dés le début du projet. Les meilleures pratiques du développement agile prônent le test le plus tôt possible, mais le coût d’implémentation des tests pour chaque itération peut s’avérer prohibitif ou conduire à des tests de faible qualité.
• Retarder les phases de tests et attendre que l’application ERP soit disponible avant la conception et l’implémentation des tests n’est pas une bonne pratique. Les tests ne pourront pas vérifier que les spécifications fonctionnelles sont couvertes tout au long de la vie projet. Attendre que l’application soit disponible pour les tests augmente considérablement les risques et réduit le nombre de tests réalisables dans le temps projet imparti, ce qui peut conduire à la détection tardive des erreurs.
• L’absence de gestion des changements des spécifications augmente le risque d’obtenir des tests incohérents par rapport au design de l’application ERP. Garder les tests et les applications développées alignées sur les changements est généralement difficile parce que ces éléments du projet sont généralement gérés par des processus différents et dépendent de référentiels indépendants. Les tests de non-régression et les modifications des tests rendent coûteuse la gestion des changements.

Les responsables qualité de projets ERP savent que les risques de régression dus aux changements dans les spécifications et les cas de tests sont élevés. La spécification de la « couche métier » et ses évolutions doit en théorie rester indépendante des choix d’implémentation. Les experts du domaine métier souhaitent faire évoluer leurs règles métiers sans nécessairement connaître les implications techniques.

Généralement, le processus de changement de scripts de test pour s’adapter à des changements de la couche technique (l’interface utilisateurs et ses composants) est une tâche à faible valeur ajoutée. Toutefois, la mise à jour des tests quand les spécifications des règles métiers changent est à la fois indispensable, long et coûteux. Ces différentes mise à jour des tests dégradent la productivité et la réactivité des équipes de validation en introduisant du risque supplémentaire dans le projet. Smartesting optimise et améliore la productivité des phases de tests de non régression et aide à réduire les risques qui y sont liés.  

La solution Smartesting propose une représentation formelle des règles métiers sous la forme d’un modèle de test. La solution Smartesting peut ensuite générer automatiquement la totalité des tests nécessaires, et ce indépendamment de l’implémentation technique de l’application.

• Tout d’abord, la solution Smartesting s’appuie sur la modélisation du comportement attendu de l’application, ce qui n’est pas lié à la couche technique mais uniquement à la couche métier. L’environnement de travail Smartesting offre aux architectes de test la capacité de concevoir leurs tests dès que les spécifications fonctionnelles sont définies. Les tests basés sur un seul et même modèle vont alors être générés pour diverses implémentations, distributions et versions d’une même application, ce qui garantit un test de non régression efficace et en permanence conforme aux spécifications.

• L’étape suivante est la traduction des tests générés automatiquement par la solution Smartesting vers la technologie cible de test concernée. Dès que l’utilisateur le souhaite et après inspection de ce qui a été généré, Smartesting va traduire les tests vers l’environnement de test choisi, selon les besoins du projet. La validation de la couverture des exigences de tests (les spécifications) peut ainsi être obtenue avant même d’avoir à écrire ou exécuter le moindre test.

Smartesting atténue les risques liés aux activités de Test d’applications basées sur un ERP en automatisant la couverture des processus métiers critiques. La génération de test basée sur la modélisation du comportement attendu industrialise pleinement le processus de test, de la conception des spécifications fonctionnelles à la conception des tests, et à l’implémentation de script de test exécutables.

Smartesting s’intègre à la fois avec les outils de modélisation de type BPMN, et avec les outils d’automatisation et de gestion de test. La génération automatique garantie la cohérence permanente des spécifications fonctionnelles et la conception de test, quel que soit l’état d’avancement du projet. Smartesting favorise l’approche itérative et facilite le découpage en lots de tests ayant une complexité fonctionnelle croissante.

Smartesting facilite la gestion des changements en ajoutant continuellement de la valeur quand l’application est mise à jour et une fois que les tests ont été modélisés au moins une fois. La mise à disposition d’un référentiel Smartesting basé sur un ou plusieurs modèles de test diminue de manière significative le coût du test de non régression tout en garantissant tout au long de la vie du projet la conformité aux besoins métiers.