Aucune donnée de production Secrets chiffrés Un scénario, plusieurs profils
Un scénario qui rejoue toujours le même compte finit par ne plus rien prouver. Variables, jeux de données et environnements séparés font tourner le même test sur des cas différents, sans le dupliquer.
Deux échecs classiques. Le premier, un unique compte utilisé partout : le jour où il est bloqué, toute la campagne tombe et le rapport devient illisible. Le second, une copie de la base de production dans l’environnement de recette, ce qui règle le problème de réalisme et en crée un bien plus gros côté RGPD.
Il existe un troisième usage, moins connu et pourtant réclamé par nos clients : produire les données elles-mêmes. Chez un acteur de la logistique, nous créons ainsi les jeux de données destinés à la mise en production. Le moteur ne se contente plus de consommer des données pour vérifier un parcours, il les fabrique en suivant les règles métier, à la fréquence et au volume demandés.
Vos jeux de données arrivent par fichier. Une ligne par cas, une colonne par valeur qui change dans le scénario.
Les données peuvent aussi être poussées par appel d’API, pour les rafraîchir avant une campagne sans intervention manuelle.
Un administrateur marque une donnée comme protégée : les autres utilisateurs de l’espace de travail ne la voient pas, et elle n’apparaît pas dans un rapport.
URL, comptes et clés changent selon la recette, la préproduction ou la production. Le scénario, lui, ne change pas.
Un seul scénario, quatre lignes dans un fichier. C'est ce qui fait la différence entre couvrir un parcours et couvrir ses cas limites.
ALLER PLUS LOIN
Chaque brique de la plateforme, de la création du scénario à la preuve de son exécution.
Un terme vous échappe ? Le glossaire du test automatisé le définit.
VOS QUESTIONS
Origine des données, secrets, environnements : les réponses aux questions qui reviennent le plus souvent.
De trois endroits. Un fichier que vous importez, un appel d'API qui les pousse avant la campagne, ou un scénario dédié qui va les créer directement dans votre application, comme le ferait un utilisateur.
C'est possible, et nous le déconseillons, sauf s'il s'agit de données que vous avez vous-même créées pour les tests. Une copie de base de production dans un environnement de recette est un risque RGPD que rien ne justifie ici.
Chiffrés au repos, et jamais restitués en clair, ni dans un rapport d'exécution ni dans un export. Un administrateur peut en plus marquer une donnée comme protégée : les autres utilisateurs de l'espace de travail ne la voient pas.
Par des variables propres à chaque environnement. Le même scénario tourne en recette, en préproduction et en production, sans être dupliqué ni modifié.
Le scénario échoue, et c'est le comportement attendu : le rapport pointe l'étape et la donnée en cause. C'est précisément pour ça qu'on évite de faire reposer une campagne entière sur un compte unique.
Oui. C’est un usage récurrent chez certains clients : nous générons les jeux de données destinés à la mise en production, en suivant les règles métier que vous définissez, au volume et à la fréquence demandés. Le moteur exécute la saisie comme le ferait une équipe, mais sans l’erreur de recopie.
La mécanique est proche, l’intention diffère. Un outil de RPA est conçu pour exécuter des processus métier de bout en bout, avec des connecteurs vers les progiciels. Nous restons sur les interfaces web et mobiles, sur des volumes cadrés, et toujours avec la trace de ce qui a été fait.
Une démo de 30 minutes sur votre propre application. Vous verrez un même scénario rejoué sur plusieurs jeux de données.