Back to Leave & Absence Management

Test and QA Plan

How the build is validated before go-live: three sequential test phases, edge cases, and production verification.

4 pagesPDF · Quality
FS-DOC-06Quality

Test and QA Plan

Leave and Absence Management

[YourCompany.com] · HR Department · Prepared by FullSpec · [Today's Date]

This document defines every test case the FullSpec team will execute before the Leave and Absence Management automation is handed over for production use. It is organised into three sequential phases: unit testing of each agent in isolation, integration and edge-case testing across agent handoffs and failure scenarios, and a final end-to-end production run with process owner sign-off. No phase begins until the previous phase achieves a full pass. The process owner joins Phase 3 only; all earlier phases are run entirely by the FullSpec team in sandbox environments.

01Testing approach

Testing runs in three sequential phases. Each phase must fully pass before the next begins. A single failing test case blocks progression; it must be resolved, retested, and confirmed green before the phase is marked complete. This sequencing ensures that integration and end-to-end tests are always built on a verified foundation.

1
Phase 1 — Unit Testing
Each agent tested in isolation against sandbox credentials
Scope
Each of the three agents tested independently: Leave Intake and Balance Agent, Approval Routing Agent, Post-Approval Sync Agent.
Environment
Sandbox only. BambooHR sandbox account, Gusto demo environment, Google Calendar test calendar, Slack test workspace, Gmail test account.
Credential rule
No production credentials may be used. All API keys, OAuth tokens, and bot tokens must reference sandbox or developer-tier accounts.
Pass condition
All cases T01 through T15 return the expected output with no errors logged. Zero failures permitted to advance.
Who runs it
FullSpec team only. Process owner not present.
2
Phase 2 — Integration and Edge Case Testing
Agent handoffs and exception scenarios validated
Scope
End-to-end handoffs between all three agents, plus edge cases covering duplicates, missing data, unavailable tools, and manager timeout.
Environment
Sandbox only. Same isolated credentials as Phase 1. No production data introduced.
Credential rule
Sandbox credentials only. Any test that touches Slack must use the test workspace bot token, not the production Slack app.
Pass condition
All integration cases T16 through T22 pass, and all edge cases E01 through E07 return the expected error handling or fallback behaviour.
Who runs it
FullSpec team only. Process owner not present.
3
Phase 3 — End-to-End Production Test
Live environment, real tools, process owner review and sign-off
Scope
One complete leave request traced from form submission through to all downstream record updates in BambooHR, Gusto, Google Calendar, and Slack.
Environment
Production. Real BambooHR account, live Gusto environment, production Google Calendar, production Slack workspace, and production Gmail.
Credential rule
Production credentials are permitted for this phase only. The test record must use a designated internal test employee. All test records must be voided after sign-off.
Pass condition
All cases T23 through T26 pass, including the final process owner approval case T26. FullSpec records sign-off in the confirmation log.
Who runs it
FullSpec team leads execution. Process owner joins to review outputs and complete the final approval case (T26).
Test and QA PlanPage 1 of 4
FS-DOC-06Quality

02Phase 1 — unit test cases

Sandbox credentials only for all Phase 1 tests. Do not connect to production BambooHR, Gusto, Slack, Google Calendar, or Gmail accounts at any point during this phase. Use dedicated sandbox API keys stored in the test environment variable file. Any test that inadvertently writes to a production system must be flagged immediately to the FullSpec team lead and retested from scratch.

Leave Intake and Balance Agent — this agent receives the submitted form payload, queries BambooHR for leave balance, and checks Google Calendar for coverage conflicts. Test cases cover the happy path, insufficient balance, and calendar conflict detection.

ID
Scenario
Input
Expected Output
Pass Criteria
T01
Happy path: valid request, sufficient balance, no conflicts
Employee ID: E001, leave type: Annual, start: +14 days, duration: 3 days, balance: 12 days
Validated request summary with balance status: sufficient, conflict flag: none
Output JSON contains balance_ok: true, conflict: false, routed_to_approval: true
T02
Insufficient leave balance
Employee ID: E002, leave type: Annual, duration: 5 days, balance: 2 days
Request rejected at intake; employee notified via Gmail of insufficient balance
Output contains balance_ok: false, workflow halts, Gmail decline email dispatched
T03
Team coverage conflict detected
Employee ID: E003, dates overlap with two existing approved absences in team calendar
Conflict flag set to true; request summary includes conflict_detail listing overlapping events
conflict: true present in payload; summary routed to manager with conflict warning included
T04
BambooHR API returns 401 Unauthorised
Valid form payload but BambooHR sandbox token expired
Workflow pauses; error logged with code 401 and step reference; FullSpec alert triggered
Error log contains source: BambooHR, code: 401; workflow does not proceed; alert confirmed
T05
Google Calendar API timeout
Valid form payload; Calendar API response delayed beyond 10-second threshold
Timeout caught; workflow retries once after 30 seconds; if second attempt fails, error logged and request held
Retry logic executes once; on second failure error is logged and request status set to: held_pending_calendar_check
T06
Leave type not in BambooHR policy list
Employee submits leave type: Study Leave which is not configured in BambooHR
Validation error returned; workflow halts; HR notified of unrecognised leave type via Gmail
Output contains validation_error: unrecognised_leave_type; Gmail notification dispatched to HR inbox

Approval Routing Agent — this agent receives the validated request summary and sends a structured Slack message to the line manager with approve/decline buttons. Test cases cover the happy path, decline path, and Slack delivery failure.

ID
Scenario
Input
Expected Output
Pass Criteria
T07
Happy path: Slack message delivered and manager approves
Validated request payload with balance_ok: true, conflict: false
Slack interactive message sent to manager; manager clicks Approve; outcome logged with timestamp and manager identity
Slack message delivered (HTTP 200); approval recorded with manager_id, decision: approved, timestamp in ISO 8601
T08
Manager declines via Slack
Validated request payload; manager clicks Decline button
Decision logged as declined; Gmail email sent to employee with decline reason placeholder
decision: declined logged; Gmail email dispatched to employee; workflow terminates without triggering Post-Approval Sync Agent
T09
Slack bot token missing or invalid
Valid request payload but Slack bot token is null in environment config
Slack delivery fails; error logged; fallback Gmail approval request sent to manager email
Error log contains source: Slack, reason: invalid_token; Gmail fallback triggered within 60 seconds
T10
Manager does not respond within 48-hour timeout window
Valid Slack message sent; no interaction recorded after 48 hours
Escalation triggered: reminder Slack message sent at 24 hours; at 48 hours HR notified via Gmail to chase manually
24-hour reminder confirmed dispatched; 48-hour Gmail escalation to HR confirmed; workflow status set to: awaiting_manual_chase
T11
Slack message delivered but interactive button payload malformed
Manager clicks Approve but callback payload is missing employee_id field
Workflow catches missing field; logs payload_error; sends Slack DM to manager asking them to resubmit via a link
payload_error logged with missing field identified; Slack DM to manager dispatched; workflow does not advance to sync

Post-Approval Sync Agent — this agent runs only on an approved decision and updates BambooHR, Google Calendar, Gusto, and sends Slack notifications. Test cases cover the full sync path and each downstream system failure mode.

ID
Scenario
Input
Expected Output
Pass Criteria
T12
Happy path: all four sync operations succeed
Approved decision payload with employee_id, dates, leave_type, manager_id
BambooHR balance deducted; Google Calendar event created; Gusto leave logged; Slack DM sent to employee; Slack channel message posted
All four API calls return HTTP 200 or 201; Slack messages confirmed delivered; run log shows all steps: success
T13
BambooHR balance update fails (HTTP 500)
Approved payload; BambooHR sandbox returns 500 on PATCH request
Error logged; balance update retried once; if retry fails, workflow halts sync and alerts FullSpec team; downstream steps do not run
Retry executes once; on second failure error logged with source: BambooHR, step: balance_deduction; downstream Gusto and Calendar steps blocked
T14
Gusto leave log API returns 422 Unprocessable Entity
Approved payload; Gusto sandbox rejects leave entry due to missing pay_period_id
Gusto step fails; error logged with full response body; HR alerted via Gmail to log manually; BambooHR and Calendar steps already completed are not rolled back
422 error captured and logged; Gmail alert to HR dispatched; workflow marks Gusto step as: requires_manual_entry
T15
Slack notification to employee fails
Approved payload; employee Slack user ID not found in workspace
Slack DM fails; fallback Gmail notification sent to employee email address on record in BambooHR; all other sync steps complete normally
Slack DM error logged; Gmail fallback dispatched within 30 seconds; BambooHR, Calendar, and Gusto steps confirmed complete
Test and QA PlanPage 2 of 4
FS-DOC-06Quality

03Phase 2 — integration and edge case tests

Integration tests verify that the three agents hand off correctly to each other under realistic conditions. Each test triggers the full chain from the point of handoff and confirms that the receiving agent processes the payload without error. All tests in this phase run in sandbox only.

ID
Scenario
Agents Involved
Input
Expected Output
Pass Criteria
T16
Full handoff: Intake Agent to Approval Routing Agent (approved path)
Leave Intake and Balance Agent, Approval Routing Agent
Valid form submission; balance sufficient; no conflicts
Intake agent outputs validated summary; Approval Routing Agent receives it without transformation errors and dispatches Slack message
Slack message delivered within 10 seconds of intake agent completion; payload fields intact including employee_id, dates, balance_remaining, conflict_flag
T17
Full handoff: Approval Routing Agent to Post-Approval Sync Agent (approved decision)
Approval Routing Agent, Post-Approval Sync Agent
Manager approves via Slack; decision payload dispatched
Post-Approval Sync Agent receives approved decision and initiates all four sync operations
All four sync steps triggered within 15 seconds of manager approval; no fields dropped between agents
T18
Decline path: Approval Routing Agent terminates workflow correctly
Approval Routing Agent
Manager declines via Slack
Post-Approval Sync Agent is NOT triggered; decline email sent to employee via Gmail; workflow closes with status: declined
No sync agent invocation recorded in run log; Gmail decline email confirmed; workflow status confirmed as: declined
T19
Intake agent payload schema mismatch passed to Approval Routing Agent
Leave Intake and Balance Agent, Approval Routing Agent
Intake agent output has unexpected null for leave_type field
Approval Routing Agent catches missing required field; logs schema_error; does not dispatch Slack message; HR alerted
schema_error logged at Approval Routing Agent entry; Slack not dispatched; HR Gmail alert sent
T20
Concurrent requests: two employees submit simultaneously
All three agents
Two separate form submissions within 5 seconds of each other for different employees
Both workflows run independently in parallel; no data mixing between the two runs
Run log shows two separate workflow instance IDs; each instance contains only its own employee data; no cross-contamination
T21
Retry behaviour when Approval Routing Agent Slack send is delayed
Approval Routing Agent
Slack API rate limit hit (HTTP 429 returned)
Agent reads Retry-After header; waits specified duration; retries once; message delivered on retry
429 response handled; Retry-After value respected; second attempt returns HTTP 200; message delivered; retry logged
T22
Post-Approval Sync Agent triggered by an already-processed approval (duplicate webhook)
Post-Approval Sync Agent
Approval webhook delivered twice due to Slack retry mechanism
Agent detects duplicate by checking idempotency key; second execution blocked; no duplicate records written
Idempotency check passes; second execution logged as: duplicate_blocked; BambooHR, Gusto, Calendar each contain exactly one record for the request

Edge case tests cover scenarios outside the normal flow: duplicate submissions, incomplete data, tool unavailability, and human inaction. These are deliberately adversarial and must all resolve safely without data corruption or silent failure.

ID
Scenario
Trigger
Expected Handling
Pass Criteria
E01
Duplicate leave request submitted by same employee for overlapping dates
Employee submits a second form with identical dates while first request is still in-flight
Automation detects duplicate on intake; second request rejected with duplicate_request error; employee notified via Gmail
duplicate_request flag set; second workflow instance closed without proceeding; Gmail notification confirmed
E02
Form submitted with missing mandatory fields (no leave type selected)
Employee submits form without selecting a leave type
Intake agent validation rejects submission; employee receives Gmail prompt to resubmit with all fields completed
validation_error: missing_leave_type logged; workflow does not advance; Gmail prompt dispatched within 30 seconds
E03
BambooHR API unavailable for more than 5 minutes
BambooHR returns 503 Service Unavailable on repeated balance check attempts
Workflow retries three times at 90-second intervals; after third failure, request placed in a held queue; HR alerted via Gmail to process manually
Three retry attempts logged; held queue entry created; Gmail alert to HR confirmed; no partial data written
E04
Gusto environment in maintenance mode during Post-Approval Sync
Gusto returns 503 during leave log step
BambooHR and Calendar steps complete; Gusto step marked as: pending_retry; retry scheduled for 1 hour later; HR alerted if retry fails
BambooHR and Calendar records confirmed written; Gusto step status: pending_retry; scheduled retry confirmed; HR alert on retry failure confirmed
E05
Manager Slack account deactivated between request submission and approval delivery
Slack returns user_not_found on message delivery attempt
Fallback to Gmail approval request using manager email from BambooHR employee record; timeout rules apply equally
Slack error logged; manager email retrieved from BambooHR; Gmail approval request dispatched; 48-hour timeout applied identically
E06
Leave request dates span a configured blackout period
Employee requests annual leave covering a company blackout date defined in workflow policy config
Intake agent detects blackout overlap; request rejected at intake; employee notified of blackout period via Gmail with policy reference
blackout_conflict: true logged; workflow halts; Gmail notification includes the specific blackout dates; no approval request sent
E07
Manager timeout: no response after 48 hours and HR Gmail escalation also unactioned for 24 further hours
No Slack interaction and no HR response for 72 hours total
Workflow escalates to Operations Lead via Gmail after 72 hours; request status set to: escalated; original request preserved in run log
72-hour escalation Gmail confirmed dispatched to Operations Lead; workflow status: escalated; run log intact with full request history
Test and QA PlanPage 3 of 4
FS-DOC-06Quality

04Phase 3 — end-to-end production test

Important before running Phase 3: use a designated internal test employee account only. Do not submit a real employee leave request as a test. The test record will write to live BambooHR, Gusto, and Google Calendar systems, so the FullSpec team must void and delete the test record from all three systems immediately after sign-off is recorded. Coordinate with the process owner before starting this phase to confirm the test employee ID, the test manager Slack account, and the exact time the test will run so the team calendar and Gusto pay period are not affected.

Phase 3 runs the complete automation once in the live production environment. The FullSpec team executes each step and the process owner observes and verifies outputs at each stage. All results are recorded in the FullSpec confirmation log. The final test case (T26) constitutes the formal process owner approval.

ID
Scenario
Steps Covered
Expected Output
Pass Criteria
T23
Full production run: form submission through manager approval
Leave Intake and Balance Agent: form receipt, BambooHR balance query, Google Calendar conflict check, Approval Routing Agent: Slack message delivery, manager approval
Validated request summary produced; Slack approval message received by designated test manager; manager approves via button; decision logged with timestamp
BambooHR balance query returns live data; Slack message delivered in production workspace; manager approval recorded with correct manager_id and ISO 8601 timestamp; no errors in run log
T24
Post-approval sync: all four systems updated correctly
Post-Approval Sync Agent: BambooHR balance deduction, Google Calendar event creation, Gusto leave log, Slack notifications
BambooHR leave balance reduced by test duration; Google Calendar event visible in shared team calendar; Gusto leave entry present for test employee; Slack DM received by test employee account; Slack channel message posted
All four systems confirmed updated by process owner inspection; Slack messages visible in production workspace; no duplicate entries in any system; run log shows all steps: success
T25
Error log and audit trail verification
All agents across the full run
Run log contains a complete sequential record of every action, API call, response code, timestamp, agent name, and decision point for the end-to-end test run
FullSpec team exports run log; process owner confirms log includes: form receipt timestamp, BambooHR query response, Calendar check result, Slack delivery confirmation, manager decision record, all four sync confirmations; no gaps in the audit trail
T26
Process owner review and approval sign-off
Full end-to-end output review by process owner
Process owner reviews all outputs from T23 through T25, confirms the automation behaved correctly across all steps, and provides verbal or written sign-off recorded by the FullSpec team in the confirmation log
Process owner confirms: correct Slack messages received, correct BambooHR balance shown, correct Google Calendar event created, correct Gusto entry present, and complete run log verified. FullSpec records sign-off in the confirmation log with owner name, date, and approval status. This case constitutes formal go-live approval.
Once T26 is recorded as passed, the FullSpec team will void the test record in BambooHR, delete the Google Calendar event, remove the Gusto leave entry, and archive the sandbox credentials. A summary of all test results across all three phases will be shared with the process owner within one business day. Any issues surfaced during Phase 3 will be resolved and retested before go-live proceeds. Contact the FullSpec team at support@gofullspec.com for any questions about this test plan or to reschedule Phase 3.
Test and QA PlanPage 4 of 4

More documents for this process

Every document generated for Leave & Absence Management.

Launch Plan
Operations · Owner
View
ROI and Business Case
Finance · Owner
View
Process Runbook / SOP
Operations · Owner
View
Developer Handover Pack
Technical · Developer
View
Integration and API Spec
Technical · Developer
View