Le système qui se teste lui-même

Ce n'est que récemment que j'ai été interpellé à plusieurs reprises sur les thèmes de la gestion des tests et de la génération de données de test. Plus précisément, des clients m'ont demandé si Solution Manager prenait également en charge le concept de génération de données de test. Dans le contexte global de toutes les fonctionnalités offertes par SolMan, cette question est très avancée.

Avant d'y penser, il convient d'effectuer quelques travaux préparatoires. Une mise à disposition automatique des données est certes utile, mais elle devrait être accompagnée d'un paquet global.

Tout commence par l'inventaire des processus de gestion, puis par la documentation et la saisie dans la documentation de la solution. La note SAP sur le générateur de Blueprint permet d'inventorier les différentes transactions utilisées dans le système de production.

L'affectation d'une transaction à un niveau de structure se fait sur la base de son paquet. Chaque paquet est associé à une composante SAP unique.

Les clients qui ont regroupé toutes leurs transactions Z dans un seul paquet, tous modules confondus, doivent revoir leur copie. Pour la procédure de test, la structure créée avec ses différentes transactions doit être regroupée en plusieurs chaînes de processus de bout en bout au moyen de liens.

La prochaine étape utile est l'utilisation du Business Process Change Analyzer. Pour cela, il faut enregistrer les nomenclatures de tous les processus de gestion pertinents. À l'aide de ces nomenclatures, qui représentent les programmes qui passent et les entrées de Customizing utilisées, il est possible de déterminer, à chaque importation productive, à quels processus de gestion se réfère un ordre de transport. Il est ainsi possible de donner une première tendance quant à l'utilité d'un test.

Comme ces nomenclatures changent à chaque importation dans le système de production, une mise à jour continue est nécessaire. Une fois ces processus établis, on peut maintenant passer au sujet suivant, à savoir l'automatisation des cas de test. L'ECatt, qui a quelque peu vieilli et qui n'est en fait rien d'autre qu'un enregistrement de batch input, ne devrait plus être utilisé.

Avec Component-based Test Automation, SAP met à la disposition des clients disposant d'un contrat Enterprise Support un outil qui est nettement plus simple à utiliser, à enregistrer et à réparer les cas de test.

Outre le SAP Gui classique, toutes les technologies d'interface modernes sont également prises en charge. L'outil intègre déjà les processus de programme connus de toutes les transactions livrées par SAP, ce qui permet de relier facilement un cas de test à un autre sur une interface graphique.

Des connaissances approfondies en programmation ne sont donc plus nécessaires. Les utilisateurs professionnels envisageront certainement de prendre une licence pour un outil de test tel que Worksoft Verify ou HP Quick Test Pro ou HP Quality Center comme alternative au CBTA. L'étape suivante consiste à générer automatiquement les données de test.

De nombreux clients aiment faire une copie du système de production, soit de manière classique, soit avec des outils permettant de limiter le contenu de la base de données. Je ne suis pas favorable aux copies dans des environnements réglementés, car cela permet aussi de faire entrer des données pertinentes et critiques dans le système d'assurance qualité.

La plupart du temps, le concept d'autorisation est un peu plus libre sur le système d'assurance qualité que sur le système de production, ce qui constitue un problème important. La génération de données de test et de données de base pertinentes ne peut être garantie que par la création de cas de test pour la constitution de ces données, qui se déroulent ensuite avant une chaîne de test et génèrent les données. La construction de ces données peut bien sûr être aussi compliquée que l'on veut.

Avec le CBTA, SAP met à disposition un très bon outil avancé permettant d'enregistrer facilement et rapidement les cas de test. Il faut définitivement effectuer un travail préparatoire pour pouvoir bénéficier de cas de test automatiques.

Il est certain que cette approche ne vaut pas la peine pour tous les processus, mais seulement pour ceux qui sont particulièrement pertinents ou qui ne peuvent être testés manuellement qu'au prix d'un effort considérable. Un concept global se compose toujours d'un recours accru aux tests unitaires, aux tests automatisés ainsi qu'à une mise à jour continue de la documentation existante sur les processus.