Test Execution Handbook

Neemias

1. Purpose

This handbook converts test strategy into execution rules for contributors.

Use this with:

• mtp.md
• ../../RTM.csv
• ../architecture/srs.md

2. Scope

Applies to:

• unit, integration, and system test execution
• accessibility and compliance verification steps
• release-gate evidence requirements

3. Requirement Traceability Rule

Every behavior-changing PR should reference affected requirement IDs and test IDs.

Minimum PR traceability:

• Requirement IDs from ../architecture/srs.md
• Test case IDs in PR summary
• ../../RTM.csv updates when mappings change

4. Test ID Naming

Use stable IDs:

• TC-RBAC-###
• TC-ATT-###
• TC-STU-###
• TC-SYNC-###
• TC-CONFLICT-###
• TC-TTL-###
• TC-A11Y-###
• TC-SEC-###
• TC-COMP-###
• TC-PERF-###

5. Planned Test Structure for Implementation

When code scaffold is introduced, follow this structure:

• tests/unit/
• tests/integration/
• tests/system/
• tests/accessibility/
• tests/security/
• tests/fixtures/

Note:

Tooling commands are intentionally not fixed in this document until the implementation stack is finalized.

6. Execution Order by Risk

Run tests in this order when validating release candidates:

1. Authentication and role gating (SCR-001, SCR-002, FR-001 to FR-008)
2. Offline queueing and sync conflict rules (FR-014, FR-015, SR-001 to SR-005)
3. Data integrity and audit retention (DR-001 to DR-005)
4. Deletion justification and admin-only constraints (FR-007, SCR-007)
5. Accessibility and UX confirmation (NFR-001, FR-021, FR-022)
6. Localization and defaults (FR-019, FR-020)

7. Evidence Requirements

Each executed test cycle should capture:

• timestamp and environment profile
• test ID and requirement mapping
• pass or fail result
• logs and screenshots for failures
• defect ticket reference for failures

Mandatory artifact groups:

• conflict resolution evidence
• session expiry and re-auth evidence
• deletion justification evidence
• accessibility quick-audit evidence

8. Defect Triage Rules

Severity follows mtp.md:

• Critical: security breach, data loss, conflict rule break, compliance breach
• High: blocked business flow, incorrect sync outcome
• Medium: recoverable behavior mismatch
• Low: cosmetic and wording issues

Gate policy:

• no open Critical defects for release
• no open High defects in security, sync, or data integrity domains

9. Manual Accessibility Checklist (Minimum)

For each major flow (login, attendance, students, deletion, reports):

• full keyboard traversal
• visible focus indicator
• semantic labels for controls
• error association to fields
• non-color-only status cues
• screen-reader announcement for success and failure states

10. Session and Time-Travel Testing

Session expiry tests should use deterministic time controls where available.

Requirements:

• do not wait real 24 hours in tests
• advance clock abstraction in test harness
• verify unsynced queue remains intact across expiry
• verify protected submission blocked until re-authentication

11. Release Candidate Checklist

Before release candidate signoff:

• requirement coverage report generated against ../../RTM.csv
• priority suites in mtp.md executed
• unresolved risks documented
• accessibility checklist completed
• decision-impacting findings reflected in ../architecture/adr/ when needed

12. Ownership and Updates

Contributors updating requirements or architecture must update this handbook if execution expectations change.

Do not leave process-critical changes undocumented.