Start with acceptance criteria
Do not start with “which tests should I write?” Start by saying how you know the feature is done. For example:
- the user can save the new field;
- the API returns the new parameter;
- the error appears in human language;
- old behavior is unchanged for other roles.
That gives AI boundaries. Without acceptance criteria, the plan can grow too broad or miss the main behavior.
Split checks by type
A small feature does not always need a large e2e suite. But it usually needs three groups:
- happy path: the main scenario;
- edge cases: empty values, permissions, boundary states, repeated clicks;
- regression checks: nearby scenarios that worked before the change.
If the feature goes to production, add a short smoke check after deploy.
Do not test everything
A useful test plan includes boundaries. If something is not in scope, say it directly: “we are not checking old mobile layout”, “we are not testing the external integration”, or “we are not running a performance test.”
That is not laziness. It is risk management.
In short
A small feature does not need a giant test strategy. It needs a clear minimum: what must work, what can break nearby, what to check by hand, and what to watch after deploy.
AI can help with that plan if you give it scope, acceptance criteria, and nearby risks.
Quick checklist
- Name acceptance criteria before listing tests.
- Cover the happy path and 2-3 edge cases.
- Add regression checks for nearby behavior.
- Separate automated tests from manual QA.
- Prepare a post-deploy smoke check.
- Say what is not in scope.
Write a small-feature test plan
Help me write a short test plan for a small feature. Context: - What is changing: [short feature description] - Who uses it: [user, admin, API client, internal team] - Acceptance criteria: [expected behavior list] - Where it runs: [page, endpoint, command, job, integration] - What can break nearby: [login, payments, permissions, validation, cache, UI] - Available checks: [unit tests, integration tests, e2e, manual QA, staging] - Constraints: [no time, no test data, no staging, other] Build the plan: 1. Happy path: what must work. 2. Edge cases: boundary or unusual scenarios to check. 3. Regression checks: nearby behavior that could break. 4. Manual checks: what to click or inspect by hand. 5. Smoke check after deploy. 6. What is not worth testing now and why. Output format: - Scope - Must-pass checks - Edge cases - Regression checks - Manual QA - Post-deploy smoke check - Not in scope