A spec tells you what the team meant to build. A bug report tells you what a real person did with it. I read the second one first.
The spec is a plan, the report is evidence
Specs are written before the code exists. They describe the path the author imagined. A bug report is written after someone left that path, usually by accident, and it records the exact step where the product stopped agreeing with them. The triage notes often say more than the ticket title.
- What the user expected, in their own words
- The last step that worked
- What else changed that day: a deploy, a flag, a price update
The path nobody tested is usually the one somebody took.
Turning a report into a test
Once I know the step, I write the test before reading the fix. If cart-count still passes on the broken build, I have not understood the bug yet.
test('guest keeps cart after login', async ({ page }) => {
await addToCart(page, 'SKU-1042');
await login(page, guest);
await expect(page.getByTestId('cart-count')).toHaveText('1');
});When the report is wrong
Sometimes the report describes a symptom two steps away from the cause. That is still useful. It tells you where the user was looking when things broke.