Back to Appointment / Booking 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

Appointment / Booking Management

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

This document defines the full structured test programme for the Appointment / Booking Management automation. It covers three sequential phases: unit testing of each individual agent in isolation, integration and edge-case testing across agent handoffs, and a final end-to-end production run. The FullSpec team runs Phases 1 and 2 entirely in sandbox environments. Your team joins for Phase 3, which executes against live production credentials. No phase begins until all test cases in the previous phase have fully passed.

01Testing approach

Testing is structured across three phases that must be completed in strict sequence. A phase does not begin until every test case in the preceding phase carries a confirmed pass status and that result is logged in the FullSpec test tracker. This sequencing ensures that integration and production tests are only run against components that have already been individually verified.

1
Phase 1: Unit Testing
Each agent tested in isolation against sandbox credentials
Scope
Individual agent logic: Booking Intake Agent, CRM and Payment Agent, Reminder and Follow-Up Agent
Environment
Sandbox only. No production credentials or live accounts are used.
Credential rule
All API calls use sandbox or test-mode tokens exclusively. Calendly sandbox, HubSpot sandbox portal, Stripe test-mode keys, Twilio test credentials, Gmail test account.
Pass condition
All test cases T01 through T13 return the expected output with no unhandled errors.
Who runs it
FullSpec team only.
2
Phase 2: Integration and Edge Case Testing
Agent handoffs and boundary conditions tested end to end in sandbox
Scope
Agent-to-agent handoffs, data passing between agents, and all defined edge cases including duplicates, missing fields, tool unavailability, and human timeout scenarios
Environment
Sandbox throughout. No live transactions or live contacts are created.
Credential rule
Same sandbox credentials as Phase 1. No switching to production keys until Phase 3 is formally authorised.
Pass condition
All integration test cases T14 through T20 and all edge cases E01 through E07 pass without data loss or unhandled failure states.
Who runs it
FullSpec team only.
3
Phase 3: End-to-End Production Test
Full live run on production credentials with process owner present
Scope
Complete booking lifecycle from inbound request through confirmation, CRM logging, deposit collection, reminder delivery, and no-show follow-up — all on production systems
Environment
Production. Live Calendly, Google Calendar, HubSpot, Stripe, Gmail, and Twilio accounts.
Credential rule
Production API keys and OAuth tokens used. All test bookings are made to an internal test address and voided or deleted from live records immediately after each case is confirmed.
Pass condition
All test cases T21 through T25 pass, error logs are clean, and the process owner confirms the final review case.
Who runs it
FullSpec team executes. Process owner is present and confirms the final approval case (T25).
Test and QA PlanPage 1 of 4
FS-DOC-06Quality

02Phase 1 — unit test cases

All Phase 1 tests must be executed using sandbox or test-mode credentials only. Do not connect production API keys, live HubSpot portals, live Stripe accounts, or real Twilio sending numbers during any Phase 1 test run. Using live credentials at this stage risks creating real calendar events, charging real payment methods, and sending emails or SMS messages to actual clients.

Booking Intake Agent: validates inbound request handling, availability logic, confirmation email dispatch, and Google Calendar event creation.

ID
Scenario
Input
Expected Output
Pass Criteria
T01
Happy path: slot available, no deposit required
Valid Calendly webhook payload; requested slot free; deposit flag = false
Confirmation email sent via Gmail; Google Calendar event created; structured booking record emitted to next agent
Gmail sandbox shows delivered message; Calendar sandbox shows new event with correct client name and service type; output record contains all required fields
T02
Happy path: slot available, deposit required
Valid Calendly webhook payload; requested slot free; deposit flag = true
Confirmation email sent; Google Calendar event created; deposit-required flag set to true in outbound booking record
Same as T01 plus deposit_required = true in the structured record passed to CRM and Payment Agent
T03
Slot unavailable: Calendly returns no availability
Valid booking request; requested slot blocked in Calendly
No calendar event created; no confirmation email sent; error state logged with reason 'slot_unavailable'
Workflow halts at availability check; error log entry present; no downstream actions triggered
T04
Malformed webhook payload: missing client email
Calendly webhook with email field null or absent
Workflow halts; error logged with field identifier 'client_email'; no email sent; no calendar event created
Error log captures missing field; no partial records created in Calendar or Gmail
T05
Calendly API timeout during availability check
Valid booking request; Calendly API returns 504 after 10 seconds
Retry attempted up to 3 times with exponential backoff; after final failure, error logged and workflow halted
Three retry attempts visible in execution log; final error state reached; no calendar event created
T06
Google Calendar event creation fails after confirmation email sent
Valid booking; Gmail send succeeds; Google Calendar API returns 403
Error logged with step 'calendar_create'; workflow flags for manual review; booking record marked incomplete
Gmail shows sent message; Calendar shows no event; error log contains 403 with step reference

CRM and Payment Agent: validates HubSpot record creation and update, Stripe deposit link generation, and payment confirmation handling.

ID
Scenario
Input
Expected Output
Pass Criteria
T07
Happy path: new contact, no deposit required
Structured booking record from Booking Intake Agent; deposit_required = false; contact email not in HubSpot
New HubSpot contact created; deal record logged with booking date, service type, and status 'Confirmed'
HubSpot sandbox shows new contact and associated deal with all required properties populated
T08
Happy path: existing contact, deposit required
Structured booking record; deposit_required = true; contact email already in HubSpot
Existing HubSpot contact updated; Stripe test-mode payment link generated and sent via Gmail; deal marked 'Awaiting Payment'
HubSpot contact shows updated activity; Stripe test dashboard shows payment link created; Gmail sandbox shows link email delivered
T09
Stripe payment confirmed: webhook received
Stripe test-mode payment.succeeded webhook; matching booking reference
HubSpot deal status updated to 'Confirmed'; payment_received flag set to true on booking record
HubSpot sandbox deal shows status change; payment_received = true in booking record; timestamp recorded
T10
Stripe payment link expires without payment
Stripe test-mode payment link expiry event; no payment.succeeded event received within 24 hours
HubSpot deal flagged as 'Payment Overdue'; follow-up email sent to client via Gmail
HubSpot deal status = 'Payment Overdue'; Gmail sandbox shows follow-up message; no booking marked Confirmed
T11
HubSpot API rate limit exceeded during contact creation
Valid booking record; HubSpot sandbox returns 429
Retry with backoff up to 3 attempts; if all fail, error logged and booking flagged for manual CRM entry
Three retry attempts in log; final error state reached; alert message generated for manual action

Reminder and Follow-Up Agent: validates timed reminder delivery via Twilio SMS and Gmail, and no-show detection and follow-up.

ID
Scenario
Input
Expected Output
Pass Criteria
T12
Happy path: 48-hour and 2-hour reminders delivered
Confirmed booking record with future appointment datetime; client mobile number and email present
Twilio test SMS sent at T-48h; Gmail reminder email sent at T-48h; second SMS and email sent at T-2h
Twilio test sandbox logs show two outbound messages; Gmail sandbox shows two reminder emails; timestamps match booking datetime offsets
T13
No-show detection and follow-up triggered
Booking datetime has passed; appointment status not updated to 'Complete' within 30-minute post-appointment window
No-show follow-up email sent via Gmail; HubSpot deal status updated to 'No Show'
Gmail sandbox shows follow-up email delivered; HubSpot sandbox deal status = 'No Show'; timestamp of update recorded in log
Test and QA PlanPage 2 of 4
FS-DOC-06Quality

03Phase 2 — integration and edge case tests

Integration tests verify that data passes correctly between agents and that the full workflow executes without data loss or state corruption at handoff points. All tests remain in sandbox environment.

ID
Scenario
Agents Involved
Input
Expected Output
Pass Criteria
T14
Full handoff: Booking Intake to CRM and Payment Agent, no deposit
Booking Intake Agent, CRM and Payment Agent
Valid Calendly webhook; slot available; deposit_required = false
Booking record passed intact; HubSpot contact created; deal logged as Confirmed
All fields from Intake Agent output present in CRM Agent input; HubSpot sandbox record matches booking data
T15
Full handoff: Booking Intake to CRM and Payment Agent, deposit required
Booking Intake Agent, CRM and Payment Agent
Valid Calendly webhook; slot available; deposit_required = true
Stripe link generated; HubSpot deal = 'Awaiting Payment'; Gmail link email delivered
deposit_required flag preserved across handoff; Stripe test link created; HubSpot and Gmail sandbox both updated
T16
Full handoff: CRM and Payment Agent to Reminder and Follow-Up Agent after payment confirmed
CRM and Payment Agent, Reminder and Follow-Up Agent
Stripe payment.succeeded webhook received; booking marked Confirmed
Reminder schedule activated; T-48h and T-2h reminders queued in test scheduler
Reminder Agent receives confirmed booking record; test scheduler shows two reminder jobs queued at correct offsets
T17
Partial handoff failure: CRM Agent fails mid-run, Reminder Agent does not activate
CRM and Payment Agent, Reminder and Follow-Up Agent
Valid booking record; HubSpot API returns 500 on deal creation attempt
CRM Agent errors and halts; Reminder Agent is not triggered; error log captures failure point
Reminder Agent execution log shows no invocation; CRM error logged with step 'deal_create'; no reminder jobs queued
T18
Twilio SMS delivery failure falls back to Gmail reminder only
Reminder and Follow-Up Agent
Confirmed booking record; Twilio test sandbox returns 400 on SMS send
SMS failure logged; Gmail reminder email sent as fallback; HubSpot note added: 'SMS failed, email reminder sent'
Twilio error captured in log; Gmail sandbox shows reminder email delivered; HubSpot sandbox shows note on contact
T19
No-show follow-up correctly updates HubSpot after Reminder Agent completes
Reminder and Follow-Up Agent
Appointment window passed; no completion status set; both reminders previously sent
No-show email sent; HubSpot deal status = 'No Show'; log entry records detection timestamp
Gmail sandbox shows follow-up email; HubSpot sandbox deal status updated; timestamps consistent with appointment datetime
T20
Complete three-agent sandbox run: intake through no-show follow-up
All three agents in sequence
Full Calendly webhook; deposit_required = true; payment confirmed; appointment passes without completion update
Confirmation email, calendar event, HubSpot record, Stripe link, payment confirmation, two reminders, and no-show follow-up all execute in sequence
All sandbox outputs present and correctly populated; no errors in execution log; all agent handoffs logged with correct timestamps

Edge case tests cover boundary conditions and failure scenarios that fall outside the standard booking flow. These must all be tested before Phase 3 is authorised.

ID
Scenario
Input
Expected Output
Pass Criteria
E01
Duplicate booking submission: same client submits the same slot twice within 60 seconds
Two identical Calendly webhooks for the same client email and appointment datetime
First submission processed normally; second submission detected as duplicate and discarded; single HubSpot record created
Execution log shows deduplication check triggered on second webhook; only one HubSpot contact and one calendar event created
E02
Missing client phone number: SMS reminder cannot be sent
Booking record with client_mobile = null; email present
SMS step skipped with warning logged; email reminder sent via Gmail; HubSpot note added: 'No mobile number on record'
Twilio step not invoked; Gmail reminder delivered; HubSpot note visible in sandbox contact timeline
E03
Missing deposit amount in booking record when deposit flag is true
Booking record with deposit_required = true; deposit_amount = null
Stripe link not generated; workflow halts at payment step; error logged with field 'deposit_amount'; booking flagged for manual review
No Stripe link created; error log entry present; HubSpot deal status = 'Requires Manual Action'
E04
Gmail API unavailable during confirmation send
Valid booking; Gmail API returns 503
Retry up to 3 times; if all fail, booking record held in pending state; alert generated; no calendar event created until confirmation is sent
Three retries logged; pending state flag set; alert message generated; calendar event creation blocked
E05
HubSpot contact exists with conflicting email domain (sandbox deduplication edge case)
Booking record email matches existing HubSpot contact but with different capitalisation
Case-insensitive match detected; existing contact updated rather than duplicate created
HubSpot sandbox shows one contact updated, not two contacts created; match method logged as 'case_insensitive_email'
E06
Appointment marked complete before no-show window expires
Booking datetime passed; completion status set to 'Complete' within 30-minute window
No-show follow-up branch not triggered; Reminder Agent closes the booking record cleanly; HubSpot deal = 'Completed'
No follow-up email in Gmail sandbox; HubSpot sandbox deal status = 'Completed'; no-show branch execution log shows skipped
E07
Human review timeout: complex reschedule flagged but no staff response within 4 hours
Reschedule request flagged for manual handling; no staff action recorded after 4-hour window
Escalation alert sent to Operations Coordinator email; HubSpot deal note added with timestamp and escalation flag
Gmail sandbox shows escalation alert addressed to coordinator; HubSpot sandbox note shows escalation timestamp; booking status remains 'Pending Manual Review'
Test and QA PlanPage 3 of 4
FS-DOC-06Quality

04Phase 3 — end-to-end production test

Important before running Phase 3: all test bookings in this phase must be submitted using an internal test email address and a test mobile number controlled by your team. Do not use real client contact details. Every calendar event, HubSpot deal, Stripe payment record, and email thread created during Phase 3 testing must be voided, deleted, or clearly tagged as a test record immediately after each case is confirmed. Stripe test-mode must be used for any payment flow test; do not run a live charge. The FullSpec team will confirm each record has been cleaned up before sign-off.
ID
Scenario
Production Systems Touched
Steps Traced
Pass Criteria
T21
Full production run: booking confirmed, no deposit, reminders delivered, appointment completed
Calendly, Google Calendar, Gmail, HubSpot, Twilio
1. Internal test user submits booking via live Calendly link. 2. Confirmation email arrives in test inbox. 3. Google Calendar event appears with correct details. 4. HubSpot contact and deal created with status 'Confirmed'. 5. T-48h SMS and email received at test number and test inbox. 6. T-2h SMS and email received. 7. Appointment manually marked Complete. 8. No-show branch confirmed not triggered.
All six tool outputs present in production systems; timestamps match; no-show branch skipped; HubSpot deal = 'Completed'; execution log clean
T22
Full production run: deposit required, Stripe test-mode payment confirmed
Calendly, Google Calendar, Gmail, HubSpot, Stripe (test mode)
1. Booking submitted with deposit-required appointment type. 2. Stripe test-mode payment link received in test inbox. 3. Test payment submitted via Stripe test card. 4. HubSpot deal status updates to 'Confirmed' on payment.succeeded event. 5. Reminder sequence activates.
Stripe test dashboard shows payment captured; HubSpot deal status = 'Confirmed' after webhook received; reminder jobs visible in scheduler; no live charge created
T23
No-show detection and follow-up on production
Gmail, HubSpot, Twilio
1. Test appointment datetime set to 35 minutes in the past at test start. 2. Completion status not set. 3. No-show window expires. 4. Follow-up email arrives in test inbox. 5. HubSpot deal status updates to 'No Show'.
Follow-up email in test inbox with correct content; HubSpot production deal = 'No Show'; timestamp within 2 minutes of expected trigger; no duplicate follow-up messages sent
T24
Error log verification: confirm all Phase 3 events are logged correctly
Automation platform execution log, HubSpot activity log, Twilio message log, Stripe event log
1. Review execution log after T21, T22, and T23. 2. Confirm each step is logged with tool name, timestamp, status, and any error codes. 3. Confirm no silent failures or missing log entries. 4. Confirm HubSpot activity timeline matches automation log sequence.
Execution log contains an entry for every step in T21 through T23; no gaps; all error-free steps show status 'success'; HubSpot timeline matches automation log order and timestamps within a 60-second tolerance
T25
Process owner review and approval: final end-to-end sign-off
All production systems reviewed by process owner
1. Process owner reviews outputs from T21 through T24 in full. 2. Process owner confirms confirmation email content, HubSpot record accuracy, reminder message copy, no-show follow-up content, and execution log integrity. 3. Process owner confirms all test records have been removed or tagged from production systems. 4. Process owner confirms the automation is ready for live traffic.
Process owner verbally or in writing confirms all cases pass to FullSpec team. Confirmation recorded by FullSpec in the project completion log. No separate signoff block is required. Contact support@gofullspec.com if any case requires remediation before approval.
Once T25 is confirmed by the process owner, the FullSpec team records the approval in the project completion log and the automation is cleared for live traffic. If any test case in Phase 3 fails, the FullSpec team will remediate the issue, re-run the affected case, and request process owner re-confirmation before go-live. Reach out to support@gofullspec.com with the test case ID and the observed behaviour for fastest resolution.
Test and QA PlanPage 4 of 4

More documents for this process

Every document generated for Appointment / Booking 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