Passer au contenu principal
Vous allez préparer un petit plan avec trois cas de test, puis utiliser une boutique fictive pour l’atelier exploratoire. Ce jeu est réservé à l’apprentissage : ses résultats ne décrivent pas la qualité d’un produit réel.

​
Avant de commencer

  • Utilisez un projet Azure DevOps de démonstration où vous pouvez créer des work items, des plans et des cas de test.
  • Vérifiez l’installation et les prérequis. Le droit de lire un rapport ne donne pas automatiquement le droit de préparer ce jeu.
  • Prévoyez une seule configuration pour les trois cas. Son nom dépend de votre projet.
  • Si vous avez déjà un petit plan avec des résultats variés, vous pouvez l’utiliser : comparez les proportions, pas les identifiants de nos captures.

​
1. Créer le plan et ses cas

Dans Test Plans, ouvrez la liste de tous les plans, puis New Test Plan. Nommez-le TP-DOC — Boutique démo. Conservez une aire et une itération de votre projet de démonstration. Sous la suite racine du même nom, créez une sous-suite statique nommée TP-DOC — Parcours de commande. Sélectionnez cette sous-suite, ouvrez Define, puis New Test Case. Créez ces trois cas avec une étape chacun : À vérifier : la sous-suite TP-DOC — Parcours de commande contient trois cas distincts. Dans Execute, cette même sous-suite affiche trois points de test si chacun possède une seule configuration. Si vous avez déjà créé les trois cas dans la racine, ajoutez ces cas existants à la sous-suite, sans recréer leurs work items. Les nouveaux points de cette sous-suite ont leurs propres résultats : renseignez leurs états à l’étape suivante, même si les cas ont déjà été exécutés ailleurs.
Pour TestPulse 2.73.1, placez les cas dans cette sous-suite plutôt qu’uniquement à la racine. Sur un plan ne contenant que sa racine, le rapport peut se rabattre sur les runs existants : un cas non exécuté peut alors manquer et le taux d’exécution paraître complet. La sous-suite permet de sélectionner et de contrôler les trois points de l’exercice.
Vous pouvez aussi télécharger le kit de démonstration ZIP, puis le décompresser : il contient le fichier facultatif tp-doc-test-cases-fr.csv avec les trois cas. Utilisez l’import natif d’Azure Test Plans ou, depuis TestPulse 2.74.0, Import → Cas de test CSV : sélectionnez les trois cas sans classement, créez un groupe et associez-le à la suite TP-DOC — Parcours de commande. Le choix Résultats automatisés XML ne crée pas de cas. Adaptez les champs éventuellement exigés par votre processus ; gardez les identifiants vides pour créer de nouveaux cas. Une nouvelle importation avec des identifiants vides crée de nouveaux work items. Voir le tutoriel CSV.

​
2. Préparer les résultats pédagogiques

Téléchargez le kit de démonstration ZIP depuis le dépôt public de la documentation, si vous ne l’avez pas déjà fait. Sous Windows, faites un clic droit sur le ZIP, puis Extraire tout. Dans le dossier extrait, ouvrez boutique-demo.html dans votre navigateur. La boutique fonctionne hors ligne, sans installation, serveur ni paiement. Aucun renseignement personnel n’est nécessaire.
  1. Cliquez sur Ajouter au panier : un article et 20 EUR apparaissent. Le cas TP-DOC-01 est Passed.
  2. Laissez l’adresse vide, puis cliquez sur Valider la commande : la boutique accepte la commande. C’est l’anomalie volontaire de l’exercice. Le cas TP-DOC-02 est Failed.
  3. Ne jouez pas le cas TP-DOC-03 ; conservez-le non exécuté.
Enregistrez ces résultats dans Execute d’Azure Test Plans, en gardant TP-DOC — Parcours de commande sélectionnée, avec le menu de résultat de chaque ligne ou le test runner. Si vous utilisez le marquage direct, il s’agit de statuts préparés pour l’atelier ; ne les présentez pas comme des exécutions automatiques. État de départ attendu : 1 Passed, 1 Failed, 1 non exécuté. Les tests terminés sont 2 sur 3 ; le taux de réussite des tests terminés est 1 sur 2, soit 50 %. Le troisième test n’est pas un succès.
Une suite statique suffit pour ces premiers ateliers. Sans exigence reliée, certaines mesures de couverture seront absentes ou peu représentatives : c’est une limite du périmètre, pas une preuve d’absence de risque. L’atelier NO-GO vous apprend à la repérer.

​
3. Préparer le support de la session exploratoire

Créez une User Story intitulée TP-DOC — Sécuriser la livraison (ou le type d’exigence de votre processus). Description à recopier :
En tant qu’acheteur, je dois renseigner une adresse avant de confirmer ma commande. Une adresse vide doit empêcher la validation et produire un message explicite. Scénario fictif utilisé pour la documentation TestPulse.
L’atelier Explore ajoutera des notes, une preuve et un bug associé à ce work item. Notez son identifiant ; chaque projet lui attribue le sien.

​
Si votre résultat diffère

  • Plus de trois points : vérifiez les configurations et les doublons de cas. Ne comparez pas les chiffres tant que le périmètre diffère.
  • Aucun droit de création : demandez à l’administrateur de préparer le jeu ; les tutoriels de lecture restent utilisables avec un plan existant.
  • Trois résultats non exécutés dans TestPulse : assurez-vous d’avoir enregistré les résultats ADO, puis régénérez le rapport.
  • Deux cas et 100 % d’exécution malgré le troisième non exécuté : vérifiez que les trois cas sont dans TP-DOC — Parcours de commande, que cette sous-suite est sélectionnée dans TestPulse et que ses propres points portent les résultats attendus. Un plan limité à sa racine peut produire ce résultat incomplet en 2.73.1.
  • Pas de User Story dans votre processus : utilisez le type d’exigence disponible et relevez les différences de vocabulaire.
  • La boutique n’est plus dans son état initial : cliquez sur Recommencer. Les résultats Azure DevOps, eux, restent enregistrés.

​
Prêt pour les ateliers

Premier rapport

Générer, comprendre et exporter.

Comprendre un NO-GO

Expliquer le verdict à partir des preuves.

Session exploratoire

Documenter l’anomalie de livraison.