JobcardSystem/docs/uat-checklist.md

JOBcard UAT checklist

Run this checklist against a production-like deployment over HTTPS with a fresh backup available. Record the date, application version, PHP/MariaDB versions, tester and evidence for each item. Do not record passwords, API keys or credential values in the evidence.

Pre-flight and deployment

• The virtual host/document root is public/; the repository root, .env, SQL files and storage/ are not web-accessible.
• .env is present outside the public root, has restrictive permissions (for example chmod 600 .env), and contains production-only values.
• php bin/healthcheck.php passes with no secret values printed.
• HTTPS is enabled and HTTP redirects to HTTPS; the certificate and hostname are valid.
• A backup was taken before UAT and its location/time is recorded separately from this checklist.

Administrator

• Sign in with the bootstrap Administrator account; invalid credentials are rejected.
• The dashboard loads and the Administrator can view clients, jobcards, SLA data, reports and audit events.
• Create, deactivate and reactivate a test Accounts user and a test Technician user.
• Assign roles/permissions; verify an unauthorized permission is not granted by merely hiding a navigation link.
• Assign a Technician to a test jobcard and verify the assignment is visible in the expected workflow.
• Review audit events for login and test administrative changes; confirm timestamps and actor are present.
• Verify sensitive credentials are masked by default, access is permission-controlled, and reveal/access is audited (where that module is enabled).

Accounts

• Create and edit a client, including contact details and preferred contact method.
• Add a primary contact and verify duplicate primary contacts are rejected.
• Create a jobcard with client, priority and requested work; verify its reference number and initial status.
• Assign a Technician, update the jobcard through the supported statuses, and verify status history.
• Configure an SLA agreement and verify allocated/used/remaining hours and period boundaries.
• View reports and export a report if permitted; verify exported data contains only intended fields and no internal notes or credentials.
• Verify validation errors are understandable and do not discard unrelated entered fields.

Technician

• Sign in as a Technician and verify only assigned jobcards are accessible.
• Verify a Technician cannot access another Technician's jobcard by changing an ID in the URL or form payload.
• View assigned work, update allowed status/work fields, and add technician notes.
• Record a valid time entry and verify hours and SLA usage update correctly.
• Verify invalid, negative, overlapping or unauthorized time-entry cases are rejected according to the configured rules.
• Verify internal notes, credentials, user administration and unrestricted reports are not exposed to Technician accounts.

Security and recovery

• Invalid and expired sessions redirect to login; logout invalidates the session.
• Verify CSRF protection rejects missing or invalid tokens on every state-changing form.
• Verify output escaping with a test value containing HTML/script characters; no script executes.
• Verify prepared statements/parameterized inputs by testing quote and SQL-like characters in names, notes and searches.
• Confirm login/session cookies use Secure, HttpOnly and SameSite settings appropriate to the deployment.
• Confirm production error responses do not disclose stack traces, SQL, filesystem paths or secrets; server logs are access-controlled.
• Confirm .env, backups and uploaded files cannot be downloaded through the web server.
• Verify brute-force/rate-limit and account deactivation controls if configured by the host/application.

Reports

• Run reports for an empty date range, a normal range and a boundary date; totals are deterministic and timezone expectations are documented.
• Verify role-specific report visibility and filters; direct URL access cannot bypass authorization.
• Verify CSV/other exports handle commas, quotes, line breaks and formula-like values safely.
• Compare a report total with the underlying test jobcards/time entries and retain the comparison evidence.

Restore verification

• Restore the pre-UAT backup to a separate database/server, never over the live database.
• Apply the documented upgrade (database/upgrade.sql, if the restored installation predates the current schema) and record the command/output.
• Run php bin/healthcheck.php against the restored configuration; do not paste secret values into evidence.
• Log in to the restored system using a test account and verify clients, jobcards, time entries, reports and audit history are present.
• Verify restored uploads/attachments and permissions, if that module is enabled.
• Record restore duration, backup timestamp, row/data spot checks and any missing items.
• Confirm the live system was not modified by restore testing and securely remove the temporary restored copy when approved.

Sign-off

• Environment/version: ______________________________
• Backup reference: __________________________________
• Tester/date: _______________________________________
• Defects and follow-up owner: _______________________
• UAT result: [ ] Pass [ ] Pass with follow-up [ ] Fail