A6 — Montées de version & non-régression

🆕 Évolution proposée

Statut : 🟢 modèle prêt à spécifier · 🟠 règles de présélection à cadrer (Q19).Prérequis technique : A3 — les deux partagent la même brique. 📖 Le sujet expliqué de fond (quoi, pourquoi, pièges du marché, exemple concret) : 27.3 — Non-régression & montées de version.

En une phrase

À chaque montée de version de l'ERP, il faut rejouer une partie des tests pour vérifier que rien n'a cassé. Aujourd'hui l'outil ne sait ni quoi rejouer, ni comparer avec la fois précédente.

Constat

La campagne porte déjà une version ERP et un type (SIT / SAT / ORT / Smoke). Mais trois choses manquent :

• Aucun lien entre deux campagnes : impossible d'exprimer « cette campagne rejoue le périmètre de celle-là ». Chaque campagne est un îlot.
• Aucune notion de « flux à retester » : rien ne distingue un test à rejouer systématiquement d'un test joué une fois pour toutes.
• Une campagne reprend tout le plan de test, sans possibilité de la restreindre à un sous-ensemble de non-régression.

Conséquence : une campagne de montée de version se prépare aujourd'hui en dehors de l'outil, et « qu'est-ce qui a cassé depuis la dernière fois ? » se répond en comparant deux exports Excel à la main.

Références au code v1. campaigns porte version_erp, type ∈ {SIT, SAT, ORT, Smoke} et statut ∈ {Planifiée, En cours, Terminée, Archivée} (001_initial_schema.sql). Pas de parentCampaignId ; activate_campaign copie tout l'arbre du projet sans filtre.

Campagne dédiée ou partie dédiée du référentiel ?

Le marché est unanime : campagne (cycle / plan / run) dédiée, rattachée à une version, dont le périmètre est une sélection dans un référentiel stable.

• TestRail rattache les runs à un milestone de release.
• Xray crée un Test Plan par version / sprint, réutilisant les tests de régression.
• Zephyr Scale associe un test cycle à une version / release.

Aucun des trois n'a de « section non-régression » séparée du reste du référentiel — cela dupliquerait la maintenance des cas de test.

➡️ Recommandation : campagne dédiée, pas de partie dédiée.

Modèle proposé

Deux informations à ajouter

Sur	Information	À quoi ça sert
La campagne	c'est une campagne de non-régression · la version ERP visée (obligatoire) · la campagne de référence qu'elle rejoue	Relier les campagnes entre elles et permettre le comparatif
Le flux (au plan de test)	appartient au noyau de non-régression	Marquer une fois pour toutes les tests à rejouer systématiquement, sans dupliquer le flux

• Sur campaigns : isRegression: boolean (ou type: 'NR'), targetVersion (obligatoire si isRegression), previousCampaignId.
• Sur tests : regressionCore: boolean. Équivalent du dossier / Test Set « regression » d'Xray, sans duplication de cas.

Assistant de constitution du périmètre

À la création d'une campagne de non-régression, quatre présélections, toutes calculables depuis l'existant :

1. flux KO lors de la campagne de référence ;
2. flux portant un CRIM impacté par la montée de version ;
3. flux marqués regressionCore ;
4. flux modifiés au référentiel depuis la campagne de référence (updatedAt > date de référence).

L'assistant propose une sélection ; l'utilisateur ajuste avant de valider. Il ne décide jamais seul du périmètre.

🔗 A3 est un prérequis d'A6. Les deux demandes reposent sur le même mécanisme — « ajouter une sélection de flux à une campagne ». Elles doivent être séquencées dans cet ordre, sinon le même travail est fait deux fois.

Le résultat de l'assistant alimente exactement la mutation campaigns.addTestsFromReferentiel(campaignId, testIds[]) d'A3.

Écran comparatif « campagne N vs N-1 »

Les flux passés de OK → KO sont les régressions détectées.

C'est la valeur métier réelle d'une campagne de montée de version, et elle est aujourd'hui totalement absente : en v1, comparer deux campagnes suppose d'exporter deux classeurs Excel et de les rapprocher à la main.

Impact

Léger : quatre informations supplémentaires, aucune structure nouvelle. Le comparatif N vs N-1 ne stocke rien — il lit les résultats des deux campagnes et les met en regard.

Trois champs sur campaigns, un booléen sur tests. Le comparatif est une query qui rapproche les etapeResults de deux campaignId (modèle A3bis) — pas une collection.

Droits

Création d'une campagne de non-régression et constitution du périmètre : admin + consultant. Lecture du comparatif : tous les rôles authentifiés.

Aligné marché

TestRail (milestone + baselines), Xray (Test Plan par version), Zephyr Scale (test cycle rattaché à une version Jira). Voir Analyse du marché.

À trancher — Q19

• Qui définit le noyau regressionCore, et sur quel critère ? (criticité métier ? fréquence d'anomalie ? décision du chef de projet ?)
• D'où vient l'information « CRIM impacté par la montée de version » ? Note de version de l'éditeur ERP ? Saisie manuelle ? Sans réponse, la présélection 2 n'est pas implémentable.
• Le comparatif automatique N vs N-1 est-il attendu comme livrable, ou seulement comme écran ?