A10 — Assignation d'exécution & configurations

🆕 Évolution proposée — issue de l'inventaire marché (C24, C25, C29)

Statut : 🟢 prêt à spécifier.Prérequis du volet « charge par testeur » d'A1.

A10.1 Assignation d'exécution (C24)

Constat

Rien, dans le modèle actuel, n'exprime « qui doit exécuter quoi ». La seule information nominative enregistrée est qui a exécuté, constatée après coup dans le journal.

Trois conséquences :

1. La répartition du travail se fait hors de l'outil (réunion, Excel, message). L'outil enregistre le résultat, pas le plan.
2. Un testeur qui ouvre l'application ne sait pas ce qu'on attend de lui : il n'y a pas de « mes flux à jouer ».
3. Le rapport de charge d'A1 mesure du réalisé, jamais du prévu — il ne peut donc pas répondre à « qui est en retard ? ».

Proposition

• L'assignation porte sur le flux dans une campagne, pas sur le flux du plan de test : le même flux peut être confié à des personnes différentes d'une campagne à l'autre.
• Assignation en masse depuis l'écran de constitution du périmètre (sélection multiple → « Assigner à … »).

Champ assignedTo (nullable) sur l'association campaignTests (A3bis).

- Écran / filtre **« Mes flux à exécuter »** dans la campagne active. - Le tableau de bord gagne l'axe **prévu vs réalisé par testeur**, qui est le véritable rapport *User (Test Execution) Workload* de TestRail.

Droits

Assigner : admin + consultant. Un testeur voit ses propres assignations et peut exécuter tout flux du périmètre — l'assignation organise, elle ne verrouille pas (un testeur ne doit jamais être bloqué parce que le chef de projet a oublié de l'assigner).

A10.2 Configurations d'exécution (C25)

Constat

L'environnement est aujourd'hui un champ plat au niveau de la campagne (CFG / UAT / TRN / PRD — Q14). Il ne permet pas d'exprimer qu'un même périmètre est joué plusieurs fois dans des contextes différents : deux sociétés, deux environnements, deux versions ERP.

En pratique, cela oblige aujourd'hui à créer une campagne par combinaison, ce qui duplique le périmètre et rend l'avancement global illisible.

Proposition

• Des groupes de valeurs nommés : groupe Environnement = CFG, UAT, PRD ; groupe Société = FR01, BE02.
• Une campagne déclare quelles combinaisons elle exécute — toujours choisies explicitement, jamais toutes les combinaisons possibles par défaut.
• Un résultat est désormais rattaché à sa combinaison : cette étape, dans cette campagne, sur cet environnement, pour cette société.
• La Synthèse affiche l'avancement par combinaison et consolidé.

⚠️ Attention à la combinatoire — c'est le vrai risque de cette évolution. 3 environnements × 4 sociétés × 400 flux × 8 étapes = 38 400 résultats à saisir. Ce n'est pas un problème technique avant d'être un problème humain : personne ne joue 38 400 étapes. La sélection des combinaisons doit rester un geste réfléchi, et l'écran doit afficher le volume induit avant validation.

• Collection configurations : groupes de valeurs nommés.
• etapeResults gagne un configurationId ; la clé d'unicité devient (campaignId, etapeId, datasetId, configurationId).
• Le volume ci-dessus (38 400) dépasse la limite de 32 000 documents lus par transaction. Deux garde-fous obligatoires : (1) sélection explicite des combinaisons, jamais de produit cartésien automatique ; (2) toute lecture consolidée paginée, avancement pré-agrégé (A1). Voir Exigences non-fonctionnelles § 14.1.

Relation avec A9

Configuration ≠ jeu de données, et la distinction doit rester nette :

	Jeu de données (A9)	Configuration (A10)
Porte sur	le contenu du test (valeurs saisies)	le contexte d'exécution
Exemple	« profil = Acheteur, montant = 1 500 € »	« environnement = UAT, société = FR01 »
Défini au niveau	du flux	de la campagne

Les deux se combinent — d'où la clé d'unicité à quatre composantes ci-dessus. Si un seul des deux est retenu, c'est la configuration : elle répond au besoin le plus courant en recette ERP (mêmes tests, plusieurs environnements).

A10.3 Temps passé (C29) — option

Enregistrer la durée d'exécution de chaque étape, saisie ou chronométrée. Alimente un indicateur de charge réelle et l'estimation des campagnes suivantes.

Non prioritaire : utile en pilotage de charge, sans valeur pour la qualité du dossier de recette. À retenir seulement si le client suit un budget de jours-homme de recette.

Aligné marché

• TestRail — configuration groups pour les tests multi-plateformes / multi-environnements ; les test plans planifient plusieurs runs, assignent des testeurs et enregistrent build, environnement et jalon.
• Zephyr Scale — les test cycles sont assignables à des testeurs et à un environnement.

À trancher

• Les configurations sont-elles un besoin réel chez ce client, ou l'environnement plat suffit-il ? → relance de Q14, désormais chiffrante (elle détermine la combinatoire, donc le dimensionnement).
• L'assignation est-elle indicative (recommandation : oui) ou contraignante (un testeur ne peut exécuter que ce qui lui est assigné) ?
• Le temps passé (A10.3) entre-t-il au périmètre ?