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

Job / Project Scheduling Automation

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

This document defines the complete quality assurance programme for the Job / Project Scheduling automation. It covers all test cases across three sequential phases: unit testing of individual agents in a sandbox environment, integration and edge-case testing of agent handoffs and failure scenarios, and a final end-to-end production run with process owner sign-off. The FullSpec team runs all phases; your process owner joins Phase 3 to confirm the production run meets operational requirements. No phase begins until the previous phase fully passes.

01Testing approach

Testing is structured across three phases that must be completed in sequence. No phase begins until every test case in the previous phase carries a Pass status. This sequencing prevents integration and production tests from masking unit-level defects that would otherwise propagate forward and be difficult to isolate. The FullSpec team owns execution across all three phases, with your process owner joining Phase 3 to validate that the live automation meets real-world scheduling requirements.

Phase 1: Unit Testing

Each agent tested in isolation, sandbox environment only

Scope

Individual agent logic: Availability and Assignment Agent; Notifications and CRM Sync Agent. Each agent tested independently without relying on upstream or downstream agents.

Environment

Sandbox only. No production Jobber jobs, Google Calendar events, HubSpot records, Slack channels, or Gmail inboxes are touched.

Credential rule

All connections must use sandbox or test credentials exclusively. Production API keys and OAuth tokens must not be present in the test environment during Phase 1.

Pass condition

All test cases T01 through T14 return the expected output with no unhandled errors. Every failure mode routes to the correct exception path.

Who runs it

FullSpec team. The process owner is not required for Phase 1.

Phase 2: Integration and Edge Case Testing

Agent handoffs and failure scenarios tested end-to-end in sandbox

Scope

Full agent-to-agent handoff from the Availability and Assignment Agent through to the Notifications and CRM Sync Agent, plus all defined edge cases including duplicates, missing data, tool unavailability, and human timeout scenarios.

Environment

Sandbox environment with simulated tool responses for unavailability and error conditions. No production records are written.

Credential rule

Sandbox credentials remain in use. Simulated error responses may be injected via mock endpoints or test flags in the automation platform. Production credentials must not be active.

Pass condition

Integration test cases T15 through T21 and edge cases E01 through E07 all pass. No data leaks between agents, no silent failures, and all human-escalation paths trigger correctly.

Who runs it

FullSpec team. The process owner is not required for Phase 2.

Phase 3: End-to-End Production Test

Live credentials, real records, process owner review and approval

Scope

A controlled production run using real tool credentials, a designated internal test job in Jobber, and monitored outputs across Google Calendar, HubSpot, Slack, and Gmail. Includes error log verification and process owner approval.

Environment

Production environment. All connections use live credentials. The test job uses an internal address and test contact. The record is voided or deleted after the run is confirmed.

Credential rule

Production API keys and OAuth tokens are active. The FullSpec team confirms all sandbox credentials have been replaced before Phase 3 begins.

Pass condition

Test cases T22 through T26 all pass, including the process owner review case (T26). Sign-off is recorded in the FullSpec confirmation log.

Who runs it

FullSpec team executes. The process owner joins to observe the live run and formally approves at test case T26.

Test and QA PlanPage 1 of 4

FS-DOC-06Quality

02Phase 1 — unit test cases

Sandbox credentials only. Before running any Phase 1 test, confirm that all tool connections (Jobber, Google Calendar, HubSpot, Slack, Gmail) are pointing to sandbox or test accounts. Production credentials must not be active. No real jobs, crew calendars, or customer records should be created or modified during this phase.

Availability and Assignment Agent — Unit Tests

Scenario

Input

Expected Output

Pass Criteria

T01

Happy path: crew available, single match

Jobber webhook payload with confirmed job; one crew member free in Google Calendar during the required window

Google Calendar event created with correct crew, job address, and time; Jobber record updated with assigned crew

Event ID returned; Jobber job record contains assigned crew name; no errors in execution log

T02

Happy path: multiple crew available, best match selected

Jobber webhook payload; two crew members free during the window, one geographically closer

Closest available crew member assigned; calendar event created; Jobber updated

Proximity rule applied correctly; assigned crew matches expected result; no duplicate events created

T03

Happy path: job with full context notes

Jobber payload with site address, scope notes, and customer contact populated

Calendar event description contains all job context fields: address, scope notes, customer contact

All context fields present in calendar event body; no truncation

T04

No crew available: all busy during window

Jobber payload; all crew members have conflicting Google Calendar events during the required window

Automation routes to human escalation; scheduler is notified of the unresolved conflict; no calendar event created

Escalation flag set; no calendar event written; execution log records the no-availability path

T05

Jobber webhook missing required field: job date

Webhook payload with job_date field absent or null

Automation halts; error logged with field name; no Calendar or Jobber write attempted

Error log contains 'job_date missing'; downstream steps not triggered; execution stops cleanly

T06

Jobber webhook missing required field: site address

Webhook payload with site_address field absent or null

Automation halts; error logged; no calendar event created

Error log contains 'site_address missing'; no partial records written

T07

Google Calendar API returns 500 error

Valid Jobber payload; Google Calendar API returns HTTP 500 on availability query

Automation retries up to 3 times with exponential backoff; if all retries fail, escalation path fires

Retry count visible in execution log; escalation triggered after third failure; no calendar event created

T08

Jobber API update returns 401 unauthorised

Crew assigned successfully; Jobber record update call returns 401

Error logged; calendar event retained; alert sent to FullSpec monitoring; no silent failure

Execution log contains 401 response; partial-success state recorded; alert visible in monitoring dashboard

Notifications and CRM Sync Agent — Unit Tests

Scenario

Input

Expected Output

Pass Criteria

T09

Happy path: all three notifications dispatched

Confirmed assignment payload from Availability and Assignment Agent with crew name, job address, start time, customer email, and HubSpot deal ID

Slack message sent to assigned crew; Gmail confirmation sent to customer; HubSpot deal updated with scheduled date

Slack delivery receipt returned; Gmail message ID returned; HubSpot deal last_modified timestamp updated; no errors

T10

Slack message contains all required job fields

Assignment payload with job address, start time, customer name, and special instructions

Slack message body includes: job address, start time, customer name, and special instructions section

All four fields present in outbound Slack message body; no placeholder text remaining

T11

Gmail confirmation contains correct booking details

Assignment payload with booked date, arrival window, crew lead name, and contact number

Customer receives email with booked date, arrival window, crew lead name, and contact number

Gmail message body parsed and all four fields verified; email sent to correct recipient address

T12

HubSpot deal ID not found

Assignment payload with a deal_id that does not exist in the sandbox HubSpot account

HubSpot update skipped; error logged with deal_id value; Slack and Gmail steps still complete

Slack and Gmail confirmed sent; HubSpot error logged; overall execution continues without halting

T13

Slack API returns 429 rate limit error

Valid assignment payload; Slack API returns 429 on message send

Automation respects Retry-After header; retries after the specified delay; message sent on retry

Slack delivery confirmed on retry; Retry-After delay honoured; execution log shows retry event

T14

Gmail SMTP send failure

Valid assignment payload; Gmail API returns 503 service unavailable on send attempt

Automation retries up to 3 times; if all fail, error logged and escalation alert raised; HubSpot and Slack steps still complete

Retry attempts logged; escalation alert raised after third failure; HubSpot and Slack not blocked by Gmail failure

Test and QA PlanPage 2 of 4

FS-DOC-06Quality

03Phase 2 — integration and edge case tests

Integration Tests — Agent Handoffs

Scenario

Input

Expected Output

Pass Criteria

T15

Full handoff: happy path, both agents complete

Jobber webhook fires with a complete confirmed job payload; one crew member available

Agent 1 assigns crew and creates calendar event; output payload triggers Agent 2; Slack, Gmail, and HubSpot all complete

End-to-end execution log shows both agents completing; all five outputs (Calendar event, Jobber update, HubSpot update, Slack message, Gmail confirmation) verified

T16

Reschedule event: existing job updated in Jobber

Jobber webhook fires for an update to a previously confirmed job with new date and time

Existing calendar event updated or replaced; Jobber record reflects new time; crew re-notified via Slack; updated Gmail confirmation sent to customer; HubSpot updated

No duplicate calendar events; all downstream notifications reflect the new date and time; old event removed or marked cancelled

T17

Agent 1 escalates: conflict flagged for human resolution

No crew available during required window; Agent 1 routes to human escalation

Agent 2 does not trigger; escalation notification sent; no Slack, Gmail, or HubSpot updates written

Agent 2 execution not present in log; escalation path confirmed; downstream tools untouched

T18

Agent 1 output payload incomplete: missing crew_id

Agent 1 completes calendar event creation but output payload omits crew_id field before handoff to Agent 2

Agent 2 detects missing crew_id; halts; error logged with field name; escalation raised

Agent 2 execution log shows 'crew_id missing'; no Slack, Gmail, or HubSpot writes attempted; alert raised

T19

Concurrent jobs: two webhooks fire within 5 seconds

Two separate Jobber webhook events fire in rapid succession for two different confirmed jobs

Both jobs processed independently without data collision; each produces its own calendar event, Jobber update, Slack message, Gmail email, and HubSpot update

Six distinct output records confirmed (two per notification type); no field values cross-contaminated between jobs

T20

HubSpot update in Agent 2 fails after Slack and Gmail succeed

Valid handoff from Agent 1; Slack and Gmail succeed; HubSpot API returns 500

Slack and Gmail success retained; HubSpot failure logged; retry attempted; alert raised if all retries fail

Partial success state recorded in execution log; Slack and Gmail delivery receipts confirmed; HubSpot error visible in monitoring

T21

Job cancelled in Jobber after automation has run

Jobber webhook fires a cancellation event for a job that has already been fully scheduled

Calendar event removed; crew notified of cancellation via Slack; customer notified via Gmail; HubSpot deal status updated

All four reversal actions confirmed in execution log; no orphaned calendar events remaining

Edge Case Tests

Scenario

Input

Expected Output

Pass Criteria

E01

Duplicate webhook: same job fires twice within 60 seconds

Jobber fires the same confirmed job webhook event twice due to a retry or user action

Idempotency check detects the duplicate; second execution skipped; no duplicate calendar event, Slack message, or Gmail sent

Execution log shows duplicate detected and skipped; single calendar event confirmed; single Slack and Gmail delivery

E02

Missing customer email address in Jobber record

Confirmed job payload with customer_email field null or empty

Gmail step skipped; error logged with job ID and field name; all other steps (Calendar, Jobber, Slack, HubSpot) complete

Gmail not triggered; remaining steps confirmed complete; error log contains 'customer_email missing' with job reference

E03

Crew member has no Google Calendar connected

Availability query run against a crew member whose Google Calendar has not been linked or shared

Crew member treated as unavailable; next eligible crew member selected; if none, escalation path fires

No error thrown on missing calendar; fallback logic confirmed; execution log records reason for skip

E04

Google Calendar API completely unavailable (timeout)

Jobber webhook fires; Google Calendar API returns no response within 30 seconds

Automation retries 3 times with backoff; after all retries fail, job is queued for manual review and escalation alert sent

Three retry attempts in log with timestamps; manual review queue entry created; no silent failure

E05

Slack workspace disconnected or token revoked

All upstream steps succeed; Slack API returns 401 invalid_auth on crew notification attempt

Slack step fails gracefully; error logged with token reference; Gmail and HubSpot steps still complete; alert raised to FullSpec monitoring

Gmail and HubSpot confirmed complete; Slack error in log; monitoring alert visible; crew not silently left uninformed

E06

Human scheduler does not action the escalation within 4 hours

Conflict escalation raised; no response from scheduler within the 4-hour threshold

Reminder notification sent to scheduler via Slack; if no action within 8 hours, secondary alert escalated to operations manager

Reminder sent at 4-hour mark; secondary alert at 8-hour mark confirmed in execution log; job remains in pending state

E07

Job payload contains special characters in site address

Confirmed job with site address containing ampersands, quotes, or non-ASCII characters

Address stored and passed correctly to Google Calendar event and Gmail without encoding errors or truncation

Calendar event address field matches raw input exactly; Gmail body renders correctly; no JSON parse errors in log

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 address (such as an internal office address or a confirmed internal test site) for the Jobber job record. Use an internal staff email address for the customer confirmation field so no real customer receives a test email. Use a dedicated test Slack channel for crew notification. After the production run is confirmed and all test cases pass, void or delete the test job record in Jobber, remove the Google Calendar event, and archive the HubSpot test deal. Do not leave test records in live systems.

Scenario

Input

Expected Output

Pass Criteria

T22

Full production run: new job confirmed end to end

A real Jobber job created and marked confirmed using production credentials; internal test address; internal email as customer; designated test Slack channel as crew channel

Jobber webhook fires; Google Calendar queried; crew assigned; calendar event created in production Calendar; Jobber record updated; HubSpot deal updated; Slack message sent to test channel; Gmail confirmation sent to internal email address

All seven pipeline steps confirmed in execution log with production timestamps; no step skipped; all output records created correctly in live systems

T23

Production reschedule: test job time changed

Test job from T22 updated in Jobber with a new date and time

Webhook fires for the update; existing calendar event updated; crew re-notified in Slack test channel; updated confirmation email sent to internal address; HubSpot updated with new date

Single calendar event with updated time confirmed; no duplicate events; all downstream notifications reflect updated details; execution log shows update path taken

T24

Production escalation path: forced conflict scenario

Test job created with a time window during which all crew members have been temporarily blocked in their production calendars

Automation detects no availability; escalation notification sent to scheduler via Slack; no calendar event created; no customer email sent; Jobber record flagged as pending assignment

Escalation message received in production Slack; calendar clean of new events; Jobber job status reflects pending; execution log records escalation path

T25

Error log and monitoring verification

Review execution logs in the automation platform and any connected monitoring tool following T22, T23, and T24 runs

All three runs have complete execution logs with step-level timestamps, input and output payloads, and clear pass or escalation status; no unhandled exceptions; retry events (if any) documented

FullSpec team confirms log completeness; no orphaned or partial executions; monitoring dashboard shows correct run statuses for all three test cases

T26

Process owner review and approval

Process owner observes the live T22 run (or reviews confirmed output records from T22 through T25); reviews execution logs, all five output records, and the escalation path from T24

Process owner confirms: scheduling output matches operational expectations; notifications contain correct content; escalation path behaves as agreed; no data concerns

Process owner formally approves. Approval is recorded in the FullSpec confirmation log with name, date, and sign-off statement. No separate signature block is required. Contact support@gofullspec.com once approval is complete to initiate go-live handover.

After T26 approval is recorded, the FullSpec team will void all Phase 3 test records (Jobber job, Google Calendar event, HubSpot test deal), confirm production monitoring is active, and initiate the go-live handover. The process is then live. For any questions during or after testing, contact the FullSpec team at support@gofullspec.com.

Test and QA PlanPage 4 of 4

Test and QA Plan

Test and QA Plan

01Testing approach

02Phase 1 — unit test cases

03Phase 2 — integration and edge case tests

04Phase 3 — end-to-end production test

More documents for this process