Celui qui teste est un lâche

Lors d'un changement de version SAP, il est plus que judicieux de tester à nouveau l'ensemble des processus de l'entreprise dans une chaîne de processus et de garantir ainsi une mise à niveau réussie.

Si le "système SAP" doit être testé, la question de savoir ce qui doit être testé et comment doit être testé se pose généralement. De nombreux clients ont alors l'habitude d'organiser les plans de test vieillissants du dernier patch et de les remanier si nécessaire.

Toutefois, c'est souvent là que se pose la première question : quelles sont les transactions qui ne figurent pas encore sur les plans de test et qui doivent être intégrées, quels sont les rapports qui sont obsolètes et qui ne sont plus du tout utilisés et qui peuvent donc être ignorés.

Rien que cette compilation et cet inventaire ne sont pas une tâche facile. J'ai vu un responsable informatique qui, quatre semaines avant le début de la phase de test, a demandé aux départements spécialisés d'inscrire toutes les transactions utilisées dans une feuille Excel de manière continue.

C'est certes un bon début, mais c'est un travail de Sisyphe. En particulier, la période d'observation n'est généralement pas suffisante. Le Blueprint Generator, que SAP fournit désormais à titre indicatif, permet d'inventorier les transactions utilisées dans le système de production et de les classer dans la documentation de la solution.

Ce n'est pas encore un plan de test, mais cela permet de s'assurer que toutes les transactions utilisées sont effectivement inventoriées dans une structure. Il est ainsi possible de créer facilement une base de départ pour un plan de test, qui est avant tout complète.

Le générateur de Blueprint, très utile, peut également effectuer des mises à jour delta, c'est-à-dire ajouter de nouvelles transactions aux structures existantes. C'est généralement le cas lorsqu'il existe déjà une documentation, mais qu'elle a un peu vieilli.

Comment créer un outil de test puissant

Un plan de test peut ensuite être élaboré sur la base de la structure de documentation générée. Il est vrai que, techniquement, un plan de test peut être créé et exécuté à partir de cette structure.

Ce plan ne contient toutefois que les transactions. En général, cela n'est pas encore très utile, car il manque encore des indications pertinentes sur les données de base, les types de documents et les types de postes avec lesquels une transaction doit être réellement testée.

Il est judicieux de compléter les structures générées par les documents Excel que la plupart des clients ont de toute façon sur des partages de fichiers et qu'ils utilisent en partie pour organiser leurs cas de test.

Ces documents peuvent également être révisés et affinés dans une étape ultérieure, mais en règle générale, il est important de commencer par établir une base de départ et un début.

Si les documents sont suffisamment complets, il est possible de créer des plans de test pertinents. Les plans de test sont généralement utilisés pour créer des paquets de test et ceux-ci sont attribués à des personnes individuelles.

Il est judicieux de tester les processus tels qu'ils se déroulent dans la réalité et de ne pas se contenter d'effectuer des tests individuels axés sur les fonctions. Dans cette optique, il convient de créer des "séquences de test" qui reproduisent le déroulement naturel d'une chaîne de processus.

Ainsi, ces séquences permettent également à plusieurs services spécialisés de collaborer sur un processus. La variante de luxe associée aux séquences de test prévoit que les testeurs soient également invités par e-mail à tester leur processus ou leur transaction.

Un modèle de rappel avec fonction d'escalade peut également être réalisé dans le framework. Au final, on obtient un outil de test puissant. Dans l'idéal, les cas de test et les plans de test sont mis à jour en permanence.

Quels sont les processus commerciaux pertinents ?

Étant donné que l'étendue des tests augmente généralement de manière continue à mesure que les fonctionnalités d'un environnement informatique s'étendent, il est d'autant plus important de réaliser des tests ciblés lors des tests d'intégration.

Le Business Process Change Analyzer de SAP peut déterminer les processus de gestion pertinents qui ont été modifiés dans le cadre d'une mise à niveau, d'une fonction de gestion ou même d'un transport. Sur cette base, il est possible de simplifier et d'alléger considérablement les procédures de test, car seuls les processus commerciaux vraiment pertinents doivent être soumis à un contrôle.

En interaction avec une documentation des processus commerciaux et une gestion des changements, le composant de gestion des tests du
Solution Manager peut être un complément utile pour la gestion du cycle de vie des applications. Même si les débuts sont souvent difficiles, une solution pragmatique peut être élaborée et établie de manière simple.