Skip to main content
Azure DevOps sait assigner des testeurs au niveau d’une suite, mais l’action ne cascade pas vers les suites enfants. Sur un plan de 172 suites portant 296 test points, réaffecter un testeur impose d’ouvrir jusqu’à 172 suites à la main. L’import CSV et la grille d’édition en masse n’aident pas davantage : ils modifient des champs du work item Cas de test, alors que le testeur et la configuration appartiennent au test point. Aucun contournement natif n’existe. L’onglet Réaffectation en masse comble ce trou. Il parcourt le plan, montre ce qui s’y trouve réellement, et applique le changement en une passe.

​
Cinq étapes

1

Périmètre

Choisissez un plan, ou jusqu’à dix à la fois. Un champ de recherche filtre la liste déjà chargée, sur le nom du plan, l’itération ou un identifiant exact. Le filtre masque, il ne désélectionne jamais — un plan sélectionné que la recherche cache reste sélectionné, et le compteur continue d’afficher le total réel.
2

Inventaire

Testeurs et configurations côte à côte, triés par volume. Chaque ligne indique son nombre de points, combien d’entre eux portent déjà un résultat d’exécution, et sa part du périmètre. Une configuration pesant moins de 2 % des points est marquée résiduelle — le plus souvent un héritage à normaliser. Non assigné est une ligne à part entière, pas une absence.Rien n’est mis en cache. L’inventaire est reconstruit à chaque analyse et porte l’horodatage de sa lecture, parce qu’agir sur une vue périmée est le vrai risque ici.
3

Opération

Choisissez quoi réaffecter — testeur ou configuration — puis l’un des trois modes :
  • Remplacer partout — une ou plusieurs valeurs actuelles remplacées par une autre
  • Tout le périmètre — chaque point ne portant pas déjà la valeur cible
  • Une suite et ses enfants — récursivement, à n’importe quelle profondeur
Les suites s’affichent en arborescence, avec repli et dépli, et une recherche par nom qui garde un résultat visible avec ses ancêtres. Une suite ne portant aucun point apparaît quand même comme branche, pour que ses descendants restent atteignables.
4

Récapitulatif

Points concernés, suites touchées, points déjà exécutés, cas ignorés et nombre d’appels API estimé — plus l’opération en langage clair et l’endpoint exact qui sera appelé. Le bouton d’application reste désactivé tant que l’impact est nul.C’est ici que vous choisissez le sort des points portant déjà un résultat, et que vous pouvez exporter l’état antérieur en CSV.
5

Résultat

Combien de points ont été réaffectés sur combien, la durée, et chaque échec avec son code HTTP et une cause en clair. Un bouton de reprise ne rejoue que les échecs.

​
Testeur et configuration ne sont pas la même opération

C’est le passage à lire deux fois. Les présenter comme un seul mécanisme serait la manière la plus simple de faire perdre son historique d’exécution à quelqu’un ; l’interface les tient donc visiblement séparés.
L’opération est irréversible. Azure DevOps ne propose aucune annulation et TestPulse ne conserve aucun état antérieur — une décision délibérée, énoncée à l’écran au-dessus du bouton d’application. L’export CSV de l’état antérieur est la trace à garder. Voir Lecture seule par défaut.

​
Deux comportements qui surprennent

Un cas de test portant déjà la configuration cible est ignoré, jamais fusionné. Le fusionner supprimerait l’une de ses affectations. Les cas ignorés sont listés avec leur suite et leur identifiant, et exportables en CSV. Un échec partiel est un résultat valide, pas un état corrompu. Rien n’est annulé : les points déjà réaffectés le restent. C’est voulu — une annulation supposerait un état antérieur que TestPulse ne conserve délibérément pas.

​
Permissions

La réaffectation en masse utilise le scope vso.test_write que le Coverage Builder déclare déjà — aucune nouvelle permission n’est demandée. Un 403 sur une suite est presque toujours une ACL de chemin d’itération plutôt qu’un scope manquant ; le rapport nomme la suite pour que vous puissiez vérifier.

​
À lire ensuite

Lecture seule par défaut

Où TestPulse écrit, et ce qu’il ne touche jamais.

Permissions & scopes

Chaque scope et ce qu’il alimente exactement.