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

Support Ticket Triage and Routing

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

This document defines every test case the FullSpec team runs before the Support Ticket Triage and Routing automation goes live. It is written for the developer and QA engineer running the build. Testing is structured across three sequential phases: unit tests against individual agents in isolation, integration and edge-case tests covering agent handoffs and failure scenarios, and a final end-to-end production run that the process owner reviews and approves before go-live. No phase begins until the previous phase has fully passed. All test IDs are sequential across phases so results can be tracked in a single log.

01Testing approach

Testing proceeds through three phases in sequence. No phase begins until every test case in the previous phase carries a Pass status. Any failure blocks progression and requires a fix plus a full re-run of the affected phase before moving forward.

Phase 1 — Unit Testing

Estimated time: 1 to 2 business days

Scope

Each agent tested in isolation: Ticket Classification Agent and Routing and Notification Agent. No live inter-agent handoff tested at this phase.

Environment

Sandbox only. Zendesk sandbox account, HubSpot sandbox portal, Slack test workspace, Gmail test address.

Credential rule

Sandbox API keys and OAuth tokens only. No production credentials are loaded or referenced at this phase.

Pass condition

All cases T01 through T14 return Expected output with no errors logged. Zero unhandled exceptions.

Who runs it

FullSpec team only. Process owner is not involved at this phase.

Phase 2 — Integration and Edge Case Testing

Estimated time: 1 to 2 business days

Scope

Agent-to-agent handoffs across the full triage pipeline, plus all defined edge cases including duplicates, missing data, unavailable tools, and human review timeouts.

Environment

Sandbox only. All tool connections use sandbox credentials matching Phase 1.

Credential rule

Sandbox credentials only. Production keys must not be present in any environment variable or secrets store at this phase.

Pass condition

All cases T15 through T22 pass and all edge cases E01 through E06 produce the defined safe-failure output. No ticket is silently dropped or incorrectly routed.

Who runs it

FullSpec team only. Process owner is not involved at this phase.

Phase 3 — End-to-End Production Test

Estimated time: 1 business day

Scope

Full production pipeline traced from a real ticket creation event through to customer acknowledgement email. Error log verification and process owner sign-off included.

Environment

Production. Live Zendesk account, live HubSpot portal, live Slack workspace, live Gmail account. Test tickets are created using an internal test email address.

Credential rule

Production API keys and OAuth tokens loaded. Sandbox credentials must be removed before this phase begins. Keys held in the secrets manager only, not in plain-text config.

Pass condition

All cases T23 through T26 pass, including the process owner review case (T26). Owner confirmation is recorded in the FullSpec platform before go-live is approved.

Who runs it

FullSpec team executes T23 through T25. Process owner participates in T26 as the final approver.

Test and QA PlanPage 1 of 4

FS-DOC-06Quality

02Phase 1 — unit test cases

All Phase 1 tests must be run against sandbox credentials only. Do not load production Zendesk, HubSpot, Slack, or Gmail API keys into any environment file before Phase 3. If a production key is accidentally used during Phase 1 or 2, revoke and rotate it immediately and notify support@gofullspec.com.

Ticket Classification Agent — unit tests (T01 to T08)

Scenario

Input

Expected output

Pass criteria

T01

Happy path: billing ticket, high-priority customer

Ticket body: 'I was charged twice this month.' Customer plan tier: Enterprise (HubSpot).

Category: Billing. Priority: High. Fields written to Zendesk sandbox ticket.

Zendesk ticket fields show category=Billing, priority=High within 10 seconds of trigger. No error log entry.

T02

Happy path: technical ticket, standard customer

Ticket body: 'The login page returns a 500 error.' Customer plan tier: Starter.

Category: Technical. Priority: Normal. Fields written to Zendesk.

Zendesk fields show category=Technical, priority=Normal. HubSpot lookup returns plan tier without error.

T03

Happy path: account access ticket, urgent flag

Ticket body: 'I cannot access my account and I have a demo in one hour.' Customer plan tier: Pro.

Category: Account Access. Priority: Urgent. Fields written to Zendesk.

Priority=Urgent written within 10 seconds. Urgency cue in body is detected correctly.

T04

Happy path: general enquiry, low priority

Ticket body: 'Can you tell me how to export my data?' Customer plan tier: Starter.

Category: General Enquiry. Priority: Low. Fields written to Zendesk.

category=General Enquiry, priority=Low. No mis-classification to higher category.

T05

Multi-issue ticket: primary intent selected

Ticket body: 'My invoice is wrong and also the dashboard is slow.' Two distinct issues present.

Category: Billing (primary intent). Priority: Normal. Secondary issue logged in classification metadata.

Only primary category written to ticket fields. Classification metadata field contains secondary issue note.

T06

Ambiguous ticket: confidence below threshold

Ticket body: 'Things are not working as expected.' No specific issue indicated.

Classification confidence below threshold. Ticket flagged for human review queue in Zendesk. No category or priority written.

Ticket routed to human review queue. No category/priority fields overwritten. Alert visible to Team Lead in Zendesk sandbox.

T07

HubSpot lookup fails: customer email not found

Ticket submitted from email address not present in HubSpot sandbox.

Classification proceeds using ticket body only. Plan tier defaults to Unknown. Priority and category still written.

Agent does not error out. Ticket fields written. Classification metadata notes HubSpot lookup returned no match.

T08

Zendesk write fails: API returns 422 error

Inject a 422 Unprocessable Entity response from Zendesk sandbox on field update.

Error logged with ticket ID and HTTP status. Retry attempted once. After retry failure, ticket placed in error queue.

Error log contains ticket ID, timestamp, HTTP 422, and retry count. Ticket appears in error queue. No silent failure.

Routing and Notification Agent — unit tests (T09 to T14)

Scenario

Input

Expected output

Pass criteria

T09

Happy path: billing ticket routed to billing agent

Classified ticket: category=Billing, priority=High. Routing rules loaded from Notion.

Ticket assigned to designated Billing agent in Zendesk. Internal context note added. Slack DM sent. Customer acknowledgement queued.

Zendesk assignee field matches billing agent. Internal note present on ticket. Slack message received in test workspace within 15 seconds.

T10

Happy path: technical ticket routed to technical agent

Classified ticket: category=Technical, priority=Normal.

Ticket assigned to Technical agent. Internal note added. Slack DM sent. Customer acknowledgement sent via Gmail.

Correct assignee. Note present. Slack DM contains ticket number, category, priority, and direct link.

T11

Customer acknowledgement email content verified

Classified ticket: category=Account Access, priority=Urgent. Customer email: test-customer@internal.test.

Gmail sends acknowledgement to test-customer@internal.test with ticket reference number and response window matching Urgent SLA.

Email received at test address. Body contains correct ticket reference. Response window text matches Urgent priority template.

T12

Internal context note content verified

Classified ticket with HubSpot data: plan tier=Enterprise, two open tickets in last 30 days.

Internal note on Zendesk ticket contains plan tier, open ticket count, and one-line issue summary.

Note body contains all three data points. No raw JSON or unformatted data visible in note.

T13

Slack API unavailable: notification delivery failure

Inject Slack API timeout on DM send step.

Error logged. Fallback: internal note on Zendesk ticket states Slack notification failed. Ticket assignment still completes.

Zendesk assignment and internal note written successfully. Slack failure logged with timestamp. Ticket not held pending Slack confirmation.

T14

Gmail send fails: authentication error

Inject Gmail OAuth token expiry on acknowledgement send step.

Error logged. Customer acknowledgement queued for retry. All upstream steps (assignment, note, Slack) unaffected.

Retry queue contains failed send with customer email and ticket ID. Upstream Zendesk and Slack steps confirmed complete. Error log entry present.

Test and QA PlanPage 2 of 4

FS-DOC-06Quality

03Phase 2 — integration and edge case tests

Integration tests verify that data flows correctly between the Ticket Classification Agent and the Routing and Notification Agent, and that each tool connection behaves as expected when both agents are running in sequence. IDs continue from Phase 1.

Scenario

Input

Expected output

Pass criteria

T15

Full handoff: classification output consumed by routing agent

New ticket created in Zendesk sandbox. Classification agent runs and writes category=Billing, priority=High. Routing agent fires on field update.

Routing agent reads category and priority fields written by classification agent without any manual intervention. Assignment executes correctly.

Routing agent trigger fires within 5 seconds of classification agent writing fields. No manual step required between agents.

T16

HubSpot data passed through handoff intact

Ticket from Enterprise customer. HubSpot data fetched in step 2 of pipeline. Data referenced in internal context note by routing agent.

Context note written by routing agent contains plan tier sourced from HubSpot lookup performed earlier in the pipeline.

Plan tier in context note matches HubSpot sandbox record. Data not re-fetched by routing agent (single lookup per ticket confirmed in logs).

T17

Human review path handoff: ambiguous ticket re-enters pipeline after manual review

Ticket flagged ambiguous by classification agent. Team Lead updates category and priority manually in Zendesk sandbox. Routing agent fires on field update.

Routing agent detects manual field update and executes assignment, note, Slack, and Gmail steps as normal.

Routing agent completes all four downstream actions after manual update. Logs confirm trigger source was manual field update, not classification agent.

T18

Routing rules loaded correctly from Notion

Routing agent initialises. Notion routing rules document queried at runtime.

Correct agent-to-category mappings applied. Billing to billing agent, Technical to technical agent, Account Access to senior agent queue.

All three category-to-agent mappings resolve correctly against Notion document. No hardcoded fallback used.

T19

Multiple tickets in rapid succession: no cross-contamination

Three tickets created in Zendesk sandbox within 10 seconds. Each has a different category and customer.

Each ticket classified and routed independently. No ticket receives another ticket's category, assignee, or customer data.

Three separate execution logs. Each log contains only the ticket ID and customer data corresponding to that ticket. Zero data bleed confirmed.

T20

End-to-end latency within SLA target

New ticket created in Zendesk sandbox. Timer starts at ticket creation.

Ticket fully assigned, noted, Slack sent, and Gmail acknowledgement dispatched within 120 seconds of ticket creation.

Execution log timestamps show total pipeline duration under 120 seconds for a standard ticket (non-ambiguous, HubSpot record found).

T21

Routing rule missing for ticket category

Ticket classified as category=Feature Request, which has no routing rule in Notion document.

Ticket routed to default fallback queue. Internal note states no specific routing rule matched. Team Lead notified via Slack.

Fallback queue receives ticket. Note body contains explicit statement of unmatched category. Slack alert sent to Team Lead Slack ID.

T22

Notion routing rules document updated mid-run: next ticket uses updated rules

Routing rules updated in Notion sandbox to reassign Technical tickets to a different agent. Next ticket submitted as Technical.

Routing agent applies updated rules on the next ticket without requiring a pipeline restart.

Technical ticket assigned to newly configured agent. Previous ticket unaffected. No restart required.

Edge case tests — the following scenarios cover failure modes, malformed data, and human timeout situations that fall outside the normal happy path.

Scenario

Input

Expected output

Pass criteria

E01

Duplicate ticket: same customer submits identical ticket twice within 5 minutes

Two tickets with identical subject, body, and sender email created in Zendesk sandbox within 5 minutes.

Both tickets processed independently. Duplicate flag added to second ticket's internal note. Neither ticket suppressed.

Second ticket note contains duplicate flag. Both tickets assigned and routed. No ticket silently dropped.

E02

Missing customer email on ticket: HubSpot lookup cannot execute

Ticket created in Zendesk sandbox with no requester email (submitted via API without email field).

Classification proceeds on ticket body alone. HubSpot lookup skipped. Plan tier defaults to Unknown. Ticket classified and routed.

Pipeline completes without error. Execution log notes HubSpot lookup skipped due to missing email. Internal note states plan tier unknown.

E03

Zendesk webhook unavailable: trigger does not fire

Zendesk sandbox webhook endpoint returns 503 for 60 seconds then recovers.

Automation platform detects webhook failure and retries delivery up to three times with exponential backoff. Ticket processed on recovery.

Retry log shows three attempts. Ticket processed within 30 seconds of webhook recovery. No duplicate processing on retry.

E04

HubSpot API rate limit hit: lookup returns 429

Inject 429 Too Many Requests from HubSpot sandbox API.

Classification agent waits for retry window specified in Retry-After header (or 60 seconds default), then retries once. If second attempt fails, ticket classified without CRM data.

Retry-After header respected. Second attempt made after wait period. On second failure, ticket proceeds with plan tier Unknown. Error logged.

E05

Human review timeout: Team Lead does not update ambiguous ticket within 30 minutes

Ticket flagged ambiguous and placed in human review queue. No manual update made within 30 minutes.

Escalation Slack alert sent to Team Lead with ticket link and urgency note. Ticket remains in human review queue. No auto-assignment.

Escalation Slack message received at Team Lead Slack ID at the 30-minute mark. Ticket not auto-assigned. Escalation event logged.

E06

Ticket body contains no text: empty or whitespace-only body

Ticket created in Zendesk sandbox with subject 'Help' and empty body.

Classification agent detects insufficient content. Confidence below threshold. Ticket routed to human review queue. No category or priority written.

Human review queue receives ticket. Classification metadata notes empty body detected. No fields overwritten. Team Lead alert triggered.

Test and QA PlanPage 3 of 4

FS-DOC-06Quality

04Phase 3 — end-to-end production test

Important before running Phase 3: use an internal test email address (for example triage-test@[YourCompany.com]) as the ticket requester for all production test runs. Do not use a real customer email address. After each test run, immediately update the test ticket status to Closed and add the internal tag qa-test-void so it is excluded from any reporting or SLA calculations. Confirm with the process owner that the test tag is filtered out of all support dashboards before Phase 3 begins. Any ticket created without the qa-test-void tag during Phase 3 must be manually reviewed and voided by the process owner within one business day.

Scenario

Input

Expected output

Pass criteria

T23

Full production run: standard billing ticket traced end to end

Ticket submitted via production Zendesk email channel from triage-test@[YourCompany.com]. Body: 'I was charged twice this month, please help.' Requester exists in production HubSpot as a Pro plan customer.

Pipeline executes in production: HubSpot lookup returns live record, category=Billing and priority=High written to live Zendesk ticket, ticket assigned to production billing agent, internal context note visible in live Zendesk, Slack DM received by billing agent in live workspace, acknowledgement email received at triage-test@[YourCompany.com].

All six outputs confirmed in production systems within 120 seconds. Execution log in the automation platform shows all steps green with timestamps. Test ticket tagged qa-test-void and closed immediately after confirmation.

T24

Production run: ambiguous ticket routes to human review queue

Ticket submitted via production Zendesk from triage-test@[YourCompany.com]. Body: 'Something is not right with my account.' Vague enough to fall below confidence threshold.

Classification agent flags ticket for human review in production Zendesk. No category or priority written. Team Lead receives Slack alert in live workspace. Ticket visible in human review queue.

Production Zendesk shows ticket in human review queue with no auto-assigned category or priority. Live Slack alert received by Team Lead. No auto-assignment made. Test ticket tagged qa-test-void and closed.

T25

Error log verification: structured logs present for all production run steps

Review automation platform execution logs for T23 and T24 runs.

Each step in the production execution log contains: step name, timestamp (UTC), input payload summary, output payload summary, HTTP status where applicable, and duration in milliseconds. No steps show null or missing log entries.

All steps in T23 and T24 execution logs are fully populated. No null entries. Any retried steps show retry count and final status. Logs accessible to FullSpec team via the automation platform dashboard.

T26

Process owner review and approval: final go-live sign-off

Process owner (Support Team Lead) reviews the T23 and T24 production run results, including the live Zendesk ticket records, the internal context notes, the Slack notifications, and the acknowledgement email received at the test address. FullSpec presents the execution logs and before-and-after comparison against the manual process.

Process owner confirms: correct classification applied, correct agent assigned, context note is accurate and useful, Slack notification is actionable, customer acknowledgement email is appropriately worded. Process owner records approval in the FullSpec platform confirmation screen.

FullSpec platform records the process owner's approval with name, role, and timestamp. This confirmation serves as the formal go-live authorisation. No separate signature block is required. Go-live is not permitted until this record is saved.

Once T26 approval is recorded in the FullSpec platform, the FullSpec team will remove all sandbox credentials, confirm production secrets are stored in the secrets manager only, disable the qa-test-void filter check, and schedule the first post-launch monitoring review for five business days after go-live. Contact support@gofullspec.com for any issues arising during or after Phase 3.

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