FS-DOC-06Quality
Test and QA Plan
Warranty & Guarantee Claim Handling
[YourCompany.com] · Customer Support Department · Prepared by FullSpec · [Today's Date]
This document defines the structured quality assurance process for the Warranty and Guarantee Claim Handling automation. It is intended for the FullSpec build team and covers every test case required before any phase of the automation is promoted to production. Testing runs in three sequential phases: unit tests on individual agents, integration and edge-case tests across agent handoffs, and a final end-to-end production run. No phase begins until the previous phase has fully passed. The process owner joins Phase 3 only, to review the live run and record approval.
01Testing approach
All testing follows three phases in sequence. No phase begins until the previous phase fully passes. Phase 1 tests each agent in isolation using sandbox credentials. Phase 2 tests agent-to-agent handoffs and edge cases that arise from real-world data problems. Phase 3 runs the full flow against the production environment with live credentials and real claim data, observed by the process owner.
1Phase 1: Unit Testing
Individual agent validation in sandbox
Scope
Each agent tested independently: Claim Intake Agent, Eligibility and Routing Agent, Resolution Confirmation Agent.
Environment
Sandbox only. No production data or live credentials used at any point during Phase 1.
Credential rule
Sandbox API keys for Zendesk, Gmail, Shopify, Google Sheets, and Slack. No production tokens permitted.
Pass condition
All test cases T01 through T12 return the expected output with no unhandled errors.
Who runs it
FullSpec team only.
2Phase 2: Integration and Edge Case Testing
Agent handoffs and failure-mode validation in sandbox
Scope
End-to-end agent handoffs (Claim Intake to Eligibility and Routing; Eligibility and Routing to Resolution Confirmation) and all documented edge cases.
Environment
Sandbox only. Synthetic claim records and sandbox order data used throughout.
Credential rule
Sandbox credentials only. Slack test workspace used for approval message tests.
Pass condition
All integration test cases T13 through T18 pass, and all edge-case tests E01 through E06 pass with correct exception handling and no silent failures.
Who runs it
FullSpec team only.
3Phase 3: End-to-End Production Test
Full live-environment run with process owner review
Scope
One complete claim traced from submission through to closed Zendesk ticket in the production environment, plus error-log verification and process owner approval.
Environment
Production. Live Zendesk, Gmail, Shopify, Google Sheets, and Slack credentials active.
Credential rule
Production OAuth tokens used. All tokens must be rotated from sandbox values before Phase 3 begins. Test records voided after each run.
Pass condition
All production test cases T19 through T22 pass; process owner records approval, which is logged in the FullSpec confirmation record.
Who runs it
FullSpec team executes; process owner (Support Lead) joins to observe and sign off on T22.
Test and QA PlanPage 1 of 4
FS-DOC-06Quality
02Phase 1 — unit test cases
Sandbox credentials only during Phase 1. Do not connect production Zendesk, Gmail, Shopify, Google Sheets, or Slack tokens at any point in this phase. Use the dedicated sandbox API keys documented in the Developer Handover Pack. Any test that inadvertently touches a production record must be flagged to support@gofullspec.com immediately before continuing.
Claim Intake Agent — monitors the Gmail inbox and Zendesk form queue, extracts structured data, creates a Zendesk ticket, and sends an acknowledgement email. Complexity: Moderate. Estimated build time: 10 hours.
ID
Scenario
Input
Expected Output
Pass Criteria
T01
Happy path: well-formed email claim
Gmail inbox receives a claim email with customer name, order number, product SKU, and fault description all present.
Zendesk ticket created with all fields populated; acknowledgement email sent to customer within 30 seconds.
Ticket exists in Zendesk sandbox with correct field values; Gmail sandbox shows sent acknowledgement with claim reference number.
T02
Happy path: Zendesk web form submission
Claim submitted via Zendesk sandbox form with all required fields completed.
Zendesk ticket created; acknowledgement email dispatched via Gmail.
Ticket ID generated; form field values map correctly to ticket fields; email delivered to sandbox recipient.
T03
Claim email with no order number
Gmail inbox receives a claim email where the order number field is blank.
Ticket created with order number flagged as missing; acknowledgement sent; ticket tagged 'requires-manual-lookup'.
Ticket tag 'requires-manual-lookup' present; no automation failure; acknowledgement still sent.
T04
Duplicate claim submission (same customer, same fault within 24 hours)
A second identical claim email arrives from the same sender within 24 hours of T01.
Automation detects probable duplicate; suppresses second ticket creation; logs a duplicate-detection note on the original ticket.
Only one ticket exists for the customer; original ticket has a system note indicating duplicate suppressed.
T05
Malformed email body (no recognisable claim fields)
An email arrives in the monitored inbox that contains no structured claim data (e.g. a newsletter).
Email ignored or routed to unmatched-message log; no Zendesk ticket created; no acknowledgement sent.
Zendesk sandbox has no new ticket; unmatched-message log entry recorded by the automation platform.
Eligibility and Routing Agent — queries Shopify for the order record, checks purchase date and SKU against the Google Sheets warranty rules table, classifies the claim, routes for auto-resolution or Slack manager approval, and logs the row in the tracker. Complexity: Complex. Estimated build time: 18 hours.
ID
Scenario
Input
Expected Output
Pass Criteria
T06
Happy path: claim within standard warranty terms, below value threshold
Zendesk ticket with order number matching a Shopify sandbox order purchased 6 months ago; product warranty period is 12 months; claim value $80.
Eligibility verdict: approved; resolution type: replacement; Google Sheets tracker row written; no Slack message sent.
Sheets tracker has new row with correct claim ID, resolution type 'replacement', and status 'auto-approved'. No Slack message in sandbox workspace.
T07
Happy path: claim above value threshold, routed for manager approval
Order value $320; claim type: full refund; exceeds the manager-approval threshold defined in Google Sheets.
Slack approval message sent to manager channel; Google Sheets row written with status 'pending-approval'; no resolution sent to customer.
Slack sandbox shows structured approval message with claim reference, order total, and approve/reject buttons. Sheets row status is 'pending-approval'.
T08
Order not found in Shopify
Claim ticket references an order number that does not exist in the Shopify sandbox store.
Eligibility verdict: unable-to-verify; Zendesk ticket tagged 'order-not-found'; Slack alert sent to support queue channel.
Ticket tag 'order-not-found' present; Slack sandbox shows alert in support channel; no resolution email sent.
T09
Claim outside warranty period
Shopify order confirmed; purchase date is 14 months ago; product warranty is 12 months.
Eligibility verdict: ineligible; resolution type: rejection; customer notified via Zendesk with rejection template; ticket closed.
Zendesk ticket status is 'closed'; customer receives rejection email with warranty-period explanation; Sheets row status is 'rejected'.
T10
Warranty rules table row missing for the product SKU
Shopify order found; product SKU not present in the Google Sheets warranty rules table.
Claim flagged as 'rules-not-found'; routed to manual review queue; Slack alert sent; no auto-resolution.
Slack sandbox alert references the missing SKU; Zendesk ticket tagged 'manual-review-required'; Sheets row written with status 'rules-missing'.
T11
Shopify API rate limit hit during batch processing
Simulation of 10 simultaneous claim tickets triggering concurrent Shopify order lookups.
Automation applies exponential back-off retry; all lookups complete within 60 seconds; no claims lost.
All 10 Sheets tracker rows written successfully; no unhandled errors in automation platform logs; retry events visible in log.
Resolution Confirmation Agent — sends the final resolution message to the customer via Zendesk and closes the ticket, triggered by manager approval in Slack or by the auto-approve path. Complexity: Simple. Estimated build time: 6 hours.
ID
Scenario
Input
Expected Output
Pass Criteria
T12
Happy path: auto-approved claim, resolution confirmation sent
Eligibility and Routing Agent sets status to 'auto-approved' for a standard in-warranty claim.
Resolution email sent to customer via Zendesk with resolution details; ticket closed automatically.
Zendesk ticket status is 'closed'; customer sandbox inbox contains resolution email with correct claim reference and resolution type.
T13
Manager approves claim via Slack
Manager clicks 'Approve' on the Slack message generated by T07.
Approval webhook triggers Resolution Confirmation Agent; resolution email sent; ticket closed; Sheets row updated to 'resolved'.
Zendesk ticket closed; Sheets row status updated from 'pending-approval' to 'resolved'; customer receives resolution email within 60 seconds of Slack approval.
Test and QA PlanPage 2 of 4
FS-DOC-06Quality
03Phase 2 — integration and edge case tests
Integration tests confirm that data passes correctly across agent boundaries and that each agent's output triggers the next agent's action without loss or transformation errors. All tests in this phase remain in the sandbox environment.
ID
Scenario
Input
Expected Output
Pass Criteria
T14
Claim Intake Agent to Eligibility and Routing Agent handoff: ticket payload completeness
T01 output ticket from Claim Intake Agent passed as input to Eligibility and Routing Agent.
All required fields (customer email, order number, product SKU, fault description, Zendesk ticket ID) are present and correctly typed in the handoff payload.
Eligibility and Routing Agent receives payload with zero null required fields; no schema validation errors in automation platform logs.
T15
Eligibility and Routing Agent to Resolution Confirmation Agent handoff: auto-approve path
Eligibility verdict payload with status 'auto-approved' and resolution type 'replacement'.
Resolution Confirmation Agent triggers immediately; resolution email sent; ticket closed.
Time from Eligibility Agent completing to Resolution email sent is under 30 seconds; Zendesk ticket status is 'closed'.
T16
Eligibility and Routing Agent to Resolution Confirmation Agent handoff: Slack-approval path
Slack approval webhook payload with action 'approved', claim reference, and approver user ID.
Resolution Confirmation Agent triggers; resolution email sent; Sheets row updated; ticket closed.
Webhook received and parsed correctly; resolution email delivered to sandbox customer; Sheets status updated to 'resolved'.
T17
Manager rejects claim via Slack
Manager clicks 'Reject' on the Slack approval message.
Rejection webhook received; customer notified of ineligibility via Zendesk; ticket closed; Sheets row updated to 'rejected'.
Customer receives rejection email; Sheets row status is 'rejected'; Zendesk ticket is closed.
T18
Google Sheets write failure during tracker update
Simulated Google Sheets API timeout during the Eligibility and Routing Agent tracker write step.
Automation retries write up to 3 times with back-off; if all retries fail, Slack alert sent to support channel; claim processing continues.
Slack support channel receives alert referencing the failed write and the claim ID; no claim is silently dropped; retry log visible in platform.
Edge case tests cover scenarios involving data quality problems, missing information, unavailable tools, and human response timeouts. Each must be handled gracefully without silent failures or stalled claims.
ID
Scenario
Input
Expected Output
Pass Criteria
E01
Duplicate claim detected across a 48-hour window
Two claim submissions from the same customer email referencing the same order number, submitted 36 hours apart.
Second submission flagged as probable duplicate; support team notified via Slack; second ticket suppressed or merged with original.
Only one active Zendesk ticket per customer-order pair; Slack alert references both submission timestamps; no double resolution sent.
E02
Claim submitted with missing customer email address
Zendesk form submission where the email field is blank.
Claim intake completes ticket creation but acknowledgement email step is skipped; ticket tagged 'no-email-address'; Slack support alert raised.
Zendesk ticket exists with tag 'no-email-address'; no email send attempted; Slack alert visible in support channel within 60 seconds.
E03
Shopify unavailable (5xx error) for more than 3 retries
Shopify sandbox endpoint returns 503 for 4 consecutive calls during order lookup.
After 3 retries with back-off, claim is placed in a 'pending-shopify-lookup' holding state; Slack alert sent to support channel; no resolution attempted.
Zendesk ticket tagged 'pending-shopify-lookup'; Slack alert references claim ID and Shopify error code; automation does not proceed to eligibility check.
E04
Zendesk API unavailable during ticket creation
Zendesk sandbox returns 503 during the Claim Intake Agent ticket creation step.
Automation retries up to 3 times; on persistent failure, raw claim data written to a Google Sheets fallback log; Slack alert raised.
Google Sheets fallback log has a new row containing the raw claim data; Slack alert references the failed ticket creation; no data lost.
E05
Manager does not respond to Slack approval request within the timeout window (4 hours)
Slack approval message sent for a high-value claim; no manager action taken within 4 hours.
Timeout escalation rule triggers; a second Slack message is sent to a secondary escalation contact; claim remains in 'pending-approval' state.
Second Slack message visible in sandbox workspace addressed to the secondary contact; original claim has not been auto-resolved or dropped; Zendesk ticket still open.
E06
Claim form submitted with a customer email that differs from the Shopify order email
Claim submitted with email address that does not match any Shopify order; customer includes order number in the notes field.
Automation falls back to order-number lookup using the notes field; if found, processing continues; if not found, claim tagged 'manual-fallback' and Slack support alert raised.
If order found via fallback: processing continues normally. If not found: Zendesk ticket tagged 'manual-fallback'; Slack alert includes raw notes field content for manual investigation.
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 (e.g. warranty-test@[YourCompany.com]) as the claim submitter for all production test runs. Do not use a real customer email address. After each test run, void the Zendesk ticket, remove the Google Sheets tracker row, and cancel any Shopify order records created for testing. Confirm with the FullSpec team that all test records have been cleared before the process goes live. Contact support@gofullspec.com if any production record cannot be cleanly voided.
Phase 3 tests the complete automation in the live production environment. The FullSpec team executes each test case. The process owner (Support Lead) observes and participates in T22, which records their formal approval. That approval is logged in the FullSpec confirmation record and serves as the go-live sign-off. No separate signature document is required.
ID
Scenario
Input
Expected Output
Pass Criteria
T19
Full production run: standard in-warranty claim, auto-resolved
Test claim email sent from internal test address to the live monitored Gmail inbox; order number references a real Shopify order within the warranty period; claim value below manager-approval threshold.
Zendesk ticket created and populated; acknowledgement email sent to test address within 2 minutes; Shopify order confirmed; eligibility approved; Sheets tracker row written; resolution confirmation email sent; ticket closed automatically.
All six steps complete without error in production environment. Acknowledgement email received by test address within 2 minutes. Zendesk ticket status is 'closed'. Sheets tracker row shows correct claim ID, resolution type, and date. No errors in automation platform production logs.
T20
Full production run: high-value claim, Slack approval path
Test claim submitted via production Zendesk form; order total above manager-approval threshold set in Google Sheets.
Claim Intake Agent creates ticket and sends acknowledgement; Eligibility and Routing Agent routes to Slack approval; manager (or FullSpec acting as proxy) approves; Resolution Confirmation Agent sends resolution email; ticket closed.
Slack approval message appears in the live manager channel within 60 seconds of ticket creation. Resolution email sent within 60 seconds of Slack approval. Sheets row status updated to 'resolved'. Zendesk ticket closed.
T21
Error-log verification: confirm all production run events are captured
Review the automation platform production logs after T19 and T20 have completed.
All execution steps logged with timestamps, input payloads, output values, and HTTP response codes for each API call to Zendesk, Gmail, Shopify, Google Sheets, and Slack.
No execution steps are absent from the log. All API calls show 2xx response codes. Any retry events (if triggered) are logged with retry count and final outcome. Log entries are retained and accessible to the FullSpec team.
T22
Process owner review and approval (go-live gate)
Process owner (Support Lead) is walked through the T19 and T20 production run outputs by the FullSpec team: ticket contents, acknowledgement email, Sheets tracker row, Slack message, resolution email, and error logs.
Process owner confirms that all outputs match the expected business behaviour documented in the SOP, that the Slack approval message contains sufficient information for a manager to make a decision, and that the Sheets tracker row is correctly formatted for the support team's reporting needs. Process owner records approval verbally or in writing with the FullSpec team, which is logged in the FullSpec confirmation record.
Process owner approval recorded in FullSpec confirmation record. Go-live authorised. No outstanding issues flagged by the process owner. FullSpec team marks Phase 3 as passed and proceeds to handoff.
Once T22 is passed and the FullSpec confirmation record is updated, the automation is considered production-ready. The FullSpec team will hand over the SOP/Runbook to the Support Lead and confirm monitoring is active. For any post-launch issues, contact support@gofullspec.com.
Test and QA PlanPage 4 of 4