Stratégie de test S/4HANA : cycles, critères et rôles

Une stratégie de test S/4HANA décide quels cycles de test vous exécutez, dans quel ordre, qui est responsable de chacun et quelles preuves permettent de passer de l'un au suivant. Sur mes programmes, elle couvre les tests d'intégration système (SIT) en plusieurs cycles, les tests d'acceptation utilisateur (UAT) en plusieurs cycles et les tests de non-régression, chacun avec des critères d'entrée et de sortie écrits et une validation nominative.

Les tests représentent environ 35 % de l'effort sur les programmes S/4HANA que je planifie, et la stratégie mérite donc autant de soin que le plan de développement.

Les types de tests eux-mêmes sont décrits dans mon guide les tests SAP expliqués. Cet article traite de la couche stratégique : cycles, critères, rôles et plan du document.

SAP Activate place l'essentiel des tests dans Realize. Le matériel de SAP sur la stratégie de test pour S/4HANA Cloud Private Edition considère les tests unitaires et les tests de chaîne comme informels. Les tests complets de processus métier, d'intégration, de migration des données et d'acceptation utilisateur sont formels et doivent être documentés.

Voici la séquence que je planifie sur un programme S/4HANA :

Les cycles de test S/4HANA

1. 01

   Tests unitaires et de chaîne

   Les consultants testent chaque fonction paramétrée et de courts enchaînements au fil du développement.

2. 02

   Cycles de SIT

   Chaînes de processus complètes à travers les modules, les interfaces et les données migrées.

3. 03

   Cycles d'UAT

   Les utilisateurs métier prouvent, cycle après cycle, que le système exécute leurs processus.

4. 04

   Non-régression

   Re-tester ce qui avait déjà réussi après les corrections, les transports et les versions.

5. 05

   Conversions à blanc et répétition

   Dérouler la bascule comme elle se déroulera le soir J, sur la base de la checklist.

6. 06

   Go-live

   Ne démarrer que lorsque la checklist de bascule validée est complète.

Tests unitaires et tests de chaîne

Les consultants et les développeurs testent chaque élément de paramétrage et chaque développement au fil de la construction. Les tests de chaîne enchaînent quelques étapes, par exemple une commande client jusqu'à la livraison.

Informels au sens de SAP, mais pas facultatifs.

Tests d'intégration système en plusieurs cycles

Le SIT teste des processus métier complets à travers les modules, les interfaces et les données converties ou chargées. Je le planifie en plusieurs cycles plutôt qu'en un seul événement, pour que les anomalies corrigées après un cycle soient re-testées dans le suivant.

Je n'ai pas de nombre fixe de cycles de SIT. Le nombre dépend des processus, des interfaces et des entités du périmètre, et la stratégie doit dire combien de cycles et pourquoi.

Tests d'acceptation utilisateur en plusieurs cycles

L'UAT est le moment où le métier confirme que le système exécute ses processus, avec ses propres équipes et des données réalistes. Comme pour le SIT, je la planifie en plusieurs cycles, pour que les corrections d'un cycle soient re-testées dans le suivant.

L'UAT demande au moins 6 à 8 semaines. Les testeurs métier la mènent en plus de leur travail habituel, et il leur faut du temps pour plus d'un cycle. Mon guide sur les tests d'acceptation utilisateur SAP détaille les scripts, les cycles et la validation.

Tests de non-régression

Chaque correction, chaque transport et chaque version peut casser quelque chose qui avait déjà réussi. Les tests de non-régression rejouent les processus importants après chaque modification, pendant le programme et après le go-live.

Le matériel de SAP place la non-régression surtout dans Run, après les mises à niveau de version, mais un programme en a besoin plus tôt. L'approche, l'analyse d'impact et la mise en place des environnements sont décrites dans mon guide sur les tests de non-régression SAP.

Conversions à blanc et répétition de bascule

Sur une conversion brownfield, je planifie trois conversions à blanc avant la bascule. Chacune teste la conversion elle-même, les durées et le rapprochement, pas seulement les processus.

La dernière répétition doit se dérouler comme la vraie nuit : même séquence, mêmes personnes, même checklist. Mon calendrier et plan de projet de migration S/4HANA montre où ces exécutions se placent dans le plan.

La décision de responsabilité la plus importante : le métier est responsable des tests d'acceptation utilisateur. Ni l'intégrateur, ni la DSI.

Un intégrateur peut préparer les scripts et corriger les anomalies. Seules les personnes qui font tourner votre clôture financière, votre order-to-cash ou votre usine peuvent confirmer que ces processus fonctionnent.

Les recommandations de SAP vont dans le même sens. Les experts paramétrage du partenaire créent les cas de test, et les experts métier du client exécutent l'UAT et enregistrent les résultats.

Voici comment je répartirais les responsabilités entre les cycles :

Cycle	Responsable	Exécute	Valide
Unitaires et de chaîne	Responsable de l'équipe de développement	Consultants et développeurs	Responsables fonctionnels et techniques
Cycles de SIT	Test manager	Consultants, rejoints par les utilisateurs clés lors des derniers cycles	Test manager et responsables de processus
Cycles d'UAT	Le métier, via des responsables de processus nommés	Utilisateurs clés et testeurs métier	Responsables de processus, puis le sponsor
Non-régression	Test manager	Équipe de test, avec de l'automatisation quand le volume le justifie	Test manager et comité des changements
Conversions à blanc et répétition	Responsable de la bascule	Équipes techniques, données et fonctionnelles	Responsable de la bascule, responsable des données et sponsor

Inscrivez des noms dans la stratégie, pas des rôles. « Responsable du processus finance » est un rôle ; une personne nommée qui a accepté de signer est un responsable.

Les critères d'entrée empêchent un cycle de commencer avant qu'il puisse réussir. Les critères de sortie l'empêchent de se terminer simplement parce que le calendrier le dit.

Rédigez les deux avant le début de Realize, quand personne n'est encore sous la pression des délais. Mon guide sur les quality gates SAP explique comment ces critères deviennent des jalons formels, avec un responsable capable de dire « pas prêt ».

Le tableau ci-dessous est une base à adapter, pas une norme à copier. Fixez les pourcentages et les seuils d'anomalies avec votre sponsor et consignez-les dans la stratégie :

Cycle	Critères d'entrée	Critères de sortie
Unitaires et de chaîne	Conception validée ; paramétrage et développements terminés pour les éléments testés	Tous les éléments testés et documentés ; anomalies corrigées ou consignées pour le SIT
Cycle de SIT	Tests unitaires terminés pour les processus du périmètre ; environnement de test construit et interfaces connectées ; données de test chargées ; scripts revus	Part convenue des scripts exécutés et réussis ; aucune anomalie critique ouverte ; chaque anomalie mineure ouverte a un responsable et une date de correction
Cycle d'UAT	Critères de sortie du SIT atteints ; testeurs métier nommés et libérés de leur travail habituel ; scripts revus par les responsables de processus ; formation sur le système de test effectuée	Chaque processus du périmètre exécuté par des utilisateurs métier ; aucune anomalie critique ouverte ; les responsables de processus ont validé leurs processus
Non-régression	Une modification, un lot de corrections ou une version prêts à avancer ; lot de non-régression convenu pour les processus concernés	Lot de non-régression réussi ; tout échec corrigé et re-testé avant que la modification n'avance
Conversion à blanc ou répétition	Copie de production disponible ; checklist de bascule et run book rédigés ; règles de rapprochement convenues	Conversion ou chargement terminé dans la fenêtre prévue ; rapprochement validé par le responsable des données ; checklist mise à jour avec les enseignements
Go-live	Tous les critères de sortie précédents atteints ; checklist de bascule validée à l'avance	Chaque point de la checklist terminé et signé ; décision go/no-go consignée par le sponsor

Deux règles font fonctionner ce tableau. Chaque critère donne une réponse par oui ou par non, et chaque sortie a un signataire nommé.

Si un cycle n'atteint pas ses critères de sortie et que le métier veut tout de même avancer, faites-en une décision écrite. Nommez la personne qui a accepté le risque et les anomalies reportées.

Le test manager le rédige en Prepare ou au début d'Explore, et le sponsor l'approuve. Gardez-le assez court pour que les responsables de processus le lisent.

Voici les sections que je m'attends à y trouver :

1. Périmètre et objectifs. Quels processus, entités, interfaces et états sont testés, et lesquels sont explicitement exclus.
2. Types et cycles de test. Tests unitaires, tests de chaîne, cycles de SIT, cycles d'UAT, non-régression, performance, tests de migration des données et conversions à blanc, avec le nombre de cycles et sa justification.
3. Calendrier et effort. Les dates de chaque cycle dans le plan SAP Activate, avec au moins 6 à 8 semaines pour l'UAT, et l'effort budgété par rapport à la part d'environ 35 % consacrée aux tests.
4. Rôles et responsabilités. Le tableau des responsabilités ci-dessus, avec des noms.
5. Critères d'entrée et de sortie. Un jeu par cycle, avec le signataire de chacun.
6. Environnements. Quels systèmes servent à quel cycle, comment ils sont rafraîchis et comment les évolutions du projet sont tenues à l'écart des corrections du support en production.
7. Données de test. D'où viennent les données, comment elles sont masquées et comment elles sont rafraîchies entre les cycles. Mon guide sur la gestion des données de test SAP traite ce point en détail.
8. Gestion des anomalies. Définitions de gravité, rythme de tri, qui décide de la priorité et délai de correction cible par gravité.
9. Outils. Où se trouvent les cas de test, les résultats, les anomalies et les validations, avec un seul système de référence.
10. Approche d'automatisation. Quels tests sont automatisés, lesquels restent manuels et pourquoi.
11. Reporting. Ce que montre le rapport de test hebdomadaire et qui le reçoit.
12. Critères de bascule et de go-live. La checklist de bascule, les répétitions qui la valident et qui prend la décision go/no-go.
13. Risques et hypothèses. Disponibilité des testeurs, dates des environnements, préparation des données et dépendances envers des tiers.

Côté outils, SAP Cloud ALM est le choix par défaut pour les nouveaux programmes. SAP indique qu'il n'y a pas de licence séparée pour SAP Cloud ALM : il est inclus avec Enterprise Support, et ses applications de gestion des tests contiennent les cas de test formels, les exécutions et les résultats.

SAP Solution Manager 7.2 est encore utilisé sur de nombreux programmes, mais sa maintenance standard prend fin fin 2027. Pour l'automatisation, SAP vend SAP Test Automation by Tricentis, qui fonctionne avec Cloud ALM ; ma comparaison des outils de test SAP couvre le choix plus large.

L'échec de test le plus fréquent que je constate est un manque de tests en UAT et en SIT.

Un mécanisme courant : le développement prend du retard, la date de go-live reste fixe, et les semaines sont prises sur les cycles de test parce qu'ils se trouvent à la fin du plan.

Voici les schémas qui en sont la cause, et ce qu'il faut faire pour chacun :

1. Le SIT démarre avant la fin des tests unitaires. Le premier cycle de SIT devient un cycle de tests unitaires. Tenez les critères d'entrée.
2. L'UAT est planifiée sur deux ou trois semaines. Les utilisateurs métier ne peuvent pas tester correctement en plus de leur travail habituel dans ce délai. Prévoyez au moins 6 à 8 semaines et libérez les testeurs.
3. L'intégrateur mène l'UAT à la place du métier. Les scripts réussissent, et le métier découvre les manques après le go-live. Laissez la responsabilité de l'UAT aux responsables de processus.
4. Les tests sont budgétés comme une petite ligne. À environ 35 % de l'effort, des tests budgétés à une fraction de ce chiffre sont coupés en premier.
5. Les critères de sortie sont rédigés pendant le cycle. Ils finissent par correspondre à ce que l'équipe a obtenu. Rédigez-les avant Realize.
6. Le go-live est décidé sur la confiance, pas sur une checklist. Personne ne peut montrer ce qui avait été convenu, donc personne ne peut dire ce qui manque.

Ce dernier point est celui sur lequel j'insiste. Mon critère de go-live est une checklist de bascule détaillée, validée à l'avance avec le métier, la DSI et l'intégrateur.

Elle couvre les étapes techniques, les chargements de données, les rapprochements, les validations métier, les basculements d'interfaces, les accès utilisateurs et les points de décision go/no-go. Si un point n'est pas terminé et signé, le programme n'est pas prêt, quoi que dise la date.

Avant le début de Realize, demandez à votre test manager le document de stratégie de test et comparez-le au plan ci-dessus. S'il ne nomme pas de responsable de l'UAT, accorde à l'UAT moins de 6 à 8 semaines ou ne prévoit pas de critères d'entrée et de sortie par cycle, corrigez cela en premier.

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

Qu'est-ce qu'une stratégie de test S/4HANA ?

C'est le plan qui décide quels cycles de test s'exécutent, dans quel ordre, qui est responsable de chacun et le valide, et quelles preuves permettent au programme de passer d'un cycle au suivant. Sur un programme S/4HANA, elle couvre généralement les tests unitaires et de chaîne, les cycles de SIT, les cycles d'UAT, la non-régression, les tests de migration des données et les répétitions de bascule.

Quelle part d'un programme S/4HANA représentent les tests ?

Sur les programmes que je planifie, les tests représentent environ 35 % de l'effort du programme. Budgétez-les à ce niveau dès le départ, car des tests sous-financés sont la première chose coupée quand le développement prend du retard.

Combien de temps doit durer l'UAT sur un projet S/4HANA ?

Au moins 6 à 8 semaines. Les testeurs métier mènent l'UAT en plus de leur travail habituel, et il leur faut du temps pour plus d'un cycle, afin que les corrections du premier cycle soient re-testées.

Qui doit être responsable des tests d'acceptation utilisateur dans SAP ?

Le métier, via des responsables de processus nommés. L'intégrateur peut préparer les scripts, gérer l'environnement et corriger les anomalies, mais seules les personnes qui font tourner les processus peuvent confirmer que le système leur convient.

Que sont les critères d'entrée et de sortie dans les tests SAP ?

Les critères d'entrée sont les conditions dont un cycle a besoin avant de commencer, comme des tests unitaires terminés, un environnement construit et des données de test chargées. Les critères de sortie sont les conditions qu'il doit remplir avant de se terminer, comme des scripts exécutés, aucune anomalie critique ouverte et la validation des responsables de processus. Chacun doit donner une réponse par oui ou par non et avoir un signataire nommé.

Que doit contenir une checklist de go-live S/4HANA ?

Les étapes techniques de bascule, les chargements de données et les rapprochements, les validations métier, les basculements d'interfaces, les accès utilisateurs et les points de décision go/no-go. Validez-la à l'avance, répétez-la lors des conversions à blanc ou de la répétition générale et ne passez en production que lorsque chaque point est terminé et signé.