Une montée de version SAP ne devrait pas casser votre activité. Thunders s'en assure.
Thunders garde vos processus SAP critiques opérationnels à travers chaque migration et montée de version. Décrivez le processus en langage naturel : créer une commande d'achat, enregistrer une réception de marchandises. Thunders construit un test qui s'exécute sur vos écrans Fiori et UI5. Il le rejoue avant et après chaque montée de version S/4HANA, pour que finance, achats et supply chain fonctionnent encore le jour du go-live. Aucun script à écrire. Aucune régression manuelle à subir.
Chaque montée de version SAP met vos processus métier en danger.
- Chaque montée de version S/4HANA impose une régression complète dans une fenêtre serrée
- Les utilisateurs métier retestent les mêmes processus à la main, release après release
- L'automatisation est enfermée dans des outils spécialisés que les consultants fonctionnels ne peuvent pas toucher
- La couverture des processus clés reste limitée parce que les tests manuels mangent le temps
- Décrivez le processus une fois. Thunders le rejoue à travers chaque migration et montée de version
- Fini les marathons de régression manuelle avant le go-live
- Toute l'équipe peut créer un test, consultants fonctionnels et utilisateurs métier inclus
- Couverture réelle sur les flux finance, achats et supply chain
Une seule façon de protéger chaque migration SAP.
Les autres outils SAP livrent des packs d'accélérateurs pré-construits à configurer. Thunders construit le test à partir du processus que vous décrivez, puis le garde fonctionnel à travers chaque montée de version.
Générez à partir du processus
Décrivez le processus tel que le métier le déroule : créer une commande d'achat, enregistrer une réception de marchandises. Thunders construit le test à travers les écrans Fiori et UI5 concernés.
Faites-le tourner à travers la migration
Pointez Thunders vers le système mis à jour et relancez toute votre suite. Vous voyez ce qui fonctionne encore et ce que la migration a cassé avant que vos utilisateurs ne le découvrent.
Se maintiennent seuls
Quand une montée de version déplace un écran ou change un élément, Thunders détecte la différence et répare le test. Votre suite survit à la migration.
En action sur un vrai parcours SAP : une commande d'achat dans Fiori
1. Décrivez
Créer une commande d'achat dans Fiori pour 10 unités d'un article, la soumettre pour approbation, et confirmer que le statut passe à “approuvé”.
2. Générez
Thunders construit les étapes à travers les écrans Fiori, avec des vérifications sur le numéro de commande et le statut.
3. Exécutez
Le test s'exécute sur les navigateurs utilisés par votre équipe, à la demande ou dans votre pipeline.
4. Migrez
Une montée de version S/4HANA change la disposition de l'écran d'approbation. Thunders applique le self-healing aux étapes concernées. Aucune réécriture.
Fonctionne avec la stack web SAP que vous utilisez déjà.
Fiori launchpad, applications UI5 et interfaces web S/4HANA Cloud. Plus GitHub Actions, GitLab CI, Jenkins, CircleCI, Azure DevOps, Jira, Slack et Teams.
Questions Fréquemment Posées
Puis-je tester SAP Fiori et S/4HANA sans écrire de scripts ?
Oui. Vous décrivez le processus métier en langage naturel : créer une commande d'achat, enregistrer une réception de marchandises. Thunders construit le test à travers les écrans Fiori et UI5 concernés. Il n'y a aucun sélecteur à scripter, ni de framework à mettre en place au préalable.
Vos tests SAP survivront-ils à une montée de version ou une migration S/4HANA ?
Oui. Les tests Thunders décrivent le processus, pas les ID d'éléments sous-jacents, donc ils tiennent quand une mise à jour change l'écran. Quand une étape est affectée, le self-healing de Thunders la répare automatiquement, si bien que vous relancez votre suite pendant la migration plutôt que de la réécrire dans l'urgence.
Dois-je être développeur pour automatiser les tests SAP ?
Non. Comme les tests sont écrits en langage naturel, les consultants fonctionnels et les utilisateurs métier peuvent les créer eux-mêmes, ce sont eux qui savent déjà comment le processus doit se dérouler. C'est la raison principale pour laquelle autant de tests SAP restent manuels aujourd'hui : l'automatisation historique est enfermée dans des outils spécialisés que la majorité de l'équipe ne peut pas utiliser.
Quelles applications SAP Thunders teste-t-il ?
Thunders teste les interfaces web SAP : le Fiori launchpad, les applications UI5 et S/4HANA Cloud, sur les flux finance, achats et supply chain. Il ne couvre pas le client desktop SAP GUI classique.
Comment Thunders gère-t-il les ID d'éléments dynamiques de Fiori ?
Fiori génère des ID d'éléments qui changent d'une session et d'une release à l'autre, ce qui casse les scripts basés sur des sélecteurs. Thunders cible l'intention de chaque étape plutôt qu'un locator fixe, donc le test continue de s'exécuter même quand l'ID sous-jacent change.
En quoi Thunders diffère-t-il d'outils comme Tricentis Tosca ou Worksoft ?
Les outils de test SAP traditionnels livrent des packs d'accélérateurs pré-construits à configurer, ou des scripts qu'une équipe spécialisée maintient après chaque changement. Thunders construit le test à partir du processus que vous décrivez et le garde fonctionnel à travers chaque mise à jour, donc vous ne maintenez pas de bibliothèque de scripts et n'attendez pas après une équipe d'automatisation dédiée.
Puis-je exécuter mes tests SAP dans mon pipeline CI/CD ?
Oui. Les résultats arrivent dans GitHub Actions, GitLab CI, Jenkins ou Azure DevOps, ainsi que dans Jira et Teams, pour que la régression SAP s'exécute aux côtés du reste de votre processus de release.
Voir plus de cas d'usage
Prêt à livrer plus vite grâce à des tests plus intelligents?
