Model Driven Testing
Amélioration de la gestion automatique de test dans les projets logiciels et ménagement des ressources
Compex Systemhaus GmbH développe son concept 2BEE® par le Model Driven Testing (MDT) pour l'implémentation de son progiciel commercial Compex Commerce. Le premier BEE, description du cycle de développement ou de la méthode (Best Enterprise Engineering) assure une implémentation réussie de Compex Commerce. Le deuxième BEE (Business Engineering Environment) correspond à la mise à disposition des outils appropriés au cycle de développement dans le cadre du Business Process Management intégré dans Compex Commerce. Ces outils assurent la mise en œuvre directe des connaissances acquises liées au projet dans la solution. La modélisation de workflows en est un exemple.
Logiciel de processus intégré dans la gestion commerciale
L'adaptation du progiciel aux besoins individuels de l'utilisateur (Customizing, paramétrage ou modification) est une caractéristique du processus clé de l'implémentation du logiciel. Cette phase est marquée par une introduction par étape, du global au détail, correspondant à une adaptation chronologique : premièrement l'organigramme, ensuite viennent les rôles des fonctions et les workflows, et finalement la définition des paramétrages dans le modèle de données, les masques de l'écran et les états.
Ainsi une utilisation directe des variantes des processus de gestion déjà contenues dans le modèle de référence standard est possible par le biais du Business Engineering Environment. Ainsi, l'utilisateur a un aperçu général. Une prise en compte des modifications souhaitées s'effectue déjà dans cette phase préliminaire. Leur modélisation et documentation immédiate dans un prototype est possible grâce à l'outil.
Clé de la réussite de projet
L'innovation est marquée par l'intégration de la documentation et la création des scénarios de test dans le processus d'adaptation déjà avant la réalisation. Les informations relatives à chaque modification sont, dès le départ, disponibles permettant de tester l'adaptation implémentée. La qualité de l'application dépend essentiellement de celle des données test et des scénarios.
L'avantage de la description intégrée et de la formalisation des données test et des scénarios en fonction du modèle est le contrôle de l'intégralité et de l'exactitude des spécifications de l'utilisateur. Les anomalies de conception sont rapidement identifiables lorsque les scénarios sont orientés pratique. Les délais de livraison sont respectés par la réduction "des programmations ultérieures" pendant l'activité de test.
Le développeur de logiciel a ainsi la possibilité de mieux estimer et calculer le temps investi dans les tests dès la phase de planification. En outre, grâce à des spécifications concrètes des données test et des cas d'utilisation, il obtient des informations relatives à la performance dont il tiendra compte au cours de la codification. Aussi, on constate une réduction des perturbations liées aux travaux d'amélioration lors de la livraison du logiciel.
Les scénarios de tests peuvent être utilisés pour des formations ou mis en œuvre dans le cadre d'un e-Learning. Les utilisateurs sont formés le long d'une courbe d'apprentissage plate conformément aux types d'utilisation nécessaires et testés.
L'organisation et la structure MDT permettent d'atteindre les avantages mentionnés plus haut :
L'organisation des scénarios de test est orientée processus de gestion. Des cas d'utilisation sont exigés pour tout le processus, un masque, une tâche, une opération et un workflow dans le but d'assurer une couverture autant que possible complète des processus de gestion de la solution, adaptée au modèle de gestion. Le test est divisé en :
Deux types de tests sont possibles. Soit un état de la base de données préalablement "figé" est utilisé soit les données d'un test précédent servent de base.
Les scénarios de test décrivent les saisies d'un utilisateur dans le dialogue, y compris l'enregistrement des données concernées. Les données enregistrées directement sont à compléter par l'utilisateur en raison des spécifications d'un résultat attendu. Contrairement aux descriptions manuelles passées, les spécifications de tests sont directement enregistrées dans l'application par un magnétophone et sauvegardées sous la forme de scripts de test python.
La gestion des scripts de test mentionnés plus haut s'effectue dans Test-Suite où leur lecture est possible à tout moment et autant de fois que nécessaire. Les données enregistrées à chaque "lecture" sont utilisées à l'étape suivante pour l'analyse du test. Au cours de la lecture d'un scénario de test, l'utilisateur peut suivre et piloter le déroulement comme dans un débogueur. Ainsi, les scénarios de test peuvent être exploités dans toutes les phases du cycle de vie du logiciel.
L'exécution d'un test automatique est surveillée par un moniteur de test intégré qui signale les écarts avec le résultat attendu. L'utilisateur peut imprimer les protocoles de tests de manière à pouvoir suivre le déroulement du test jusqu'à la saisie du champ et jusqu'au résultat ciblé.
La qualité du logiciel peut être gérée dès la phase de conception par le biais du MDT intégré. La condition sine qua non est une mise en œuvre conséquente du concept 2BEE. Etant donné que les tests automatiques peuvent être répétés aussi souvent que voulu, ils peuvent toujours être appliqués au logiciel modifié. Ainsi non seulement une qualité constante, mais aussi perfectible du logiciel est garantie par chaque test de scénario supplémentaire.
"Ce processus est, pour nous clients, synonyme de gain de vitesse, de sécurité et de réduction des coûts dans le processus de développement du logiciel" commente M. René Petit, Directeur financier chez Coop Alsace.
Une vue d'ensemble des avantages du Test-Suite: