The Test Plans model

The hierarchy

Test Plan → Test Suite → Test Case → Test Point → Result.

Entity	What it is
Test Plan	A container for a testing effort — a release, a sprint, a regression campaign.
Test Suite	A folder of test cases inside a plan. Three kinds: static (hand-picked), requirement-based (bound to a User Story / PBI), query-based (filled by a work-item query).
Test Case	The work item describing what to test — title, steps, expected results. One case can belong to several suites and plans.
Test Point	A test case as it appears in one suite, for one configuration. Results attach to points, not to the case directly.
Result	The outcome of running a point (Passed, Failed, …) at a moment in time. TestPulse reports the latest result.

How TestPulse reads it

TestPulse walks the tree read-only: plan → suites → cases → points → latest results. It never modifies anything it did not create itself (see what TestPulse writes).

Because results attach to points, a case that lives in several suites can have several results. TestPulse resolves the latest result for the points in scope.

Suite types, in practice

Static — you pick the cases. TestPulse reports them as-is.

Requirement-based — the suite is tied to a User Story / PBI; this is what powers traceability and the coverage view.

Query-based — cases are resolved from a WIQL query at read time.

Getting started

Concepts

Generate a report

Exports

Quality & decision

Cockpit

Dashboard

Coverage Builder

Test Repository

Reports history

Configuration

On the work item

Exploratory testing

Security

Reference

Changelog

The Test Plans model

The hierarchy

How TestPulse reads it

Suite types, in practice

Traceability & hierarchy

Statuses & results

​The hierarchy

​How TestPulse reads it

​Suite types, in practice

​Related

Traceability & hierarchy

Statuses & results

The hierarchy

How TestPulse reads it

Suite types, in practice

Related