Turn “add a regression test” into a specific outcome

"Add a regression test" is an easy action item to write and a difficult one to finish if it lacks a concrete expectation. A month later, someone picks it up with no memory of the incident, writes something that checks the page loads, and closes the ticket.

Capture the detail while the incident is still understood. Compare these two:

Add a regression test for the coupon bug.

With a cart over $100 and the SPRING20 coupon, the checkout total should be 20% lower before payment. On 12 March it showed "Discount applied" and charged full price. Use the seeded test product and a fresh account.

The second one names the starting state, the action and what should have happened. Anyone can pick it up.

Before you close the action item

• Choose the right layer. Decide which layer can verify the cause most directly, and whether a browser test is also needed to protect the whole journey. A pricing bug may need a unit test and a browser regression test for different reasons.
• Give it an owner and repeatable test data. Otherwise it will be flaky or ignored within a few weeks.
• See it fail. Run the test against the broken behavior and confirm it fails, then confirm it passes after the fix. A test that has never failed hasn't shown you much.
• Read the assertion. A new test file existing isn't the same as the problem being covered.

If it's a browser flow, you can write that second paragraph almost directly into Zerocheck's web app. It drafts and runs the scenario, and you review the steps and the real outcome before saving it for future releases. Zerocheck won't tell you when production breaks, because it isn't a monitoring system. Its job here is to make that one expectation repeatable.