SaveLink ajoute à SaveTest un registre des exigences, la comparaison de branches et la planification

SaveLink a publié une mise à jour de SaveTest, sa plateforme de gestion des tests. L'annonce, parue le 8 octobre 2026, met en avant trois fonctions clés : un registre des exigences avec matrice de traçabilité, la comparaison de branches et la planification des campagnes de tests. La partie accessible du document ne contient ni métriques de performance, ni nombre de clients, ni tarifs. La version ne peut donc être évaluée que sur son jeu de fonctionnalités et sur les besoins des équipes QA qu'elle couvre.

Ce que contient la version

Le principal changement est le lien entre exigences et tests. Jusqu'ici, ces systèmes stockaient le plus souvent les cas de test et les résultats d'exécution, tandis que les exigences vivaient dans un outil de suivi de tickets ou dans des documents. Désormais, le registre des exigences se trouve dans SaveTest, et la matrice indique quelles exigences sont couvertes par des tests et lesquelles restent sans vérification.

Contenu de la mise à jour, d'après la description publiée :

• registre des exigences intégré à la plateforme ;
• matrice de traçabilité : lien entre exigence, cas de test et résultat ;
• comparaison de branches ;
• planification des campagnes de tests ;
• date de l'annonce : 8 octobre 2026, source : CNews.

À quoi sert la traçabilité

La matrice de traçabilité répond à la question que les responsables QA entendent avant chaque livraison : qu'a-t-on vérifié exactement, et que reste-t-il non couvert ? Lorsqu'une exigence est liée à des cas de test et à leurs derniers résultats, la lacune saute aux yeux, sans rapprochement manuel de tableaux. Pour les projets soumis à un audit, à des exigences réglementaires ou à un cycle de vie produit long, cette transparence est particulièrement précieuse : elle permet de montrer aux auditeurs comment chaque exigence est démontrée par un test.

L'effet inverse existe aussi. Les cas de test sans lien avec une exigence sont faciles à repérer. On les garde dans la suite par habitude, et ils allongent les campagnes sans protéger rien de précis.

Branches et planification

La comparaison de branches répond au problème du développement en parallèle. Quand un produit évolue sur plusieurs lignes, par exemple une branche principale, une branche de release et une branche pour une fonctionnalité majeure, les suites de tests divergent. L'outil de comparaison permet de voir ce qui différencie les versions et d'éviter de perdre des modifications lors d'une fusion. Les détails d'implémentation ne figurent pas dans l'extrait accessible : on ignore si la comparaison porte uniquement sur les cas de test, ou aussi sur les exigences et les résultats.

La planification des exécutions est une fonction plus terre à terre, mais c'est elle qui rythme le travail au quotidien. Calendrier des lancements, répartition des tests entre testeurs et builds, visibilité sur la charge de l'équipe : tout cela vit généralement dans des tableurs et des messageries. Le transfert dans la plateforme réduit le risque d'oublier une campagne de non-régression ou de la lancer sur le mauvais build.

Marché et contexte

SaveTest arrive sur un marché dense. TestRail, Qase, Allure TestOps et Test IT sont déjà là, et chacun propose sa propre version de la traçabilité et de la planification. SaveTest devra donc se distinguer par la profondeur de ses intégrations et le confort de gestion des branches. Alors que l'IA se diffuse massivement dans le test, par exemple pour générer des cas de test à partir des exigences, un autre point frappe : la partie accessible de l'annonce ne dit rien des fonctions d'IA. Cette version porte sur le processus et la discipline, pas sur la génération automatique.

Que vérifier avant de l'adopter

Les équipes qui envisagent la mise à jour gagneraient à clarifier plusieurs points auprès de l'éditeur :

• comment les exigences arrivent dans le registre : import depuis un outil de suivi de tickets, API ou saisie manuelle ;
• s'il est possible de synchroniser les statuts des exigences avec les tickets dans Jira ou un outil équivalent ;
• ce qui est précisément comparé lors du rapprochement de branches et comment les conflits sont résolus ;
• s'il existe des rapports de couverture exploitables pour un audit ;
• quelles options de déploiement sont disponibles : cloud ou infrastructure propre.

Pour un pilote, il suffit de prendre un produit avec deux branches actives et de mesurer le temps nécessaire pour préparer un rapport de couverture avant et après la bascule. Si la matrice se construit automatiquement et correspond à la réalité, la fonction est rentabilisée. Si les liens doivent être maintenus à la main, il n'y aura aucun gain.