QA Test Plan Writing
Test plan structure, test cases, scenarios, scope, and bug priority levels
Test plan writing essentials
- Test plan: strategy + scope + test types + resources + schedule + pass/fail criteria
- Test case formula: ID + preconditions + numbered steps + expected result at each layer
- Scenario vs. case: scenario = "user authentication" (what); test case = exact steps with inputs (how)
- Scope: in scope + out of scope + test types per feature + entry/exit criteria
- P0 = system unusable/data loss; P1 = major feature broken; P2 = partial/workaround; P3 = cosmetic
Question 0 of 5
What is the primary purpose of a QA test plan?
Testing strategy + scope + types + resources + schedule — agreed before testing begins. A test plan answers:
- What will be tested? (scope: features, APIs, integrations)
- What will NOT be tested? (explicitly out of scope)
- How will it be tested? (unit, integration, E2E, performance, security, accessibility)
- Who will test it? (QA engineers, developers for unit tests, users for UAT)
- When? (test phases relative to release dates)
- What are the pass/fail criteria? (no P0 or P1 bugs open at release)
Which test case is written most effectively?
ID + title + preconditions + numbered steps + expected result for each observable layer. Test case anatomy:
- ID: TC-AUTH-003 — enables referencing, tracking, and regression suites
- Title: descriptive scenario name
- Preconditions: exact setup state — no ambiguity about what "registered user" means
- Steps: numbered, one action each
- Expected result: UI message (exact text), system state (account unlocked), and HTTP response (401) — verifiable at multiple layers
What is the difference between a test case and a test scenario?
Scenario = high-level "what"; test case = detailed "how" with exact steps and expected outputs. Example:
- Test scenario: "User authentication" — covers the general area
- Test cases under it:
- TC-AUTH-001: Login with valid credentials
- TC-AUTH-002: Login with unregistered email
- TC-AUTH-003: Login with invalid password
- TC-AUTH-004: Login with expired password
- TC-AUTH-005: Account lockout after 5 failed attempts
- TC-AUTH-006: Password reset via email
A test plan says: "All features will be tested." Why is this insufficient?
Missing: specific features, test types, entry criteria, and pass/fail release criteria. What a scope section must include:
- In scope: "User authentication module, password reset flow, OAuth2 integration with Google and GitHub"
- Out of scope: "Mobile app, IE11 compatibility, load testing above 10K concurrent users"
- Test types per feature: "Auth: unit tests (developers), integration tests (QA), security pen test (external)"
- Entry criteria: "Testing begins when all P0 stories are dev-complete and deployed to staging"
- Exit criteria: "Release approved when: zero P0 bugs open, zero P1 bugs open, all P2 bugs triaged with accepted deferral"
Which bug priority level is defined correctly?
P0 = system unusable or data loss — stop everything. Priority levels:
- P0 (Critical): system down, data loss, security breach, complete feature failure with no workaround → release blocker, fix immediately
- P1 (High): major feature broken, poor workaround exists, significant user impact → release blocker unless deferred with sign-off
- P2 (Medium): feature partially broken, usable workaround, moderate impact → fix before next minor release
- P3 (Low): minor inconvenience, cosmetic, edge case → fix in backlog, no release impact