Des tests intelligents

Tester, c'est être lâche ? Pas du tout ! Ceux qui ne testent pas ne connaissent pas le Business Process Change Analyzer (BPCA) en tant que fonctionnalité partielle de SolMan - ni ses avantages imbattables dans le cadre de l'optimisation de l'étendue des tests.

Les responsables de processus, les gestionnaires de tests, les utilisateurs/testeurs clés, la base SAP, tous les décideurs ainsi que les utilisateurs finaux en profitent. Et donc, au final, la stabilité des processus ou l'exploitation SAP.

Car celui qui veut vraiment tester intelligemment a besoin d'un tel outil. Et certainement tous les acteurs susmentionnés disposant d'un solide savoir-faire en matière de processus - surtout pour pouvoir classer les résultats du BPCA, en particulier pour le périmètre de test défini par le BPCA et donc les cas de test définis. C'est là que se situe le cœur du BPCA.

Mais reprenons les choses dans l'ordre :

• Qui peut utiliser le BPCA ?
• Comment s'y prendre ?
• Quels sont les cas d'utilisation de BPCA ?
• Quel est le résultat ?
• Et quel profit en tirerai-je ?
• Et pourquoi un article sur le BPCA maintenant, alors qu'il existe déjà depuis quelques années ?

Commençons par cette dernière question : avec SolMan 7.2, une documentation réorganisée sur les solutions est disponible. Solution signifie ici "solution" : Unité de tous les systèmes, y compris la documentation des processus, les cas de test, les unités exécutables ([Z-]transaction, [Z-]rapport). La documentation de la solution peut être différenciée selon le degré de maturité (production vs. maintenance vs. développement/sandbox). Cela permet de séparer les versions de la documentation en fonction de leur contenu.

Quels sont les cas d'utilisation de BPCA ? Quel est le résultat ? Et quels sont les avantages que j'en retire ? La question centrale derrière tous les cas d'application est la suivante : quels sont les processus critiques pour l'entreprise qui sont concernés par un changement effectué ? En d'autres termes, quels sont les processus qui doivent être (re)testés afin de garantir la stabilité des processus ou le fonctionnement de SAP ?

Les modifications pertinentes pour le BPCA peuvent être : mise à niveau SP/EhP, activation de la fonction de gestion, (objet dans un) ordre de transport, document de modification ChaRM y compris les ordres de transport ainsi que les listes d'objets. Toutes les modifications pertinentes pour le BPCA ont un point commun : elles doivent être présentes dans un ordre de transport dans le système de développement.

Le résultat BPCA est une liste de tous les processus/étapes de processus concernés par une modification, c'est-à-dire le périmètre à (re)tester. Si aucun plan de test n'est disponible, il suffit d'appuyer sur un bouton pour en générer un et le stocker dans la Test Suite.

Il n'est pas possible d'aller plus vite ! Si le périmètre de test défini initialement par le BPCA est trop vaste ou ne peut pas être traité dans le temps imparti par les ressources disponibles, il existe des approches pragmatiques pour optimiser le périmètre de test (par exemple, couverture de test de 75% : 10 cas de test vs couverture de test de 90% : 100 cas de test).

L'utilité est claire : une première recommandation sur le périmètre à (re)tester. Souvent une tâche intellectuellement inabordable. De plus, il n'est souvent pas possible de l'organiser en termes de ressources.

Une révision du résultat du BPCA par un expert en processus est à mon avis indispensable. En effet, celui qui veut sciemment se méprendre sur l'utilité du BPCA ne devrait même pas se lancer.

Et maintenant, les dernières questions : qui peut utiliser le BPCA ? Comment s'y prendre ?

Les clients de SAP Enterprise Support bénéficient actuellement de l'analyse BPCA. Le chemin vers l'analyse BPCA se présente dans les grandes lignes comme suit : Définir des processus et des étapes de processus et les enregistrer avec des unités exécutables, effectuer la configuration BPCA dans le solman_setup et générer des "Technical Bill of Materials" (TBOM) par unité exécutable sur la base des données UPL/SCMON dans le système de production.

Ensuite, on place la modification dans un ordre de transport, on exécute l'analyse BPCA sur cet ordre de transport, on analyse/interprète le résultat et, le cas échéant, on crée un plan de test à partir de celui-ci - et voilà ! La voie vers le "smart testing" est ainsi ouverte.