Skills

Software Test Plan and Coverage Analysis

6 weeks · 0 milestones

Produce a software test plan and coverage analysis for a real software system (your own or an open-source system). The test plan must include: a testing scope statement identifying what is in and out of scope with rationale, a test strategy for at least 3 test levels (unit, integration, system), documented test cases for at least 20 representative scenarios with expected results, risk-based test prioritisation explaining why higher-risk areas receive more coverage, and a coverage analysis showing which code paths, branches, or requirements are covered by the documented tests. Tools: pytest-cov, coverage.py, JaCoCo, or equivalent (all free). Proof artifacts: the test plan document (design artifact) and the coverage report with gap analysis (analysis artifact). Accessible: all coverage measurement tools are free and open-source. Verification: a software engineer reviews the coverage gap analysis — 'these untested paths represent what risk?' — and the test case rationale for at least 5 cases.

Part of: Engineering · Proves for: Engineers, UG

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.

You'll sign in first, then come straight back here.

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

Powstik Guide

Twenty structured test cases and a coverage figure.

Steps

Map each test to a requirement.
Write steps, input and expected result.
Run and record pass or fail.
Calculate coverage and name gaps.

Template

| ID | Requirement | Steps | Input | Expected | Pass/fail |
|----|-------------|-------|-------|----------|-----------|
Coverage: __ / __ = __%        Gaps:

What gets sent back

Fewer than 20 tests.
Tests not mapped.
Coverage not calculated.

Resources

Foundationstart here

Depthgo deeper

Masteryfor the dedicated

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.

You'll sign in first, then come straight back here.

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

Powstik Guide

A complete test plan with coverage analysis, reviewed.

Steps

Assemble scope, test cases and coverage numbers into one report.
Check every number traces to a calculation.
Book a qualified reviewer.
Log at least three challenges and your answers.

Template

Review session log
Date:            Duration:
Reviewer name:
Reviewer role and credentials:

Challenge 1 (a coverage gap):
  What they asked:
  My answer:
  Did it hold?
Challenge 2:
  What they asked:
  My answer:
  Did it hold?
Challenge 3:
  What they asked:
  My answer:
  Did it hold?

What I will change because of this session:

What gets sent back

A reviewer who doesn't meet the stated bar.
Notes without the reviewer's name and role.
No coverage analysis.

Resources

Foundationstart here

Depthgo deeper

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.

You'll sign in first, then come straight back here.

Part of

Software Engineering Foundations →

Related outcomes

Milestone map

3 milestones

Define the System Under Test and Testing Objectives

1–2 weeks (2–3 hrs/week)

Proof required

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.

You'll sign in first, then come straight back here.

Write Test Cases and Calculate Coverage

3–4 weeks (4–5 hrs/week)

Proof required

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

Powstik Guide

Twenty structured test cases and a coverage figure.

Steps

Map each test to a requirement.
Write steps, input and expected result.
Run and record pass or fail.
Calculate coverage and name gaps.

Template

| ID | Requirement | Steps | Input | Expected | Pass/fail |
|----|-------------|-------|-------|----------|-----------|
Coverage: __ / __ = __%        Gaps:

What gets sent back

Fewer than 20 tests.
Tests not mapped.
Coverage not calculated.

Resources

Foundationstart here

Depthgo deeper

Masteryfor the dedicated

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.

You'll sign in first, then come straight back here.

Write the Test Plan and Present Coverage Analysis

2–3 weeks (2–3 hrs/week)

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

Powstik Guide

A complete test plan with coverage analysis, reviewed.

Steps

Assemble scope, test cases and coverage numbers into one report.
Check every number traces to a calculation.
Book a qualified reviewer.
Log at least three challenges and your answers.

Template

Review session log
Date:            Duration:
Reviewer name:
Reviewer role and credentials:

Challenge 1 (a coverage gap):
  What they asked:
  My answer:
  Did it hold?
Challenge 2:
  What they asked:
  My answer:
  Did it hold?
Challenge 3:
  What they asked:
  My answer:
  Did it hold?

What I will change because of this session:

What gets sent back

A reviewer who doesn't meet the stated bar.
Notes without the reviewer's name and role.
No coverage analysis.

Resources

Foundationstart here

Depthgo deeper

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.

You'll sign in first, then come straight back here.