QA Engineer

Test cases are generated from the acceptance criteria in the repo. They arrive in your test management system linked to the backlog story, with steps derived directly from the acceptance criteria. You don't create these — they're ready when you arrive.

Create test cases in project PROJ from the Notification Banner
acceptance criteria in docs/work/<feature>/requirements.md.
Link them to PROJ-456.

The agent creates test management cases — for example, PROJ-TC-201 through PROJ-TC-204 — each with steps derived from the acceptance criteria, linked to the backlog story. You can also create cases manually; the key is that each case gets a PROJ-TC-XXX identifier that threads through the entire workflow.

You add: Awareness of what's coming. If you're involved early, you can flag acceptance criteria that won't produce useful test cases before they're generated.

When the design team generates a component from Figma, the agent also generates a .spec.ts file with Playwright tests tagged to the test case keys. Here's what a generated stub looks like:

test.describe('NotificationBanner', () => {
  test('PROJ-TC-201: should display info variant with message', async ({ page }) => {
    await page.goto('http://localhost:6006/?path=/story/notificationbanner--info');
    await expect(page.getByRole('alert')).toBeVisible();
    await expect(page.getByText('Your changes have been saved')).toBeVisible();
  });

  test('PROJ-TC-202: should display error variant with error message', async ({ page }) => {
    await page.goto('http://localhost:6006/?path=/story/notificationbanner--error');
    await expect(page.getByRole('alert')).toHaveAttribute('data-variant', 'error');
    await expect(page.getByText('Something went wrong')).toBeVisible();
  });

  test('PROJ-TC-203: should dismiss when dismiss button clicked', async ({ page }) => {
    await page.goto('http://localhost:6006/?path=/story/notificationbanner--dismissable');
    await page.getByRole('button', { name: 'Dismiss notification' }).click();
    await expect(page.getByRole('alert')).not.toBeVisible();
  });
});

When reviewing a generated stub, check four things: selectors (are they targeting the right elements using accessible roles and labels?), assertions (do they actually verify the acceptance criterion, or are they too shallow?), story URLs (do the Storybook story paths match the actual story names?), and case key mapping (does each test title start with the correct PROJ-TC-XXX prefix?).

Then add what the agent didn't generate — this is where your expertise matters most. The agent covers the happy path from the acceptance criteria. You add edge cases, boundary conditions, interaction sequences, and error states:

// Edge case — the agent wouldn't generate this
test('PROJ-TC-205: should truncate messages longer than 120 characters', async ({ page }) => {
  await page.goto('http://localhost:6006/?path=/story/notificationbanner--long-message');
  const alert = page.getByRole('alert');
  await expect(alert).toBeVisible();
  const text = await alert.textContent();
  expect(text!.length).toBeLessThanOrEqual(123); // 120 chars + "..."
});

Key principle: Review generated tests before running them. A passing test with a bad assertion is worse than a failing test — it gives false confidence. Verify selectors, check assertions, then add your edge cases.

You add: Coverage judgment. Does this test actually validate the requirement, or does it just pass mechanically? Is anything missing?

Start Storybook, then run the tests. You have two modes:

Interactive mode (agent + Playwright MCP) — the agent navigates to each story, interacts with the component through its accessibility tree, and reports results in chat. Good for debugging failures and exploratory testing: you can follow up conversationally ("navigate to the error state story and check if the dismiss button has an accessible name") without writing additional test code.

Scripted mode (CLI) — run npx playwright test directly from the terminal. Results are reported to the test management system automatically. Good for regression suites, CI pipelines, and any execution where repeatability matters more than interactivity.

Both modes use the same test files and both flow results to the same test management cases. Interactive mode is what you use during development when things are breaking; scripted mode is what runs in CI.

You add: Disciplined execution. Run every test case, including edge cases and error states. Don't skip the states that seem unlikely — requirements gaps often hide there.

When a test fails, the triage question is: is this a requirements gap, an implementation gap, or a test gap? The routing is different for each. See the Triage section below for the decision tree.

You add: The triage judgment. This is the QA skill that AI doesn't replace — reading a failure and understanding its root cause.

Run tests iteratively as engineering implements changes. Track which test cases are passing, which are blocked, which are failing. Use the linked backlog stories to surface test results to the PM and engineering without separate status updates. See the Test Cycle Strategies section below for how to structure your cycles.

Before sign-off, run regression coverage against areas of the codebase affected by the feature. Regressions to watch for: a design token update (color, spacing, typography), a shared component modification, a Figma redesign that triggers component regeneration, or a dependency upgrade. You don't write new tests for regression — you re-run the .spec.ts files that already exist. Those files, with their test case keys, are your regression suite.

When all acceptance criteria tests pass and regression coverage is clean, sign off on the feature for handoff. Your sign-off is the quality gate — it is not a formality. The PM and engineering proceed on the basis of your judgment that the feature meets the specified quality standard.