Master Test Plan and QA Strategy

Neemias

1. Purpose

This Master Test Plan defines how Neemias requirements are verified before and during implementation. It translates product and system requirements into test suites, repeatable test cases, environments, and release gates.

2. References

• PRD: PRD
• SRS: SRS
• SDD: SDD
• Requirement Traceability Matrix: RTM

3. Scope

In scope:

• Functional behavior across all defined roles.
• Offline-resilient workflows (backend-primary with IndexedDB fallback) and deferred synchronization.
• Conflict resolution and audit-history retention.
• Session expiration and re-authentication paths.
• LGPD-related controls and role-based data access.
• WCAG Level AA accessibility validation.
• Localization defaults for Brazilian Portuguese.

Out of scope for this baseline:

• High-scale load testing beyond 3 to 5 active users.
• Provider-specific infrastructure tests.
• Native mobile platform tests.

4. Quality Goals

• 100 percent SRS requirement coverage through mapped test cases.
• Zero Critical defects open at release gate.
• Zero High defects open in security, data integrity, and sync conflict domains.
• All mandatory accessibility checks pass for WCAG Level AA.
• No test evidence of silent data loss in offline or conflict scenarios.

5. Test Levels and Strategy

• Unit tests: domain rules, role checks, validation, conflict policy, schema validation.
• Integration tests: local storage plus sync engine plus auth/session interactions.
• System tests: end-to-end workflows for each role across online and offline states.
• Security and compliance tests: session TTL behavior, protected action gating, encryption controls, audit logging.
• Accessibility tests: automated scans and manual keyboard and screen-reader checks.
• Regression tests: smoke path plus high-risk suites on each candidate release.

6. Test Environment Strategy

Baseline environment matrix:

• Desktop browsers: Chrome, Edge, Firefox.
• Mobile browsers: Chrome Android, Safari iOS.
• Network profiles: online, offline, unstable, high latency.
• Time control: fake clock injection for session and token TTL tests.
• Storage pressure simulation: browser quota pressure and persistence API checks.

Environment requirements:

• Stable test seed data for users, students, and event history.
• Isolated test accounts for each role.
• Deterministic server clock for conflict and TTL verification.

7. Entry and Exit Criteria

Entry criteria:

• Feature requirements mapped in RTM.
• Test data fixtures available.
• Test environment healthy.

Exit criteria:

• All Critical and High suites passed.
• No unresolved blocker defects.
• Requirement coverage report generated and signed off.
• Accessibility checklist completed.

8. Defect Severity Model

• Critical: data loss, unauthorized access, broken conflict policy, compliance breach.
• High: blocking business flow, incorrect sync outcome, missing deletion justification control.
• Medium: non-blocking behavior mismatch, recoverable UI state issue.
• Low: cosmetic issues and non-blocking wording or layout defects.

9. Priority Test Suites

9.1 Suite A: Sync and Conflict Resolution

Coverage IDs: FR-015, SR-001, SR-002, SR-003, SR-004, SR-005, NFR-006, NFR-012

TC-CONFLICT-001: Offline Admin versus Offline Roll-caller Conflict

Objective:

• Prove admin precedence over lower-privilege conflicting actions.

Preconditions:

• Student S-100 exists and is active.
• Device A logged in as Roll-caller.
• Device B logged in as Admin user.
• Both devices have latest synced state.

Steps:

1. Turn off Wi-Fi on Device A and Device B.
2. On Device A, mark student S-100 as PRESENT.
3. On Device B, delete student S-100 with valid justification text.
4. Turn on Wi-Fi for Device A, wait until sync attempt completes.
5. Turn on Wi-Fi for Device B, wait until sync attempt completes.

Expected results:

• Final authoritative state reflects Admin deletion.
• Roll-caller attendance action is retained in history but superseded.
• Conflict outcome is visible to user with clear state feedback.
• Audit history contains both events with actor, role, and timestamps.

Evidence to capture:

• Sync logs for both devices.
• Event timeline with conflict markers.
• UI notification for superseded event.

TC-CONFLICT-002: Non-admin versus Non-admin Conflict

Objective:

• Validate non-admin conflict policy.

Policy baseline:

• Last write wins by server timestamp.

Expected results:

• Newest server timestamp determines active attendance state.
• Both conflicting events remain in history.

9.2 Suite B: Session TTL and Offline Preservation

Coverage IDs: FR-016, FR-017, SCR-001, SCR-002, SCR-003, SCR-004

TC-TTL-001: 24-hour Session Expiration without Waiting 24 Hours

Objective:

• Validate expiration and re-auth behavior using deterministic time control.

Time-travel strategy:

• Session module must consume a clock abstraction, not direct system time.
• Test harness injects fake clock and advances time instantly.
• Backend validation endpoint also uses test-controlled token issue and expiry values.

Preconditions:

• User has valid session with queued offline action.
• Fake clock initialized at token issue time.

Steps:

1. Disconnect network.
2. Create attendance action while offline.
3. Advance fake clock by 23 hours and verify action submission remains blocked only by offline state.
4. Advance fake clock to 24 hours plus 1 minute.
5. Attempt protected submission.
6. Reconnect network.
7. Verify app prompts re-authentication before submission.
8. Re-authenticate successfully.
9. Submit queued actions.

Expected results:

• Unsynced queue is preserved across expiry.
• User has local read-only access after expiry.
• Protected submission is denied until re-authentication succeeds.
• After re-authentication, queued actions sync without loss.

Evidence to capture:

• Queue snapshot before and after expiry.
• Auth gate logs and prompt screenshots.
• Post-sync event consistency report.

9.3 Suite C: Storage Persistence and Eviction Resilience

Coverage IDs: NFR-005, NFR-006, NFR-007, NFR-012

TC-STORAGE-001: Storage Eviction Pressure with Persistent Storage

Objective:

• Verify storage persistence requests and behavior under quota pressure.

Preconditions:

• App requests persistent storage via navigator.storage.persist where supported.
• Test browser profile with controlled quota behavior.

Steps:

1. Install app and sync baseline student dataset plus photos.
2. Confirm persistent storage grant status.
3. Fill origin storage close to quota using test payloads.
4. Force browser restart and reload app offline.
5. Validate IndexedDB stores and queued actions remain intact.
6. Continue pressure cycle with additional writes.
7. Reopen app and verify critical stores are still readable.

Expected results:

• Persistence request state is recorded.
• No silent deletion of IndexedDB data in the protected profile scenario.
• If eviction occurs in non-protected scenario, app detects and reports recovery-required state clearly.

Evidence to capture:

• Persistence API status log.
• IndexedDB store inventory before and after pressure.
• User-facing recovery message screenshot if relevant.

9.4 Suite D: Deletion Justification and Audit

Coverage IDs: FR-007, DR-003, DR-004, SCR-007

Core checks:

• Non-admin delete attempt is denied and audited.
• Admin delete without justification is blocked.
• Admin delete with justification 10 to 500 chars succeeds.
• Historical records remain available after soft deletion.

9.5 Suite E: Search and Immediate Photo Feedback

Coverage IDs: FR-010, FR-011, FR-012, NFR-003, NFR-004

Core checks:

• Matching student photo appears immediately in search results.
• Cached photo rendering works offline.
• Fallback visuals appear if photo asset is unavailable.

9.6 Suite F: Accessibility and UX Feedback

Coverage IDs: FR-021, FR-022, NFR-001

Core checks:

• Keyboard-only workflow for login, search, attendance mark, and deletion confirmation.
• Screen-reader labels and announcement of success and error states.
• Double-check confirmation shown before all user-visible data changes.
• Contrast and focus indicators satisfy WCAG AA.

9.7 Suite G: User Management and Security

Coverage IDs: FR-NEW-01, FR-NEW-02, FR-NEW-03, FR-NEW-04, FR-NEW-05, FR-NEW-06, FR-NEW-07, FR-NEW-08, FR-NEW-09, SCR-NEW-01

Core checks:

• Admin can list all users and create/edit/deactivate/reset password.
• Username uniqueness and format validation is enforced.
• Deactivated users cannot authenticate.
• Self-deactivation and last-active-admin deactivation are blocked in service layer.
• Every user action creates append-only UserEvent records.
• Passwords are stored only as SHA-256 hashes and never as plaintext.

10. Regression and Release Gates

Regression set per build:

• Smoke path by role.
• Sync path online and offline.
• Session expiry plus re-auth path.
• Deletion with and without justification.
• Accessibility quick audit.

Release gate:

• All Priority suites pass.
• Risk log reviewed.
• Coverage report matches RTM.

11. Test Data Baseline

Users:

• 1 Roll-caller
• 1 Report user
• 1 Data entry
• 1 Admin user

Students:

• Minimum 50 students with mixed names and photo states.

Events:

• Seeded attendance and student lifecycle events for history and report checks.

12. Deliverables

• Test case set and execution records.
• Defect log with severity and requirement linkage.
• Requirement coverage report.
• Accessibility verification checklist.
• Final QA signoff summary.