FS-DOC-06Quality
Test and QA Plan
Workplace Incident Reporting
[YourCompany.com] · HR Department · Prepared by FullSpec · [Today's Date]
This document defines every test case the FullSpec team runs before the Workplace Incident Reporting automation goes live. It is organised into three sequential phases: unit testing of each individual agent, integration and edge-case testing across agent handoffs and failure conditions, and a final end-to-end production run with the process owner. No phase begins until the previous phase has fully passed. All test IDs carry forward across phases so every case is uniquely traceable in the test log.
01Testing approach
Testing runs in three phases in strict sequence. No phase begins until every test case in the previous phase carries a Pass status and any related bugs are resolved and re-tested. Phase 1 isolates each agent. Phase 2 tests handoffs between agents and exposes edge-case behaviour. Phase 3 is the single production run that confirms the live environment behaves identically to sandbox.
1Phase 1: Unit Testing
Each agent tested independently in sandbox
Scope
Incident Intake Agent, Notification and Escalation Agent, and Investigation and Corrective Action Agent tested individually. No cross-agent calls during this phase.
Environment
Sandbox only. Sandbox Google Form, Sheets, Slack workspace, Notion workspace, Gmail alias, and BambooHR sandbox account.
Credential rule
Sandbox credentials exclusively. No production API keys, no real employee records, no live Slack channels.
Pass condition
All cases T01 through T14 return the expected output with no errors. Any failure blocks progression to Phase 2.
Who runs it
FullSpec team. Process owner is not required for Phase 1.
2Phase 2: Integration and Edge-Case Testing
Agent handoffs and failure scenarios in sandbox
Scope
End-to-end agent handoffs: Intake to Notification, Notification to Investigation. Plus targeted edge-case scenarios covering duplicates, missing data, unavailable tools, and human timeout.
Environment
Sandbox only. Cross-agent data flow tested with synthetic incident payloads of each severity type.
Credential rule
Sandbox credentials only. Simulated tool outages achieved by temporarily revoking sandbox OAuth tokens, not production tokens.
Pass condition
All cases T15 through T22 and E01 through E06 return the expected output. Edge cases must produce the correct fallback behaviour, not a silent failure.
Who runs it
FullSpec team. Process owner is not required for Phase 2.
3Phase 3: End-to-End Production Test
Live environment verified with process owner present
Scope
Full production workflow from a real Google Form submission through to closure confirmation email and Google Sheets status update. One complete run per severity level (minor, moderate, serious).
Environment
Production. Live credentials, live Slack channels, live BambooHR account, live Notion workspace. Test records voided after each run.
Credential rule
Production credentials active. FullSpec team accesses only through agreed service accounts. No direct access to employee personal data beyond the test record.
Pass condition
All cases T23 through T27 pass. Process owner confirms expected outputs in each live tool. Owner sign-off recorded as the final test case (T27) in the FullSpec confirmation log.
Who runs it
FullSpec team executes. Process owner (HR Manager) is present and confirms outputs in Slack, Notion, Gmail, BambooHR, and Google Sheets.
Test and QA PlanPage 1 of 4
FS-DOC-06Quality
02Phase 1 — unit test cases
All Phase 1 tests run against sandbox credentials only. Do not use production API keys, real employee names, real Slack channels, or the live BambooHR account during this phase. Use the dedicated sandbox Google Form URL and the test Sheets tab named SANDBOX-REGISTER.
Incident Intake Agent — reads Google Form responses, classifies severity, assigns reference numbers, and writes structured rows to the incident register. Estimated build time: 8 hours. Complexity: Moderate.
ID
Scenario
Input
Expected Output
Pass Criteria
T01
Happy path: minor incident
Form submission: slip and fall, no injury, near-miss only, employee name and department populated
New row in SANDBOX-REGISTER with severity = Minor, reference number in format INC-YYYYMMDD-001, timestamp within 30 seconds of submission
Row exists, severity field = Minor, ref number matches format, all required columns populated
T02
Happy path: moderate incident
Form submission: laceration requiring first aid, injury confirmed, department and manager field populated
Row written with severity = Moderate, injury flag = true, correct department and manager extracted
Severity = Moderate, injury_flag = TRUE in Sheets row, manager field not blank
T03
Happy path: serious incident
Form submission: hospitalisation required, lost time injury, all fields completed
Row written with severity = Serious, escalation_required = true, reference number assigned
Severity = Serious, escalation_required = TRUE, ref number unique and sequential
T04
Duplicate form submission within 60 seconds
Identical form payload submitted twice within one minute
Only one row written; second submission flagged as duplicate in the Sheets log column
Exactly one data row; duplicate_flag column = TRUE on the second attempt row (or second submission silently suppressed with log entry)
T05
Missing mandatory field: incident description blank
Form submitted with description field empty
Row not written to register; error entry created in SANDBOX-ERROR-LOG with field name and timestamp
No data row in SANDBOX-REGISTER; error log entry present with field = description
T06
Severity classification ambiguity: description matches two severity levels
Free-text description: 'employee felt dizzy, sat down, resumed work after 10 minutes, no medical attention'
Agent classifies as Moderate (conservative rule: any health symptom without injury = Moderate); human_review_flag = TRUE
Severity = Moderate, human_review_flag = TRUE in Sheets row
T07
Google Form webhook does not fire (simulated platform timeout)
Sandbox trigger suppressed for 90 seconds then released
Agent picks up backlogged payload within 120 seconds of the trigger firing; no data loss
Row written within 120 seconds of trigger release; no duplicate rows
Notification and Escalation Agent — routes Slack notifications to the correct manager or operations director based on department and severity. Estimated build time: 5 hours. Complexity: Simple.
ID
Scenario
Input
Expected Output
Pass Criteria
T08
Happy path: minor incident, single manager notification
Incident row in Sheets: severity = Minor, department = Warehouse, manager = sandbox-manager-1
Slack DM sent to sandbox-manager-1 with incident reference, severity label, and summary within 60 seconds of row creation
Slack DM received by sandbox-manager-1; message contains ref number and severity; no message sent to ops director
T09
Happy path: serious incident, dual notification
Incident row: severity = Serious, department = Retail Floor, manager = sandbox-manager-2
Slack DM sent to sandbox-manager-2 AND Slack DM sent to sandbox-ops-director; notification log row written to Sheets
Both sandbox accounts receive DMs; notification_log column in Sheets shows two recipients and timestamps
T10
Manager field blank in incident row
Incident row: department = Logistics, manager field empty
Notification sent to department fallback channel (#logistics-alerts); alert also sent to HR Slack channel flagging missing manager field
Message arrives in #logistics-alerts; separate alert in #hr-incidents with warning text referencing missing manager
T11
Slack API rate limit hit (simulated)
Sandbox Slack token throttled to return 429 for first two attempts
Agent retries with exponential backoff (2 s, 4 s); message delivered on third attempt; retry count logged
Message eventually delivered; retry_count column in notification log = 2 or 3; no duplicate messages
T12
Invalid Slack user ID in manager field
Manager field contains a deactivated sandbox user ID
Message delivery fails gracefully; error entry in SANDBOX-ERROR-LOG; fallback alert sent to #hr-incidents
No unhandled exception; error log entry present; fallback message in #hr-incidents
Investigation and Corrective Action Agent — creates Notion investigation pages, sends Gmail deadline reminders, monitors corrective action status, and updates BambooHR for injury incidents. Estimated build time: 9 hours. Complexity: Complex.
ID
Scenario
Input
Expected Output
Pass Criteria
T13
Happy path: Notion task created with all fields
Confirmed Sheets row: severity = Moderate, manager = sandbox-manager-1, injury_flag = FALSE
Notion page created in SANDBOX-INVESTIGATIONS database with: incident reference, severity, assigned manager, due date = today + 5 business days, status = Open
Notion page exists; all five required fields populated; due date calculated correctly
T14
BambooHR update for injury incident
Sheets row: severity = Serious, injury_flag = TRUE, employee_id = SBX-EMP-001
BambooHR sandbox record for SBX-EMP-001 updated with: incident_date, incident_type = Injury, incident_reference
BambooHR GET /v1/employees/SBX-EMP-001 returns updated custom fields; no other employee records modified
Test and QA PlanPage 2 of 4
FS-DOC-06Quality
03Phase 2 — integration and edge case tests
Phase 2 validates data flowing correctly across all three agent boundaries and confirms the automation handles real-world failure conditions without silent data loss or unhandled exceptions.
ID
Scenario
Input
Expected Output
Pass Criteria
T15
Intake to Notification handoff: minor incident full chain
New sandbox Form submission: severity triggers Minor classification
Intake Agent writes row; Notification Agent picks up new row event within 30 seconds and sends manager DM
Sheets row exists AND Slack DM received within 90 seconds of form submission; no manual intervention required
T16
Intake to Notification handoff: serious incident dual escalation
New sandbox Form submission: severity triggers Serious classification, injury_flag = TRUE
Intake Agent writes row with escalation_required = TRUE; Notification Agent sends DMs to both sandbox-manager and sandbox-ops-director
Both Slack DMs received; notification log shows two recipients; escalation_required column = TRUE in Sheets
T17
Notification to Investigation handoff: Notion task created after Slack send
Confirmed Sheets row from T16
Investigation Agent triggers after Notification Agent completes; Notion page created within 60 seconds of Sheets row confirmation
Notion page present with correct fields; creation timestamp within 60 seconds of Sheets row timestamp
T18
Gmail reminder fires when Notion task not updated by deadline
Notion sandbox page: status = Open, due_date = today minus 1 day (past deadline)
Gmail reminder sent from sandbox Gmail alias to sandbox-manager-1 with direct Notion page link; reminder_sent flag updated in Sheets
Email received in sandbox inbox; Notion URL in email body is correct and opens the right page; reminder_sent = TRUE in Sheets
T19
BambooHR update fires only for injury incidents
Two simultaneous sandbox rows: one injury_flag = TRUE, one injury_flag = FALSE
BambooHR update runs for the injury row only; no BambooHR call made for the non-injury row
BambooHR sandbox log shows exactly one API call; non-injury employee record unchanged
T20
Closure email sent after HR marks incident closed in Notion
Notion page status changed to Closed by sandbox HR user
Automation sends Gmail closure confirmation to sandbox reporter email; Google Sheets row status updated to Closed
Email received; Sheets row status = Closed; closure_timestamp populated
T21
Repeat reminder: Notion task still open 48 hours after first reminder
Notion page: status = Open, first_reminder_sent = TRUE, due_date = 2 days ago
Second Gmail reminder sent; escalation DM sent to sandbox-ops-director in Slack; second_reminder_sent flag set in Sheets
Two emails in sandbox inbox; Slack DM to ops director present; second_reminder_sent = TRUE
T22
Full chain timing: form submission to all outputs in under 3 minutes
Single sandbox Form submission: moderate severity, injury_flag = FALSE
Sheets row written, Slack DM sent, Notion page created: all within 3 minutes of form submission
Timestamp delta between form submission and Notion page creation is less than 180 seconds
Edge-case tests cover conditions outside the normal flow: duplicate submissions, missing required data, tool unavailability, and human timeout. These must all produce a defined, logged fallback outcome.
ID
Scenario
Input
Expected Output
Pass Criteria
E01
Duplicate reference number generated (collision)
Two form submissions within the same second on the same date
Sequential counter appended: INC-YYYYMMDD-001 and INC-YYYYMMDD-002; no overwrite of existing row
Two distinct rows in Sheets; reference numbers unique; no data from submission 1 overwritten
E02
Form submitted with no employee name
employee_name field blank; all other fields complete
Row written with employee_name = UNKNOWN; human_review_flag = TRUE; Slack alert to #hr-incidents noting missing name
Row exists with UNKNOWN value; review flag = TRUE; Slack alert received
E03
Notion API unavailable for 10 minutes (simulated 503)
Investigation Agent triggers; Notion returns 503 for all requests
Agent retries every 2 minutes up to 5 attempts; after final failure, error logged to SANDBOX-ERROR-LOG and Slack alert sent to #hr-incidents
Five retry attempts visible in execution log; error log entry present; Slack alert received; no Notion page created silently
E04
BambooHR employee ID not found in sandbox
Sheets row: injury_flag = TRUE, employee_id = SBX-EMP-999 (does not exist)
BambooHR API returns 404; error logged with employee_id and incident reference; Slack alert to #hr-incidents; no crash
Error log entry present; Slack alert received; automation continues to next step without halting
E05
Manager does not respond to Notion task within agreed SLA (7 days)
Notion page: status = Open, created_date = 7 days ago, no updates
Escalation DM sent to sandbox-ops-director; escalation_flag = TRUE in Sheets; third Gmail reminder sent to manager
Ops director DM received; escalation_flag = TRUE; third email in sandbox inbox
E06
Incident description contains special characters or emoji
Free-text description field: 'Slip near exit door \u2014 employee OK 👍 no injury'
Field sanitised before writing to Sheets; emoji stripped or encoded; no row write failure; description stored legibly
Sheets row written without error; description column contains readable text; no formula injection in cell
Test and QA PlanPage 3 of 4
FS-DOC-06Quality
04Phase 3 — end-to-end production test
Important before running Phase 3: use the internal test email address (test-incident@[YourCompany.com]) as the reporter address on every production test submission. Use a clearly labelled test employee record in BambooHR (name: TEST RECORD, do not use a real employee). After each test run, void the Notion page by marking it Voided, delete or archive the Sheets row, and confirm with the FullSpec team that the BambooHR test record is reset. Never submit a production test using a real employee name, a live manager who has not been briefed, or a Slack channel that is not monitored during the test window.
Phase 3 runs in the live production environment with all real credentials active. The process owner (HR Manager) is present and confirms expected outputs in each tool. Three severity variants are tested. All test IDs continue from the Phase 2 sequence.
ID
Scenario
Input
Expected Output
Pass Criteria
T23
Production run: minor incident, full chain
Live Google Form submitted with test-incident@[YourCompany.com] as reporter; severity = Minor; injury_flag = FALSE
Sheets row written with correct severity and reference number; manager Slack DM received; Notion investigation page created; no BambooHR call
Process owner confirms: Sheets row present, Slack DM received by correct manager, Notion page exists with correct fields and deadline
T24
Production run: serious incident, dual escalation confirmed live
Live Form submission: severity = Serious; injury_flag = TRUE; department = pre-agreed test department
Sheets row with escalation_required = TRUE; Slack DM to line manager AND ops director; Notion page created; BambooHR TEST RECORD updated
Process owner confirms: both Slack DMs received; BambooHR TEST RECORD shows incident_date, incident_type, and reference number; Notion page open
T25
Gmail reminder fires on missed deadline in production
Notion production test page: due_date manually set to yesterday; status = Open
Gmail reminder sent from production Gmail alias to test-incident@[YourCompany.com] with Notion link; reminder_sent = TRUE in Sheets
Email received in test inbox within 5 minutes of trigger check cycle; Notion URL resolves correctly; Sheets flag updated
T26
Error log verification: simulated field validation failure in production
Live Form submitted with description field blank
Row not written to production register; error entry created in PRODUCTION-ERROR-LOG sheet tab with timestamp and field name; Slack alert to #hr-incidents
No data row in production register; error log tab entry present; Slack alert visible to process owner in #hr-incidents
T27
Process owner review and approval: full end-to-end sign-off
Process owner reviews outputs from T23, T24, T25, T26 across Google Sheets, Slack, Notion, Gmail, and BambooHR
Process owner confirms all outputs match expectations; FullSpec team records approval in the FullSpec confirmation log with owner name, date, and outcome for each case
FullSpec confirmation log entry marked Complete with process owner name and date. All previous Phase 3 cases marked Pass. Automation cleared for go-live. No separate sign-off block required.
After T27 is recorded as Complete in the FullSpec confirmation log, the FullSpec team will notify the process owner at support@gofullspec.com with a go-live clearance summary. Any case that does not pass in Phase 3 is logged as a defect, assigned a severity (Critical, High, or Low), fixed in the staging environment, and re-tested from the affected case ID before the go-live date is confirmed.
Test and QA PlanPage 4 of 4