Test Plan Template

Test Plan Template

Copy this page and fill in each section. Remove placeholder text in italics. See Testing Processes for a description of each component.

---

1. Document Header

Field	Value
Title	Test Plan: [Component or Module Name]
Component	e.g. FlowController, ConnectionManager
Author	Name
Date	YYYY-MM-DD
Version	1.0
Status	Draft / Reviewed / Approved

---

2. Scope

In scope

List the classes, modules, or subsystems covered by this plan.

• e.g. FlowController business logic
• e.g. HardwareFlowSensor adapter (integration tests only)

Out of scope

List what is explicitly not covered and why.

• e.g. Vendor SDK internals: not observable
• e.g. UI layer: covered by a separate plan

---

3. Objectives

One or two sentences stating the quality goal.

Example: Verify that all business logic in FlowController behaves correctly across its full input range using injected fakes, and verify that the hardware adapters interact correctly with the sensor and valve on the target.

---

4. Test Levels

Level	Scope	Dependencies	Run on
Unit	Single class	All faked	Target, no hardware state required
Component	Subsystem of classes	Key interfaces faked	Target
Integration	Full stack	Real hardware	Target with hardware connected

---

5. Hardware and Environment Requirements

Target hardware

Board name, revision, and any special configuration.

Connected peripherals

List each peripheral, its port or pin assignment, and its required state before tests run.

Peripheral	Port / Pin	Required state
e.g. Flow sensor	SPI0, CS=GPIO4	Powered, calibrated
e.g. Valve driver	GPIO12	Closed at start

Running unit and component tests

Unit and component tests require no hardware state. They can be run immediately after deployment to the target:

# All unit and component tests
ctest --test-dir build --label-exclude HwIntegration

Running integration tests

Describe any setup commands, e.g. loading firmware, setting hardware state.

# Integration tests only
ctest --test-dir build --label-regex HwIntegration

---

6. Test Cases

Add one row per test case. Detailed cases may be expanded in sub-sections below.

ID	Description	Level	Hardware required
TC-[PREFIX]-001	e.g. Valve opens when calibrated flow exceeds threshold	Unit	No
TC-[PREFIX]-002	e.g. Valve closes at exactly the threshold value	Unit	No
TC-[PREFIX]-003	e.g. Calibration offset is applied before threshold check	Unit	No
TC-[PREFIX]-004	e.g. Log message contains the calibrated flow value	Unit	No
TC-[PREFIX]-005	e.g. HardwareFlowSensor returns valid reading on target	Integration	Yes

TC-[PREFIX]-001 (detailed example)

Description: Valve opens when calibrated flow exceeds threshold.

Level: Unit

Preconditions:

• StubSensor configured to return a raw reading that, after applying calibrationOffset, exceeds flowThreshold
• SpyValve initialised with no prior calls
• FlowConfig set to {calibrationOffset: 0.5, flowThreshold: 10.0}

Steps:

1. Set stub sensor reading to 10.0
2. Call controller.update()

Expected result: valve.lastAction() returns "open"

Hardware required: No

---

7. Coverage Goals

Scope	Goal	Tool
Business logic classes	100% branch coverage	e.g. gcov / lcov
Hardware adapters	Covered by integration tests	n/a

Running coverage

cmake -B build -DCMAKE_BUILD_TYPE=Debug -DCMAKE_CXX_FLAGS="--coverage"
cmake --build build
ctest --test-dir build --label-exclude HwIntegration
lcov --capture --directory build --output-file coverage.info
lcov --remove coverage.info '*/googletest/*' -o coverage.info
genhtml coverage.info --output-directory coverage_html

---

8. Pass / Fail Criteria

The test run is considered passing when all of the following are true:

• All unit and component tests pass with zero failures
• All integration tests pass on the target with the reference hardware configuration described in Section 5
• Branch coverage for all business logic classes is at or above the goal stated in Section 7
• No test is marked as skipped without a documented reason in Section 9

---

9. Known Limitations and Exclusions

Document what this plan does not cover and why. Leave blank if none.

Item	Reason
e.g. Vendor SPI library internals	Not observable; verified by supplier
e.g. Hardware failure modes	Cannot be safely induced on target

---

10. Revision History

Version	Date	Author	Changes
1.0	YYYY-MM-DD	Name	Initial draft