# Test Environment and Data Readiness: [Project or release name]

> One document for the four environment and data information items of
> ISO/IEC/IEEE 29119-3:2021: test data requirements (clause 8.5), test
> environment requirements (clause 8.6), the test data readiness report
> (clause 8.7) and the test environment readiness report (clause 8.8).
> Part A states what testing needs and is agreed before the environment
> is built; Part B records, at a checkpoint before execution, whether
> each need is met. Replace every `[bracketed]` value and every row
> marked *Example*.

<!--
Guidance: How to use this template
- Fill Part A when the test design is known, and send it to the people
  who build environments and provide data. They need lead time.
- Fill Part B at each readiness checkpoint (for example two days before
  each test cycle). Every requirement in Part A gets a row in Part B.
- Use the same IDs in both parts: TDR-nn for data requirements, TER-nn
  for environment requirements.
- If test data contains personal data, involve the data protection
  owner before copying anything. Synthetic or masked data is the
  default; production copies need a documented approval.
- The worked example is a fictional system test of release 5.3 of
  Quillfern Desk, a help desk product of the fictional Quillfern Systems.
-->

## Document control

<!-- Guidance: Part A is approved once; Part B is reissued per checkpoint. Record both in the revision history. -->

| Field | Value |
|---|---|
| Document ID | [TEDR-PROJECT-001] |
| Project / release | [Quillfern Desk 5.3] *(Example)* |
| Test plan | [TP-QD53-001] |
| Test level | [System test] |
| Version | [1.0] |
| Status | [Part A draft / Part A approved / Readiness checkpoint n issued] |
| Owner | [@test-lead] |
| Environment owner | [@platform-lead] |
| Data owner | [@data-steward] |
| Classification | [Internal / Confidential] |
| Last updated | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | Part A draft |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Part A approved |
| 1.1 | YYYY-MM-DD | [@name] | *Example:* Readiness checkpoint 1 for cycle 1 |

**Part A: Requirements** (sections 1 and 2)

## 1. Test data requirements

<!-- Guidance: 29119-3 clause 8.5. For each data need give an ID, a description precise enough to build from, who provides it, when it is needed, how it is reset between runs, and how it is archived or disposed of. Trace each requirement to the test cases or procedures that use it. -->

| ID | Description | Used by | Responsibility | Period needed | Resetting needs | Archiving or disposal |
|---|---|---|---|---|---|---|
| TDR-01 *(Example)* | 5,000 synthetic tickets across 40 queues, statuses in production proportions | TC-BRD-001 to TC-BRD-060 | [@test-data-engineer], generated by script | Cycle 1 start to release | Restore snapshot before each cycle | Deleted with environment |
| TDR-02 *(Example)* | 200 customer accounts, 20 with assistive technology settings enabled | Portal procedures TP-PRT-01 to TP-PRT-09 | [@test-data-engineer] | Cycles 1 and 2 | Reset passwords nightly | Deleted with environment |
| TDR-03 *(Example)* | Ticket histories producing PDF exports of 1 MB, 5 MB and 20 MB | TC-PDF-031 to TC-PDF-050 | [@tester] | Cycle 1 week 2 onward | None, read only | Kept as reusable asset |
| TDR-04 *(Example)* | Masked copy of 10 production queues for migration test | TC-MIG-001 to TC-MIG-012 | [@data-steward] after approval | One week in cycle 2 | No reset; single use | Securely erased at end of cycle 2, erasure recorded |
| [TDR-nn] | [Description] | [Test cases] | [@owner] | [Period] | [Reset] | [Archive / dispose] |

### 1.1 Personal and sensitive data

| Question | Answer |
|---|---|
| Does any data requirement contain personal data? | *Example:* Only TDR-04, masked |
| Legal basis or approval for using it | [Approval reference from the data protection owner] |
| Masking or synthesis method | [Method and tool; who checked it] |
| Access restrictions | [Named roles only; environment access logged] |
| Disposal evidence | [How deletion is recorded] |

Check the data protection rules that apply to you with your data
protection owner; a privacy impact assessment (`compliance/dpia`) may be
needed for production-derived test data.

## 2. Test environment requirements

<!-- Guidance: 29119-3 clause 8.6. List every item the environment needs: hardware, software, network, services, tools, accounts, facilities. For each, describe the configuration, who provides it and when. Record known differences from production; they limit what results mean. -->

| ID | Environment item | Description and configuration | Responsibility | Period needed |
|---|---|---|---|---|
| TER-01 *(Example)* | Application servers | Release 5.3 build, 3 instances, same container images and settings as production | [@platform-lead] | Cycle 1 start to release |
| TER-02 *(Example)* | Database | Same engine and major version as production, restored from TDR-01 snapshot | [@platform-lead] | As TER-01 |
| TER-03 *(Example)* | PDF export service | Same version as production; 20 MB file limit as production | [@platform-lead] | As TER-01 |
| TER-04 *(Example)* | Single sign-on | Test tenant of the identity provider with 30 test users | [@identity-admin] | As TER-01 |
| TER-05 *(Example)* | Client devices and assistive technology | Windows 11 with NVDA, macOS and iOS with VoiceOver, Android with TalkBack | [@test-lead] | Cycle 1 week 2 onward |
| TER-06 *(Example)* | Test tools | Test management project, CI runners, accessibility checker | [@test-lead] | Throughout |
| [TER-nn] | [Item] | [Configuration] | [@owner] | [Period] |

### 2.1 Known differences from production

| Item | Production | Test environment | Effect on results |
|---|---|---|---|
| Database replicas *(Example)* | 2 read replicas | None | Read performance not representative; no performance testing here |
| E-mail delivery *(Example)* | Live provider | Capture service, no external delivery | Delivery timing not tested |
| [Item] | [Production] | [Test] | [Effect] |

**Part B: Readiness reports** (sections 3 to 5)

## 3. Test data readiness report

<!-- Guidance: 29119-3 clause 8.7. One row per TDR requirement, stating its status at the checkpoint with evidence. A requirement is Ready only when someone has checked it, not when it was requested. -->

Checkpoint: [1], date YYYY-MM-DD, for [cycle 1 starting YYYY-MM-DD].

| Requirement | Status | Evidence or check performed | Issue and action |
|---|---|---|---|
| TDR-01 *(Example)* | Ready | Row counts and status mix checked by query, results attached | |
| TDR-02 *(Example)* | Ready | 200 accounts sign in; 20 with settings enabled | |
| TDR-03 *(Example)* | Partly ready | 1 MB and 5 MB histories exist; 20 MB history fails to generate | Fix generator by YYYY-MM-DD (owner [@tester]) |
| TDR-04 *(Example)* | Not ready | Not needed until cycle 2; approval pending | Approval due YYYY-MM-DD |
| [TDR-nn] | [Ready / Partly ready / Not ready] | [Evidence] | [Action] |

## 4. Test environment readiness report

<!-- Guidance: 29119-3 clause 8.8. One row per TER requirement. Include a smoke test result: an environment that is installed but untested is not ready. -->

| Requirement | Status | Evidence or check performed | Issue and action |
|---|---|---|---|
| TER-01 *(Example)* | Ready | Build 5.3.0-rc2 deployed; smoke suite passed (42 of 42) | |
| TER-02 *(Example)* | Ready | Restored from snapshot, schema version matches build | |
| TER-03 *(Example)* | Partly ready | Exports over 5 MB time out | Platform ticket raised; owner [@platform-lead] |
| TER-04 *(Example)* | Not ready | 2 of 30 test accounts expired | Renewal requested |
| TER-05 *(Example)* | Ready | Device and assistive technology versions recorded | |
| TER-06 *(Example)* | Ready | | |
| [TER-nn] | [Status] | [Evidence] | [Action] |

## 5. Readiness decision

<!-- Guidance: Decide whether execution can start, and which tests must wait. Partial readiness is common; say exactly which tests are affected so execution can start on the rest. -->

| Item | Value |
|---|---|
| Decision | [Start / Start with restrictions / Do not start] |
| Restrictions | *Example:* Start cycle 1. Defer large-file PDF cases (TDR-03, TER-03) and single sign-on cases for the two expired accounts (TER-04) until their actions close |
| Effect on schedule | *Example:* None if actions close by YYYY-MM-DD; otherwise reported as a blocker in the test status report |
| Decided by | [@test-lead], [@platform-lead] |
| Date | YYYY-MM-DD |

Open readiness issues are carried into the Test Status Report
(`quality/test-status-report`) as blockers until they close.

## 6. References

<!-- Guidance: Link the plan and the detailed specifications that the requirements come from. -->

- Test plan (`quality/test-plan-29119`) and test strategy (`quality/test-strategy`)
- Test case specification (`quality/test-case-specification`) and test procedure (`quality/test-procedure`), which the "Used by" column traces to
- Data protection impact assessment (`compliance/dpia`) when production-derived data is used
- ISO/IEC/IEEE 29119-3:2021, *Software and systems engineering: Software testing: Part 3: Test documentation*, clauses 8.5 to 8.8. Official text: ISO, IEC and IEEE, purchase or licensed access: https://www.iso.org/standard/79429.html

## Standard and licence note

Structure aligned with ISO/IEC/IEEE 29119-3:2021, *Software and systems
engineering: Software testing: Part 3: Test documentation*: test data
requirements (clause 8.5), test environment requirements (clause 8.6),
test data readiness report (clause 8.7) and test environment readiness
report (clause 8.8), combined here in one document. The standard is
copyrighted and is cited by name, edition and clause number only; no
text or example from it is reproduced, and all wording here is
original. Check the current edition before claiming conformance. This
template is not legal advice on data protection. Official text: ISO,
IEC and IEEE, purchase or licensed access, at the link in section 6.
Template licence: MIT.