# Integrated Test Plan — example

**Reference:** EX-TP-001  
**Author:** Carlo Hennsa  
**Date:** 14 October 2026  
**Version:** 1.0  
**Status:** Illustrative fictional example. No tests have been executed.

## 1. Purpose and decision

Test the fictional Aster Field Operations Platform before a release. The proposed release gate requires verified critical workflows, access controls, offline synchronization, recoverability and an explicitly approved operational decision.

## 2. Scope

In scope: identity and roles; field inspection and photo evidence; offline capture and queued replay; supervisor review; API contracts and audit; security, performance, accessibility and restore validation. Out of scope: physical gate control, native mobile apps, AI hazard detection, multi-region failover and unsupported external integrations.

## 3. Test environments

- **TEST:** Disposable DB, deterministic seeded data, CI automation.
- **STAGING:** Production-like auth/TLS/monitoring and release candidate.
- **DISCONNECTED:** Block client API traffic while server remains healthy.
- **RECOVERY:** Restore into isolated fresh environment and reconcile data.

## 4. Testing levels

- Unit tests on every change for rules, validators and synchronization.
- Contract and API tests for authorization, schema and error behaviour.
- End-to-end browser tests for capture, replay and supervisory approval.
- Security, resilience and restore drills before the release decision.
- UAT against approved workflows with named owner sign-off.

## 5. Representative scenarios

| ID | Scenario | Expected result | Priority | Execution |
|---|---|---|---|---|
| TP-001 | Authentication: Valid user logs in; session renewal follows policy | Permitted route works; token expiry enforced | P1 | Auto |
| TP-002 | Authorization: Field observer calls supervisor approval API | 403 response; no unauthorized state change; audit event | P1 | Auto |
| TP-003 | Inspection submission: Complete inspection with required image and valid data | One stored record and linked evidence; confirmation shown | P1 | Auto |
| TP-004 | Input validation: Omit mandatory photo or submit invalid area ID | Clear validation response; no partial record saved | P1 | Auto |
| TP-005 | Offline capture: Disconnect field client, capture two inspection records | Records queued locally, distinguishable, survive reload | P1 | Auto |
| TP-006 | Replay after recovery: Reconnect and replay pending queue | Exactly one logical record per command; queue clears on ACK | P1 | Auto |
| TP-007 | Duplicate events: Replay same command ID three times | Idempotent outcome; no duplicate audit or evidence | P1 | Auto |
| TP-008 | Conflicting updates: Client A and B edit same record while disconnected | Defined policy applied; conflict surfaced or rejected; logged | P1 | Manual+Auto |
| TP-009 | Supervisor review: Approve complete inspection with supervisor account | Status advances once; actor, time and reason traceable | P2 | Auto |
| TP-010 | Data isolation: User from Team A queries Team B inspection | No cross-team access; denial visible in logs | P1 | Auto |
| TP-011 | Recovery drill: Restore staging backup on clean infrastructure | Data and audit records reconcile; recovery evidence retained | P1 | Manual |
| TP-012 | Performance smoke: Simulate 100 virtual users for 15 minutes | API p95 <= 800ms for scoped endpoints, error rate <1% | P2 | Auto |

These scenarios are examples, not a complete suite.

## 6. Non-functional verification

Illustrative targets, **not agreed criteria**: selected API p95 <= 800 ms at representative load; no lost accepted writes during restart; queued offline records survive a 24-hour partition; no privilege escalation; WCAG 2.2 AA on core tasks; fresh restore within 4 hours, with data reconciliation.

## 7. Test data and evidence

Use synthetic data for distinct roles, teams, version conflicts, image types and UTC time boundaries. Attach build SHA, configuration fingerprint, results, redacted traces, defect IDs and retest reports to each release run. Never publish secrets or real personnel records.

## 8. Defects and release exit

S1 and S2 defects block release unless the agreed governance process specifically permits a documented exception. For this sample release, all P1 scenarios must pass; no open S1/S2; relevant requirements trace to executed tests; offline replay, authorization and recovery drills complete; rollback and business ownership are accepted.

## 9. Four-week illustrative execution window

- Week 1: Preparation, fixtures, environment smoke tests.
- Week 2: API integration, E2E and regression.
- Week 3: Resilience, security and business UAT.
- Week 4: Defect retest, evidence reconciliation and final go/no-go.

Development owns code and automated checks; QA owns test execution evidence; platform and security own operational verification; product owner owns formal UAT acceptance. Carlo Hennsa is the example plan author and reviewer, not automatically the final approval authority.

## 10. Control and reuse

Use **Carlo Technical Document Style v1.1**, with a navy cover, numbered sections, side navigation and A4 print styles. In real engagements replace all fictional names, requirements, targets and owners with approved evidence. The HTML is the visual master; Markdown is a machine-friendly content example; PDF is the print export.