Les tests SAP expliqués : types, phases et responsables

Les tests SAP consistent à prouver qu'un système SAP paramétré exécute correctement vos processus métier, avec vos données et à vos volumes, avant sa mise en production et à chaque modification ensuite. Sur un programme S/4HANA, ils couvrent six types de tests : tests unitaires, tests d'intégration système (SIT), tests d'acceptation utilisateur (UAT, la recette), tests de non-régression, tests de performance et répétition de bascule.

Chaque type répond à une question différente, et aucun ne remplace un autre. D'après mon expérience, les tests représentent environ 35 % de l'effort d'un programme. C'est pourquoi ils méritent leur propre plan, leur propre budget et leurs propres responsables, plutôt que quelques semaines à la fin du développement.

Cette page est la vue d'ensemble. Chaque type a son propre guide, accessible depuis les sections ci-dessous.

Un système SAP, c'est du paramétrage, des données de base, du code spécifique et des interfaces qui fonctionnent ensemble. Une modification à un endroit peut casser un processus ailleurs, souvent dans un module que personne n'a touché.

C'est pourquoi les tests SAP s'organisent autour des processus métier plutôt que des écrans. Order to cash, procure to pay et record to report traversent plusieurs modules, et un test qui s'arrête à une seule transaction ne prouve pas grand-chose.

Les tests ne s'arrêtent pas non plus au go-live. Les corrections de support, les versions SAP et les nouveaux déploiements modifient tous le système, et la même discipline se poursuit donc dans la phase Run.

Voici les six types que je planifie sur un programme S/4HANA. Le tableau indique ce que chacun prouve, quand il a lieu et qui doit en être responsable.

Type de test	Ce qu'il prouve	Place dans SAP Activate	Responsable
Tests unitaires	Chaque élément de paramétrage, programme ou amélioration fonctionne isolément	Realize, dans chaque sprint de développement	Consultants fonctionnels et techniques
Tests d'intégration système (SIT)	Les processus complets s'exécutent à travers les modules et les interfaces avec des données réalistes	Realize, en plusieurs cycles une fois le développement stabilisé	Responsable des tests du programme, avec les responsables de processus
Tests d'acceptation utilisateur (UAT)	Le métier peut exécuter ses scénarios réels sur le système	Fin de Realize, avant Deploy	Le métier
Tests de non-régression	Ce qui fonctionnait avant fonctionne toujours après une modification	À partir de Realize, puis à chaque version en Run	Responsable des tests, avec de l'automatisation quand le volume le justifie
Tests de performance	Le système tient avec de nombreux utilisateurs simultanés et les volumes de production	Realize, terminés avant le go-live	Responsable performance au niveau du programme, avec l'équipe Basis
Répétition de bascule	La séquence de go-live, les chargements de données et les durées fonctionnent de bout en bout	Deploy	Responsable de la bascule

Les tests SAP au fil de SAP Activate

1. 01

   Prepare

   Mettre en place l'outil de test, l'équipe et l'environnement de test.

2. 02

   Explore

   Rédiger la stratégie de test pendant les décisions de Fit-to-Standard, pour que les exigences soient testables.

3. 03

   Realize

   Tests unitaires dans les sprints, puis cycles de SIT, tests de performance et UAT une fois le développement stabilisé.

4. 04

   Deploy

   Répétitions de bascule sur la base d'une checklist validée, puis décision de go-live.

5. 05

   Run

   Tests de non-régression pour chaque correction de support, mise à niveau et version.

Tests unitaires

Les tests unitaires sont réalisés par ceux qui ont construit l'élément. Un consultant fonctionnel vérifie une condition de prix, un développeur vérifie une amélioration ou le mapping d'une interface.

Ils sont nécessaires, mais pas suffisants. Un test unitaire réussi ne vous dit rien de ce qui se passe quand cet élément rencontre le reste du processus.

Tests d'intégration système

Le SIT est le moment où le programme découvre si la conception fonctionne. Une commande client doit s'enchaîner avec la livraison, la facturation, la comptabilité et le reporting, et chaque interface en chemin doit comptabiliser correctement.

Je planifie le SIT en plusieurs cycles, pas en un seul passage. Les anomalies trouvées au premier cycle sont corrigées, et le cycle suivant prouve que les corrections n'ont rien cassé ailleurs. L'articulation des cycles, des critères d'entrée et des critères de sortie est décrite dans mon guide de stratégie de test S/4HANA.

Tests d'acceptation utilisateur

L'UAT, c'est le métier qui confirme que le système permet de travailler comme il travaillera après le go-live. Elle appartient au métier, pas à l'intégrateur, car seul le métier peut accepter le système.

L'UAT demande au moins 6 à 8 semaines. Si vous la comprimez pour absorber un développement en retard, vous obtenez une validation sur le papier et des problèmes en production. Mon guide sur les tests d'acceptation utilisateur SAP couvre les scripts, les rôles et la validation.

Tests de non-régression

Les tests de non-régression rejouent des tests déjà validés après une modification, pour détecter ce que la modification a cassé. Sur un programme long, les corrections du support en production et les évolutions du projet passent en même temps dans le système.

Mon approche consiste à faire tourner deux environnements distincts, l'un pour le projet et l'autre pour l'exploitation courante (BAU). Les corrections du support et les évolutions du projet sont alors testées séparément, et aucune ne masque une anomalie de l'autre. Mon guide sur les tests de non-régression SAP couvre l'approche à deux environnements, les mises à niveau et l'analyse d'impact.

Tests de performance

Les tests de performance doivent avoir lieu avant le go-live. Les plus importants sont les tests de concurrence, avec de nombreux utilisateurs qui exécutent des transactions au même moment.

Une transaction correcte pour un utilisateur peut tomber en timeout pour deux cents. Les tests fonctionnels ne vous le montreront jamais. Mon guide pour les DSI sur les tests de performance SAP couvre les tests de charge, de stress et d'endurance, ainsi que la rédaction des critères d'acceptation.

Répétition de bascule

La répétition de bascule teste le go-live lui-même : la séquence des étapes techniques, les chargements de données, les rapprochements et les validations, avec leurs durées. Sur une conversion brownfield, je planifie trois conversions à blanc avant la bascule.

Le critère de go-live sur lequel j'insiste est une checklist de bascule détaillée, validée à l'avance. Si la checklist est rédigée pendant le week-end de bascule, les répétitions n'en étaient pas vraiment.

D'après mon expérience, les tests représentent environ 35 % de l'effort d'un programme. Ce chiffre surprend les sponsors qui voient les tests comme le court intervalle entre le développement et le go-live.

L'effort est réparti sur de nombreuses personnes. Les consultants exécutent les tests unitaires, une équipe de test prépare et exécute le SIT, les utilisateurs métier exécutent l'UAT, et les équipes Basis et intégration accompagnent les tests de performance et les répétitions de bascule.

La migration des données se déroule en parallèle et représente à elle seule 30 à 40 % de l'effort. Les deux se recoupent fortement, car chaque cycle de test a besoin de données migrées qui ressemblent à la production.

L'échec de test le plus fréquent que je constate est tout simplement un manque de tests en SIT et en UAT. Les cycles sont réduits quand le développement prend du retard, et la date de go-live ne bouge pas. Sur les 21 programmes SAP que j'ai dirigés ou redressés, la plus grande erreur reste de ne pas planifier correctement au départ, et c'est généralement dans les tests qu'elle apparaît en premier.

Les tests ne valent que ce que valent les données sur lesquelles ils s'exécutent. Ma règle : des données masquées, mais au niveau de la production. Des volumes à l'échelle de la production et des enregistrements réalistes, avec les champs personnels et sensibles masqués.

Des données de test réduites et propres cachent les problèmes qui comptent. Un état qui s'exécute en quelques secondes sur quelques milliers d'enregistrements peut tourner pendant des heures sur une année complète de comptabilisations.

L'environnement compte autant que les données. Planifiez l'environnement de test en Prepare, décidez comment il est rafraîchi entre les cycles, et gardez séparées les évolutions du projet et celles de l'exploitation courante. Mon guide sur la gestion des données de test SAP couvre les copies, le masquage et les données de test sélectives.

Ma règle sur l'automatisation est simple. Quand un grand nombre de cas de test doivent être testés de façon approfondie et répétée, automatisez. En dessous, les tests manuels conviennent.

C'est généralement sur la non-régression que l'automatisation est rentable en premier, car les mêmes tests sont rejoués après chaque modification. L'UAT reste largement manuelle, car son objet est le jugement d'un utilisateur métier, pas celui d'un script.

Il y a une raison pratique de décider tôt. Les tests automatisés demandent du temps à construire et à maintenir, et ne sont donc rentables que s'ils sont exécutés de nombreuses fois. Mon guide de l'automatisation des tests SAP explique par où commencer et à partir de quand elle est rentable.

Les outils se répartissent en trois groupes : gestion des tests, automatisation fonctionnelle et tests de performance. Les équipes que j'ai dirigées ou avec lesquelles j'ai travaillé ont utilisé Tricentis Tosca, Worksoft, Panaya, SAP Cloud ALM, SAP Solution Manager, UiPath et LoadRunner.

Voici ce que fait chaque groupe, avec les produits qui en font partie :

Groupe d'outils	Ce qu'il fait	Produits couramment utilisés par les équipes
Gestion des tests	Plans de test, cas de test, traces d'exécution, anomalies et traçabilité vers les exigences	SAP Cloud ALM, SAP Solution Manager, Panaya
Automatisation des tests fonctionnels	Exécute des tests scriptés ou basés sur des modèles sur des applications SAP et non SAP	Tricentis Tosca, SAP Test Automation by Tricentis, Worksoft, UiPath
Tests de performance	Simule de nombreux utilisateurs simultanés et les volumes de production	OpenText LoadRunner, désormais vendu sous le nom OpenText Professional Performance Engineering

Quelques faits produits méritent d'être connus avant de choisir.

1. SAP Cloud ALM est inclus pour les clients disposant de SAP Enterprise Support ou d'un abonnement cloud qui contient Enterprise Support, cloud editions (SAP Support). Sa gestion des tests couvre la préparation des tests, les plans de test et l'exécution, y compris les cas de test manuels pour l'UAT (SAP Learning).
2. SAP Solution Manager 7.2 : la maintenance standard prend fin fin 2027, avec une maintenance étendue optionnelle jusqu'à fin 2030 pour une partie des fonctions, dont la suite de tests (SAP Support).
3. SAP Test Automation by Tricentis est le produit d'automatisation revendu par SAP, intégré à SAP Cloud ALM et conçu pour les systèmes SAP et tiers (SAP).
4. LoadRunner est un produit OpenText. LoadRunner Professional s'appelle désormais OpenText Professional Performance Engineering, et il prend en charge les protocoles SAP GUI et SAP Web (OpenText).

Si vous démarrez un nouveau programme, prévoyez la gestion des tests dans Cloud ALM plutôt que dans Solution Manager. Pour une comparaison plus approfondie, lisez mon guide sur les outils de test SAP.

Sur SAP Cloud ERP public edition (S/4HANA Cloud Public Edition), SAP met à niveau chaque client selon son propre calendrier. SAP Learning décrit des mises à niveau tous les six mois, actuellement en février et en août, avec de nouvelles fonctionnalités livrées chaque mois entre les deux (SAP Learning).

Vous ne choisissez pas la date de mise à niveau, et les tests de non-régression deviennent donc une échéance fixe du calendrier plutôt qu'un projet. C'est le meilleur argument pour automatiser tôt la non-régression sur un système en cloud public.

En cloud privé et on-premise, vous maîtrisez le calendrier des mises à niveau. Chacune exige malgré tout un cycle de non-régression dimensionné selon les processus touchés par la modification.

Avant toute chose, inscrivez les tests au plan comme un chantier, avec son propre responsable et son propre budget, dimensionné à environ un tiers de l'effort. Ensuite, nommez le responsable métier de l'UAT et bloquez dès maintenant 6 à 8 semaines dans le calendrier, avant que le développement ne la comprime.

Reliez les résultats des tests à vos décisions go/no-go avec des critères de sortie mesurables. Mon guide sur les quality gates SAP montre comment. Si votre programme est déjà en difficulté, mes notes sur le redressement de programmes SAP indiquent ce qu'il faut corriger en premier.

Si vous souhaitez un regard indépendant sur une stratégie de test ou une décision de go-live, j'accompagne les organisations sur ce sujet. Vous pouvez me contacter ici.

Que sont les tests SAP ?

Les tests SAP prouvent qu'un système SAP paramétré exécute correctement vos processus métier, avec vos données et à vos volumes. Sur un programme S/4HANA, ils comprennent les tests unitaires, les tests d'intégration système, les tests d'acceptation utilisateur, les tests de non-régression, les tests de performance et la répétition de bascule. Ils se poursuivent après le go-live pour chaque correction de support et chaque version.

Quels sont les types de tests SAP ?

Les six types principaux sont les tests unitaires, les tests d'intégration système (SIT), les tests d'acceptation utilisateur (UAT), les tests de non-régression, les tests de performance et la répétition de bascule. Les tests unitaires vérifient des éléments isolés, le SIT vérifie des processus complets à travers les modules et les interfaces, et l'UAT, c'est le métier qui accepte le système. La non-régression, la performance et la répétition de bascule protègent contre les modifications, la charge et le go-live lui-même.

Combien de temps durent les tests d'acceptation utilisateur SAP ?

Prévoyez au moins 6 à 8 semaines pour l'UAT. Le métier doit en être responsable, exécuter ses scénarios réels et la valider. Le manque de tests en UAT et en SIT est l'échec de test le plus fréquent que je constate.

Quelle part d'un projet SAP représentent les tests ?

D'après mon expérience, les tests représentent environ 35 % de l'effort d'un programme. Cela couvre la préparation et l'exécution des tests unitaires, des cycles de SIT, de l'UAT, de la non-régression, des tests de performance et des répétitions de bascule. La migration des données se déroule en parallèle et doit fournir des données proches de la production pour chaque cycle de test.

Faut-il automatiser les tests SAP ?

Automatisez quand un grand nombre de cas de test doivent être testés de façon approfondie et répétée, ce qui signifie généralement la non-régression. En dessous, les tests manuels conviennent. L'UAT reste largement manuelle, car son objet est le jugement du métier.

Quel outil utilise-t-on pour les tests SAP ?

La plupart des programmes combinent un outil de gestion des tests, un outil d'automatisation et un outil de tests de performance. Les choix courants sont SAP Cloud ALM ou Solution Manager pour la gestion des tests, Tricentis Tosca, SAP Test Automation by Tricentis, Worksoft ou UiPath pour l'automatisation, et OpenText LoadRunner pour la performance. Les nouveaux programmes devraient prévoir Cloud ALM, puisque la maintenance standard de Solution Manager prend fin en 2027.