Le test améliore le processus.
Les tests montrent comment un processus se déroule réellement. Si un cas de test s’écarte du modèle, TAOM le détecte – et demande : oublié dans le processus, une variante ou seulement un chemin de test ?
La réponse crée une nouvelle version du modèle. Le responsable du processus (GPO) la valide. Ce n’est qu’alors qu’elle s’applique – et la formation et la documentation en sont informées.
Les exécutions de test produisent automatiquement des modèles de processus BPMN nouveaux ou optimisés.
Parcourez en cliquant : du modèle validé au modèle adapté, en passant par le déroulement de test modifié – en brouillon jusqu’à la validation du responsable du processus.
De l’exécution de test à un meilleur modèle
Qui teste trouve des lacunes dans le processus. Jusqu’ici, elles finissent dans un procès-verbal, dans une réunion et peut-être un jour dans le modèle. Dans TAOM, elles deviennent directement une proposition à la bonne étape.
Ce que TAOM remarque de lui-même
Personne n’a besoin de signaler un écart. Le testeur peut en plus indiquer à la main « ne correspond pas au modèle ».
| Déclencheur dans le test | Comment TAOM le détecte |
|---|---|
| Cas de test E2E : station insérée | Station sans étape ou sans liaison dans le chemin du modèle |
| Cas de test E2E : ordre modifié | L’ordre des stations diffère du chemin du modèle |
| Cas de test E2E : station supprimée | Étape obligatoire du modèle sans station |
| Étape supprimée ou déplacée dans le modèle | L’identifiant du cas de test ne pointe vers rien |
| Exécution de test « réussie avec écarts » | Remarque du testeur à la station |
| Import Excel avec de nouveaux cas de test | Lignes sans identifiant d’une étape du modèle |
Si l’écart se trouve dans un modèle lié, TAOM propose l’emplacement dans celui-ci – le brouillon est créé dans le modèle concerné.
Une question, trois réponses
L’étape a-t-elle été oubliée dans le processus, ne s’applique-t-elle que sous condition, ou n’appartient-elle pas du tout au processus ? Seul celui qui connaît le processus le sait. TAOM pose la question – et met en œuvre la réponse.
Oublié dans le processus
L’étape en fait toujours partie.
- Nouvelle version brouillon avec l’étape au bon endroit
- Nom, rôle et système proviennent du cas de test
- Rôle conforme à la matrice RACI
Variante de processus
L’étape ne s’applique que sous condition.
- Au choix pour chaque cas : une branche avec condition dans le même modèle
- ou un modèle de variante distinct avec renvoi
- Les deux en version brouillon
Seulement un chemin de test
Préparation du test ou contournement, pas une partie du processus.
- Le modèle reste inchangé
- Le cas de test est marqué
- Traçable dans le reporting
Les simples vérificateurs disposant de la licence complémentaire peuvent aussi décider – il ne s’agit que d’un brouillon. Seuls peuvent valider ceux qui en ont le droit selon le pilotage des champs .
Nouvelle version – et qui la valide
Chaque version du modèle a un statut. C’est toujours la dernière version validée qui s’applique. Les exécutions de test, la preuve de test et le manuel utilisateur indiquent la version et son statut.
Piloté par le pilotage des champs
Le client définit lui-même qui peut valider – avec les rôles de l’ organisation du projet.
- Champ « Valider la version du modèle » – modèle : GPO et administrateur
- Règle « Quatre yeux pour les versions de modèle » : imposer (modèle) ou seulement journaliser – alors avec la mention « validé sans deuxième personne »
- Sans GPO sur le modèle, un autre rôle disposant du droit de validation valide ; le modèle invite à désigner un GPO
La validation et le rejet figurent avec l’identifiant de la personne, l’horodatage et le commentaire dans l’historique et dans le sceau d’origine.
Excel : cas de test dans les deux sens
Les métiers préfèrent souvent rédiger leurs cas de test dans Excel. C’est possible – sans perdre le lien avec le processus.
Le plan de test devient un modèle
S’il n’existe encore aucun modèle pour les cas de test, il est créé à partir du plan de test – au niveau du modèle d’entreprise que l’utilisateur attribue.
Avec connexion IA
Webuser, Webuser Pro, Enterprise avec connexion agent.
- L’ agent IA construit le modèle comme d’habitude
- Avec le signe IA de l’UE (origine IA)
- Brouillon – le GPO valide (Human in the Loop)
Sans connexion IA
Par exemple Enterprise sans connexion agent.
- Une forme par étape de test, un couloir par rôle
- L’éditeur relie les formes dans l’ordre des lignes Excel
- L’utilisateur complète branches, événements et systèmes – puis validation par le GPO
Après la validation, tout le monde est informé
Un processus modifié exige souvent une formation et une documentation modifiées. TAOM le déclenche.
Ce que coûte un écart aujourd’hui – un calcul modèle
Sans outil, un écart est recherché, discuté, remodélisé, validé et transmis – par plusieurs personnes.
Calcul modèle, pas une mesure. Tous les temps de ce tableau sont des hypothèses pour un cas type. Ils montrent le bénéfice possible – pas une amélioration mesurée. Vous saisissez l’effort réel dans TAOM comme temps réels dans les temps de projet ; la valeur mesurée figure alors à côté de l’hypothèse.
| Activité par écart | aujourd’hui (hypothèse) | avec TAOM (hypothèse) | pourquoi |
|---|---|---|---|
| Extraire l’écart des protocoles de test | 0,5 h | 0 h | TAOM le détecte lui-même |
| Se concerter : oublié, variante ou chemin de test (3 personnes × 1 h) | 3,0 h | 1,0 h | Le cas est disponible avec le cas de test et le modèle ; deux personnes suffisent généralement |
| Mettre le modèle à jour | 1,0 h | 0,1 h | Le brouillon est créé à partir du cas de test |
| Obtenir et documenter la validation | 1,0 h | 0,1 h | Validation sur le modèle, mention automatique |
| Déclencher formation et documentation | 0,5 h | 0 h | Ticket ou carte créés automatiquement |
| Par écart | 6,0 h | 1,2 h | environ 80 % de moins |
| 30 écarts dans un cycle de test | 180 h | 36 h | environ 144 heures-personnes de moins |
Calcul modèle avec des hypothèses, pas une mesure. Cela dépend de la qualité de la description préalable du processus.
Réponses brèves
Le testeur doit-il signaler les écarts ?
Non. TAOM compare le cas de test avec le chemin du modèle. Indiquer à la main « ne correspond pas au modèle » reste possible.
Un testeur modifie-t-il ainsi le modèle ?
Non. Seul un brouillon est créé. Il ne devient valable qu’avec la validation du GPO ou d’un autre rôle disposant du droit de validation.
Que se passe-t-il en cas de rejet ?
La version reçoit le statut rejeté et reste visible dans l’historique. Cela vaut aussi pour un modèle ou une variante issus de la réingénierie. Le cas de test reste ouvert avec « rejeté – adapter le cas de test ».
Le créateur peut-il valider lui-même ?
Pas dans le modèle (principe des quatre yeux). L’administrateur peut régler la règle « Quatre yeux pour les versions de modèle » sur « seulement journaliser » – « validé sans deuxième personne » figure alors dans l’historique et le sceau d’origine.
De quelle licence ai-je besoin ?
La réingénierie fait partie de la licence complémentaire Vérification et test – voir matrice des fonctionnalités.
Puis-je réimporter des résultats de test via Excel ?
Non. L’exécution et le résultat restent dans TAOM, afin que capture d’écran, preuve et principe des quatre yeux concordent.
Tester et améliorer d’un seul geste.
La réingénierie de processus fait partie de la licence complémentaire Vérification et test – par personne qui vérifie, durée propre, résiliable séparément.