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

Complaint Escalation Workflow

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

This document defines every test case the FullSpec team will execute before the Complaint Escalation Workflow goes live in your environment. Testing runs in three sequential phases: unit tests against isolated agents, integration tests covering agent handoffs and edge cases, and a final end-to-end run in production. No phase begins until every case in the previous phase passes. The process owner joins Phase 3 to confirm the workflow behaves correctly against real complaints and to record formal approval. Contact support@gofullspec.com with any questions about individual test cases or results.

01Testing approach

All testing follows three sequential phases. Each phase must reach a full pass before the next phase is permitted to start. This ensures defects caught at the unit level are resolved before they can propagate into integration or production runs, and that the support team's sign-off is based on a fully validated system, not one that still carries open issues.

Phase 1: Unit Tests

Each agent tested in isolation against sandbox data

Scope

Individual agent logic: Complaint Triage Agent and Escalation and Routing Agent tested separately with mocked inputs and outputs.

Environment

Sandbox only. No production Zendesk tickets, HubSpot records, Slack channels, or Gmail accounts are touched.

Credential rule

Sandbox API keys for Zendesk and HubSpot; test Slack workspace; a dedicated test Gmail address. No production credentials loaded at this phase.

Pass condition

All cases T01 through T10 return the expected output with no unhandled exceptions. Zero cases in a failing state before Phase 2 begins.

Who runs it

FullSpec team only. Process owner is not required for Phase 1.

Phase 2: Integration and Edge Case Tests

Agent handoffs and failure scenarios tested end to end in sandbox

Scope

Full agent-to-agent handoff from Complaint Triage Agent to Escalation and Routing Agent, plus edge cases covering duplicate submissions, missing data, tool unavailability, and human timeout scenarios.

Environment

Sandbox throughout. Slack test workspace, Gmail test address, and Zendesk sandbox instance remain active. HubSpot sandbox used for all CRM calls.

Credential rule

Same sandbox credentials as Phase 1. Production credentials remain locked out.

Pass condition

All integration cases T11 through T17 and all edge cases E01 through E07 pass with correct outputs, graceful error handling, and no orphaned workflow executions.

Who runs it

FullSpec team only. Process owner may observe but formal sign-off is not required.

Phase 3: End-to-End Production Test

Live production environment with real credentials and a traced test complaint

Scope

One complete production run traced from complaint submission through triage, routing, acknowledgement, and overdue escalation. Error log verification and process owner approval included.

Environment

Production: live Zendesk instance, production HubSpot, real Slack channels (test messages flagged clearly), Gmail production account using an internal test address.

Credential rule

Production OAuth tokens and API keys used for the first time. All production credentials must be provisioned and stored in the secret manager before this phase begins.

Pass condition

All cases T18 through T21 pass, the test Zendesk ticket is voided and deleted, and the process owner formally approves the workflow. Approval is recorded in the FullSpec confirmation log (case T21).

Who runs it

FullSpec team leads execution. Process owner is required to participate in T21 (review and approval).

Test and QA PlanPage 1 of 4

FS-DOC-06Quality

02Phase 1 — unit test cases

Sandbox credentials only. Do not load production API keys into the automation platform during Phase 1. Use the dedicated Zendesk sandbox, HubSpot sandbox, test Slack workspace, and the internal Gmail test address (e.g. qa-test@[YourCompany.com]) for every case below. Any case that accidentally touches a production record must be voided immediately and the phase restarted.

Complaint Triage Agent

Scenario

Input

Expected Output

Pass Criteria

T01

Happy path: low-severity complaint

Sandbox Zendesk ticket created from a polite, first-time customer email. HubSpot sandbox record shows no prior complaints.

Severity score: low. Category: general enquiry. HubSpot context appended to ticket.

Triage output object contains severity=low, category populated, customer_context object non-null.

T02

Happy path: medium-severity complaint

Sandbox ticket with frustrated tone and mention of partial refund. Customer has one prior complaint in HubSpot sandbox.

Severity score: medium. Category: billing. Customer history note appended.

Severity field returns medium; category field returns billing; prior_complaint_count=1 in enriched data.

T03

Happy path: high-severity complaint

Sandbox ticket containing strong negative sentiment, legal threat keywords, and a HubSpot sandbox record showing lifetime value above $5,000.

Severity score: high. Category: legal/escalation. Full customer record with LTV appended.

Severity=high; category contains escalation flag; LTV field populated from HubSpot sandbox response.

T04

HubSpot lookup fails: contact not found

Sandbox Zendesk ticket where the customer email has no matching record in HubSpot sandbox.

Severity scored from complaint text alone. HubSpot context field set to null with a not_found flag.

Agent completes without throwing an exception; context_source field returns email_only; ticket updated.

T05

HubSpot API timeout

Simulate HubSpot sandbox returning a 504 after 10 seconds.

Agent retries once after 5 seconds, then proceeds with text-only scoring. Ticket tagged with hubspot_timeout.

Retry attempt logged; agent does not stall; ticket receives severity score and timeout tag within 30 seconds total.

T06

Complaint text is empty

Zendesk sandbox ticket created with a blank body (e.g. a malformed form submission).

Severity defaulted to medium. Category set to unclassified. Ticket tagged with triage_review_needed.

No unhandled null-pointer exception; default values applied; triage_review_needed tag present on ticket.

T07

Non-English complaint text

Sandbox ticket containing complaint text in Spanish.

Sentiment analysis runs on detected language or falls back to keyword matching. Severity assigned; language tag added.

Severity field populated; language_detected field set to es; no exception thrown.

Escalation and Routing Agent

Scenario

Input

Expected Output

Pass Criteria

T08

Happy path: low-severity routing

Triage output: severity=low, category=general enquiry. Agent pool available in Zendesk sandbox.

Ticket assigned to next available agent. Slack notification sent to agent in test workspace. Acknowledgement email sent from test Gmail.

Zendesk sandbox ticket shows assignee populated; Slack test channel receives agent notification; Gmail test inbox receives acknowledgement within 60 seconds.

T09

Happy path: high-severity routing with manager alert

Triage output: severity=high. Manager Slack user configured in test workspace.

Ticket assigned to senior agent. Agent Slack notification sent. Separate manager alert sent in test workspace. Acknowledgement email sent.

Two distinct Slack messages received in test workspace (agent and manager); ticket assigned to senior_agent group in Zendesk sandbox; Gmail acknowledgement delivered.

T10

Slack notification delivery failure

Simulate Slack test workspace returning a 429 rate-limit error on first send attempt.

Agent retries after a 60-second back-off. If second attempt fails, error logged and ticket tagged with slack_notify_failed.

Retry logic executes; on persistent failure the slack_notify_failed tag appears on the ticket; no exception propagates to the orchestration layer.

Test and QA PlanPage 2 of 4

FS-DOC-06Quality

03Phase 2 — integration and edge case tests

Integration tests validate the handoff from the Complaint Triage Agent to the Escalation and Routing Agent, ensuring the enriched triage payload is correctly consumed and that all downstream tool writes succeed in the correct sequence.

Scenario

Input

Expected Output

Pass Criteria

T11

Full handoff: low severity end to end in sandbox

New sandbox Zendesk ticket from a low-frustration email. Full HubSpot sandbox record exists.

Triage agent scores low, enriches ticket. Routing agent assigns ticket, sends Slack agent notification, sends Gmail acknowledgement. All within 90 seconds.

All four tool writes confirmed in sandbox logs: Zendesk update, HubSpot read, Slack message, Gmail send. Total elapsed time under 90 seconds.

T12

Full handoff: high severity end to end in sandbox

Sandbox ticket with legal threat keywords and high-LTV HubSpot record.

Triage scores high. Routing agent assigns to senior queue, sends two Slack messages (agent and manager), sends high-priority acknowledgement email.

Zendesk sandbox ticket shows priority=urgent; two Slack messages in test workspace; Gmail acknowledgement subject line contains High Priority indicator.

T13

Triage output schema mismatch

Manually post a malformed triage payload (missing category field) to the routing agent input.

Routing agent detects missing field, defaults category to unclassified, logs a schema_warning, and completes routing.

No workflow crash; schema_warning entry in execution log; ticket routed and notifications sent with category=unclassified.

T14

Overdue escalation alert fires correctly

Sandbox ticket created and intentionally left unresolved. Overdue threshold set to 2 minutes for testing purposes.

After 2 minutes, routing agent fires a Slack escalation alert to the manager and updates ticket priority in Zendesk sandbox.

Slack escalation alert received in test workspace within 10 seconds of threshold breach; Zendesk sandbox ticket priority incremented.

T15

Gmail acknowledgement personalisation by severity tier

Three sandbox tickets submitted simultaneously: one low, one medium, one high.

Three distinct acknowledgement emails sent from test Gmail, each with the correct expected response time: 24 hours (low), 4 hours (medium), 1 hour (high).

Three emails received in test inbox; subject and body response-time values match severity tier mapping defined in the build spec.

T16

Gmail send failure: SMTP error

Simulate Gmail sandbox returning a 500 error on acknowledgement send.

Agent logs a gmail_send_failed error, retries once after 30 seconds, tags the Zendesk ticket with ack_email_failed if retry also fails.

Retry attempt present in execution log; ack_email_failed tag on ticket; routing and Slack steps still complete successfully.

T17

Concurrent complaint volume: 10 tickets simultaneously

Submit 10 sandbox Zendesk tickets in rapid succession to simulate a complaint burst.

All 10 tickets processed independently with no queue starvation. All receive a triage score, routing assignment, and acknowledgement email within 3 minutes.

Execution log shows 10 independent workflow runs with no overlapping state contamination; all 10 Gmail test-inbox messages received within 3 minutes.

Edge case tests cover conditions that fall outside the normal complaint flow but are realistic given the process volume of approximately 90 complaints per month.

Scenario

Input

Expected Output

Pass Criteria

E01

Duplicate complaint submission

The same customer submits the identical complaint twice within 5 minutes (e.g. double form submission).

Second ticket is detected as a duplicate via email address and subject match. Duplicate tagged in Zendesk and merged with the original. Only one acknowledgement sent.

Zendesk sandbox shows one active ticket with duplicate tag on the second; only one Gmail acknowledgement delivered to test inbox.

E02

Missing customer email address

Complaint submitted via web form with no email field populated.

Ticket created in Zendesk. HubSpot lookup skipped. Severity scored from text. Ticket tagged with missing_contact_email. Acknowledgement not sent.

no_email tag present; HubSpot call not made (confirmed in API request log); acknowledgement step skipped; triage score still applied.

E03

Zendesk API unavailable

Simulate Zendesk sandbox returning 503 at ticket creation step.

Workflow retries ticket creation up to three times with exponential back-off (30s, 60s, 120s). After three failures, an alert is sent to the internal Slack ops channel and the raw complaint is stored in the error queue.

Three retry attempts logged with correct back-off intervals; Slack ops channel receives failure alert; error queue contains the raw payload for manual recovery.

E04

Complaint contains only an attachment, no text body

Email complaint submitted with a PDF attachment and a blank body.

Ticket created. Text body set to attachment_only. Severity defaulted to medium. Ticket tagged with manual_review_required.

manual_review_required tag on ticket; severity=medium; no exception from the sentiment analysis step when passed an empty string.

E05

Agent assigned in Zendesk is no longer active

Routing agent attempts to assign a ticket to a Zendesk sandbox user whose account has been deactivated.

Routing falls back to the default support queue. Ticket tagged with routing_fallback. Slack notification sent to the queue channel rather than a named agent.

routing_fallback tag present; ticket sits in default queue; Slack notification delivered to queue channel in test workspace.

E06

Human agent does not acknowledge ticket within SLA window

Ticket assigned in Zendesk sandbox. Agent takes no action. Overdue threshold set to 3 minutes for test.

Escalation alert fires to manager Slack channel. Ticket priority upgraded in Zendesk. A second alert fires at 6 minutes if still unresolved.

First escalation Slack message received at 3-minute mark; priority incremented in Zendesk; second message at 6-minute mark if ticket open status unchanged.

E07

HubSpot returns a contact with no complaint history but very high LTV

Sandbox ticket from a new customer email matched to a HubSpot sandbox contact with LTV of $12,000 and zero prior support tickets.

Triage agent upgrades severity from its text-based score (medium) to high due to LTV rule. Routing agent triggers manager alert.

Severity in triage output=high with reason=ltv_override; manager Slack alert received in test workspace despite no negative text signals.

Test and QA PlanPage 3 of 4

FS-DOC-06Quality

04Phase 3 — end-to-end production test

Important before running Phase 3: All test complaints submitted during this phase must use an internal test email address (e.g. qa-test@[YourCompany.com]) as the customer contact. Do not use a real customer email address. Every Zendesk ticket created during Phase 3 must be voided, deleted, or clearly marked as TEST before the end of the session. The FullSpec team will confirm deletion. Any HubSpot activity created by the test run must also be removed from the production contact record. Confirm with your Zendesk and HubSpot administrators that test records have been cleared before the workflow is opened to live complaints.

Scenario

Input

Expected Output

Pass Criteria

T18

Full production run: high-severity complaint traced end to end

Internal test address submits a complaint email with high-frustration language and a production HubSpot contact record with high LTV attached.

Production Zendesk ticket created automatically. Triage agent scores high and enriches ticket with live HubSpot data. Routing agent assigns to senior queue, sends two Slack alerts (agent and manager) in the live workspace, and sends a personalised high-priority acknowledgement from the production Gmail account. All steps complete within 3 minutes.

Live Zendesk ticket visible with correct severity, assignee, and HubSpot context. Two Slack messages received in live workspace. Gmail acknowledgement received in the test inbox. Total elapsed time logged under 3 minutes. All steps confirmed in the orchestration execution log.

T19

Production overdue escalation alert

After T18 ticket is created, leave it unresolved. Overdue threshold temporarily set to 5 minutes for the test.

At the 5-minute mark, a Slack escalation alert is posted in the live manager channel. The Zendesk ticket priority is upgraded in production.

Slack alert received in live manager channel at or before the 5-minute mark. Zendesk ticket priority field updated. Execution log entry confirms the overdue trigger fired.

T20

Error log and monitoring verification

Review the orchestration execution log and any configured error alerting channel after T18 and T19 complete.

Execution log shows all workflow steps with timestamps, input/output payloads, and no unresolved error states. Any warnings flagged in Phase 1 or 2 are absent from the production log.

Zero unhandled exceptions in the production execution log. All step statuses show success or expected_warning (e.g. hubspot_ltv_override). Monitoring alert channel shows no active incidents.

T21

Process owner review and approval

Process owner reviews the T18 ticket in Zendesk, the two Slack messages, the Gmail acknowledgement, and the T19 escalation alert. FullSpec presents the execution log side by side.

Process owner confirms all outputs match the agreed workflow design. Test Zendesk ticket voided and deleted. Process owner approval recorded in the FullSpec confirmation log.

Process owner formally approves. Approval timestamp, reviewer name, and FullSpec confirmation reference recorded in the FullSpec system. This case constitutes the official go-live sign-off. No separate signature block is required.

After T21 passes, the FullSpec team will remove the temporary overdue threshold used in T19 and restore the agreed production SLA deadlines confirmed with the support manager during discovery. The workflow is then cleared for live traffic. Reach out to support@gofullspec.com if any case remains open or if a defect is discovered during the Phase 3 run.

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