Test Plan — Release Plan for a SAMPLE Service (Markdown)
A complete release test plan for the fictional Novus Checkout Service — scope, test levels, entry and exit criteria, a risk table and deliverables. Useful as a Markdown-rendering fixture with three tables and nested lists, and as a realistic input for documentation tooling that has to extract structure from prose.
# Test Plan — Novus Checkout Service, release 2026.08
**Status:** SAMPLE document for a fictional service. Every name, system and defect here is invented.
## 1. Scope
In scope: cart pricing, discount stacking, tax calculation, session persistence, receipt
rendering, and the payment capture call to the fictional gateway at `payments.example.com`.
Out of scope: the catalogue service, the partner loyalty API (stubbed in every environment), and
anything behind the `@wip` tag.
## 2. Test levels
| Level | Owner | Tooling | Gate |
| --- | --- | --- | --- |
| Unit | Engineering | JUnit XML, LCOV | 80% line coverage |
| Contract | Engineering | Cucumber, JSON schema | all scenarios green |
| Integration | QA | Robot Framework | no P1 or P2 defects open |
| Performance | QA | Load generator, HAR capture | p95 under 500 ms |
| Exploratory | QA | Session notes | charter completed |
## 3. Entry criteria
1. The build is green on the default branch.
2. Coverage is at or above the gate in `coverage-gate-config.json`.
3. No test is quarantined for more than five consecutive builds.
## 4. Exit criteria
1. Every requirement in the traceability matrix has at least one passing test.
2. No open defect at severity P1 or P2.
3. The flake rate across the last twenty builds is below 2%.
## 5. Risks
| Risk | Likelihood | Impact | Mitigation |
| --- | --- | --- | --- |
| Rounding differs between the pricing service and the receipt renderer | Medium | High | Shared rounding fixture, asserted in both suites |
| Payment gateway timeouts leak into unit runs | Medium | Medium | Network calls blocked in the unit profile |
| Flaky session-expiry test masks a real regression | High | High | Quarantine after two failures, tracked as a defect |
## 6. Deliverables
- JUnit XML per suite and a merged aggregate report
- LCOV tracefile plus a Cobertura twin for the dashboard
- HAR capture of one full checkout journey
- This plan, the test-case matrix, and the traceability matrix
Specifications
- Seed
- 61200
- Sections
- 6
- Tables
- 3
- Flavour
- GitHub-flavoured Markdown
- Fictional
- true
- Line Endings
- LF
Testing contract
Reference control- Scenario
- Render or extract structure from a multi-section Markdown test plan.
- Expected result
- Six numbered sections and three tables are found, and the exit criteria list parses as three ordered items.
What is a .md file?
Markdown (MD) is a lightweight plain-text markup language that uses simple punctuation conventions to denote headings, lists, links, emphasis, and code. It is designed to be readable as-is and to convert cleanly to HTML. It is widely used for documentation, READMEs, and content authoring.
How to use this file
Use an example Markdown file to test parsers and renderers, verify GitHub-Flavored Markdown extensions like tables and fenced code, and exercise HTML-conversion pipelines.
How to use this file for testing
“Test Plan — Release Plan for a SAMPLE Service (Markdown)” is a deterministic Novus Examples fixture for Editor testing, Conversion testing, Config testing. Text-based files you can open, edit, and download directly in the browser editor.
Documented properties for this file: seed 61200 · LF. Compare results against paired or grouped companions on this page when present (clean↔damaged, searchable↔scanned, or format twins) so scores stay reproducible across runs.
Download the file once, keep the path stable in CI or local scripts, and treat the spec table as the contract: dimensions, seeds, field lists, and roles are intentional. Corrupt or invalid samples are labelled as such — expect parsers to fail loudly rather than silently accept them.
Test and coverage reports document their totals (suites, cases, passes, failures, skips, covered lines) in the spec table. Point your CI dashboard, coverage gate, or report converter at the file and assert those counts survive; format twins carry identical numbers so a conversion can be scored exactly.
Code examples
import markdown # pip install markdown
html = markdown.markdown(open("test-plan.md").read())
print(html[:200])Related files
- lcovCoverage — Gate Boundary at 79.29% (misses the gate by one line)A tracefile sitting misses the gate by one line against the 80% minimum in this group's gate config: 111 of 140 lines, 79.29%. 79.29% is one covered line short of the gate, the smallest possible failure.
- lcovCoverage — Gate Boundary at 80.00% (meets the gate exactly)A tracefile sitting meets the gate exactly against the 80% minimum in this group's gate config: 112 of 140 lines, 80.00%. 80.00% is exactly the configured minimum, so a > comparison fails the build and a >= comparison passes it — the single most common off-by-one in a coverage gate.
- lcovCoverage — Gate Boundary at 80.71% (clears the gate by one line)A tracefile sitting clears the gate by one line against the 80% minimum in this group's gate config: 113 of 140 lines, 80.71%. 80.71% clears the gate by one covered line, the smallest possible pass.
- mdCoverage — Markdown Pull-Request SummaryThe Markdown comment a coverage bot posts on a pull request: a headline percentage, a per-file table and the uncovered line numbers. Useful for testing Markdown table rendering and for checking that a bot's generated comment matches the machine-readable report it claims to summarise. Every file in this group describes the same four-file source tree and reports 127/140 lines, 17/24 branch outcomes and 18/20 functions, so a converter can be diffed against a known answer.
- featureGherkin — Background, Feature Tags and HooksA named Background whose two steps are prepended to all three scenarios, plus feature-level tags that every scenario inherits and scenario-level tags that only some carry. Tag filtering is where this file earns its keep: @slow selects one scenario by its own tag and all three by inheritance from the feature.
- featureGherkin — Checkout Feature (Background, Outline, Doc String)The source feature for this whole group: a Background with a data table, a plain scenario, a Scenario Outline expanded by two Examples tables, and a scenario asserting against a doc string. It compiles to exactly six pickles and 32 pickle steps — the numbers the cucumber-messages and cucumber.json twins next to it report.
Generated by generation/testing.py. Free for any use, no attribution required — license.