Le compte rendu : bug produit ou bug de test

Trois verdicts, trois propriétaires

• Bug d'app → un développeur corrige le produit.
• Bug de test → vous corrigez le test, et laissez une ligne dans la PR sur le motif pour que la revue attrape le prochain.
• Environnement → celui qui possède le pipeline.

Nommer le compartiment, avec preuve, est le livrable. « Ça échoue parfois » n'est pas un verdict.

Ce dont un développeur a besoin

• Étapes et données exactes — quel SKU, quel coupon, quel compte. Pas « un utilisateur valide ».
• Attendu vs réel — une ligne mesurable chacun.
• Preuve — la trace, la capture d'écran ou le corps de réponse. Attaché, pas décrit.
• Environnement — navigateur, CI ou local, commit SHA.
• Fréquence — 7/50, pas « parfois ».

Title: Cart total drops the discount when the cart is edited
       after a coupon is applied

Steps: 1. Add SKU-104 (qty 1)   2. Apply SAVE10 — total $35.99
       3. Change qty to 2       4. Total shows $79.98 (discount gone)

Expected: $71.98 (10% held)     Actual: $79.98
Evidence: trace.zip attached — step 3's PUT /cart responds 200
          with discount:null    Commit: a8d3c42, chromium headless
Frequency: 10/10 on CI and locally

Pourquoi « impossible à reproduire » arrive

Ça arrive quand vous remettez une conclusion au lieu d'une preuve. Des étapes, des données, une trace et une fréquence ne laissent rien à rejeter.

Basé sur la façon dont les rapports d'échec sont traités — et rejetés — dans les vraies équipes