Milestone map
Milestone map
3 milestones
Define the System Under Test and Testing Objectives
1–2 weeks (2–3 hrs/week)
Select a real or realistic software system, embedded system, or hardware assembly for which you will write a test plan. Define the system under test (SUT): its purpose, key functional requirements (from a requirements specification or user stories), and non-functional requirements to be tested (performance, security, reliability). Identify the testing levels to be covered (unit, integration, system, acceptance) and the testing types within scope (functional, regression, performance, security, usability, or equivalent). State what is explicitly out of scope and why — a test plan with no scope boundaries is not a test plan.
Proof required
Submit your system under test definition (≥500 words): SUT description, ≥8 functional requirements or user stories to be tested, ≥2 non-functional requirements, testing levels in scope, and a clear statement of what is out of scope with justification.
What gets checked
- ≥8 functional requirements or user stories are identified as test targets — not 'all features'
- ≥2 non-functional requirements are included as test targets — not just functional testing
- Out-of-scope items are explicitly listed with justification — not just omitted
Common mistakes
- Test plan scope defined as 'test all features' — a test plan must identify specific testable requirements; 'all features' produces a plan that tests nothing specifically
- Non-functional requirements omitted — performance, security, and reliability testing are frequently omitted from student test plans; this omission means the most common real-world failure modes are not covered
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Confirm ≥8 functional requirements or user stories are identified as specific test targets.
- Confirm ≥2 non-functional requirements are included — flag if only functional testing is planned.
- Confirm out-of-scope items are listed with justification — flag absent scope exclusions.
Write Test Cases and Calculate Coverage
3–4 weeks (4–5 hrs/week)
Write specific, executable test cases for the requirements identified in M1. Use a structured format for each test case: test case ID, requirement covered, preconditions, test steps, input data, expected result, and pass/fail criteria. Apply coverage techniques: equivalence partitioning and boundary value analysis for functional requirements; apply load profiles and threshold targets for non-functional tests. Calculate your requirement coverage: (requirements with ≥1 test case / total requirements) × 100%. Identify any requirements with zero test cases and justify the omission. A test plan with untested requirements must explicitly acknowledge them.
Proof required
Submit ≥20 test cases in structured format (ID, requirement mapped, steps, input, expected result, pass/fail criteria) and a coverage table showing the percentage of requirements with ≥1 test case, with any untested requirements identified and justified.
What gets checked
- ≥20 test cases are in structured format with all required fields populated — not free-text descriptions
- Coverage percentage is calculated and stated — not claimed without supporting data
- Any untested requirements are identified and justified — not silently omitted
Common mistakes
- Test cases that describe what to test without specifying how — 'test the login function' is not a test case; a test case specifies exact steps, input data, and the expected result that determines pass or fail
- 100% coverage claimed without evidence — coverage must be calculated from the requirement-to-test-case mapping table, not stated as a target achieved
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Confirm ≥20 test cases are in structured format — flag free-text descriptions without required fields.
- Confirm coverage percentage is calculated from the mapping table — flag coverage claims without supporting data.
- Confirm untested requirements are explicitly identified and justified.
Write the Test Plan and Present Coverage Analysis
2–3 weeks (2–3 hrs/week)
Assemble the complete test plan document (2,000–3,000 words plus test case appendix) combining M1 scope and M2 test cases. Include: test objectives and scope, test environment requirements (tools, hardware, software versions, test data), entry and exit criteria, test execution schedule, risk and mitigation (what could prevent test completion), and the coverage analysis. Present the test plan to a reviewer with software testing, quality assurance, or software engineering experience and answer Q&A on the coverage gaps and the exit criteria.
Proof required
Submit your complete test plan (2,000–3,000 words plus test case appendix) and review record: reviewer name, role, ≥3 challenge questions about coverage gaps or exit criteria, and your responses.
What gets checked
- Entry and exit criteria are specific and measurable — '100% of critical test cases executed with ≤2 open P1 defects' rather than 'when testing is done'
- Test environment is specified — which tools (Selenium, JMeter, pytest, manual), versions, and test data sources
- Reviewer has software testing or QA experience and challenged the coverage gaps or exit criteria specifically
Common mistakes
- Exit criteria that say 'when all tests pass' — exit criteria must define what is acceptable given real-world constraints; a plan with zero defect tolerance will never exit in practice
- Test environment described as 'a computer' — test environment specification must name the testing tools, browsers or devices, software versions, and test data sources
Resources
Foundationstart here
What a verifier looks for
- Engineering Design Triad check: M1–M3 together produce a design artifact (test plan with scope and environment specification), an analysis artifact (test cases with coverage calculation and coverage gap identification), and a documentation artifact (complete test plan document + review record) — confirm all three types are present.
- Confirm entry and exit criteria are specific and measurable — flag 'when testing is done' criteria.
- Confirm test environment names tools, versions, and data sources.
- Confirm reviewer has software testing or QA experience and challenged coverage gaps or exit criteria specifically.
- The Proof Accessibility Rule applies — ISTQB free study materials, IEEE 829 free overview, Ministry of Testing free articles, and TestLodge free templates are all accessible without commercial licence.