Back to Client Deposit & Payment Tracking

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

Client Deposit and Payment Tracking

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

This document defines the complete testing programme for the Client Deposit and Payment Tracking automation. It covers three sequential phases: unit testing of each agent in isolation, integration and edge-case testing across agent handoffs, and an end-to-end production run. The FullSpec team designs, executes, and records results for all three phases. The process owner joins Phase 3 to validate the production run and record formal approval. No phase begins until every test case in the preceding phase achieves a passing result.

01Testing approach

Testing runs in three phases in sequence. No phase begins until the previous phase fully passes. Phase 1 isolates each agent in a sandbox environment. Phase 2 validates cross-agent handoffs and edge conditions. Phase 3 runs a single traced production transaction with the process owner present. Each phase has a defined scope, environment rule, credential rule, pass condition, and ownership.

1
Phase 1: Unit Testing
Each agent tested in isolation against sandbox data
Scope
Individual agent logic: trigger detection, data parsing, tool writes, and output formation for Deposit Monitor Agent, Client Communication Agent, and Internal Notification Agent.
Environment
Sandbox only. No production Xero, Stripe, Gmail, HubSpot, Google Sheets, or Slack accounts are touched.
Credential rule
All credentials must be sandbox or test-mode equivalents. Stripe test-mode keys, Xero demo company, Gmail alias (no real client addresses), HubSpot sandbox portal, a dedicated test Google Sheet, and a private Slack test channel.
Pass condition
All test cases T01 through T15 return the expected output with no unhandled errors. Any failure blocks progression to Phase 2.
Who runs it
FullSpec team. Process owner is not required during Phase 1.
2
Phase 2: Integration and Edge-Case Testing
Agent handoffs and exception scenarios validated in sandbox
Scope
End-to-end data flow between agents, including overdue flag handoff, payment-confirmed handoff, and exception routing. Covers duplicate detection, missing data fields, unavailable tool responses, and human-review timeout handling.
Environment
Sandbox only. Simulated tool outages are injected using mock responses where required.
Credential rule
Same sandbox credentials as Phase 1. No production tokens used.
Pass condition
All integration test cases T16 through T22 and all edge-case tests E01 through E07 return the expected outputs. Any failure blocks progression to Phase 3.
Who runs it
FullSpec team. Process owner is not required during Phase 2.
3
Phase 3: End-to-End Production Test
Single traced production run with process owner sign-off
Scope
One complete invoice lifecycle executed against live production accounts: invoice creation in Xero, Stripe payment, Google Sheets logging, Gmail outbound, HubSpot activity record, Xero reconciliation, and Slack notification.
Environment
Production. All six connected tools are live. Test invoice and test payment must be voided after the run.
Credential rule
Production API credentials used for the first time. FullSpec confirms each credential is scoped correctly before the run begins. No sandbox tokens permitted.
Pass condition
All production test cases T23 through T26 pass, including the process owner review recorded as T26. Approval is logged in the FullSpec confirmation record.
Who runs it
FullSpec team executes T23 through T25. Process owner joins for T26 to review all outputs and record approval.
Test and QA PlanPage 1 of 4
FS-DOC-06Quality

02Phase 1 — unit test cases

Sandbox credentials only throughout Phase 1. Use Stripe test-mode keys, the Xero demo company, a Gmail alias with no real client addresses, the HubSpot sandbox portal, a dedicated test Google Sheet, and a private Slack test channel. Never connect a production token during unit testing.

Deposit Monitor Agent — build complexity: Moderate. Estimated build time: 14 hours.

ID
Scenario
Input
Expected Output
Pass Criteria
T01
Happy path: new invoice with deposit terms detected in Xero
Xero webhook payload with invoice_id, client_name, deposit_amount = $2,000, due_date = T+7 days
New row written to Google Sheets tracker: invoice_id, client_name, deposit_amount, due_date, status = Pending
Google Sheets row exists within 10 seconds of webhook receipt; all five fields populated correctly
T02
Stripe payment detected and matched to open deposit record
Stripe test payment: amount = $2,000, reference = INV-TEST-001, date within due_date window
Google Sheets row updated: status = Matched; matched_amount, payment_date, stripe_payment_id populated
All four fields updated within one polling cycle (max 24 hours in production; use 30-second interval in sandbox)
T03
Deposit due date passes with no matching Stripe payment
Open Google Sheets row with due_date = yesterday; no Stripe payment matched
Overdue flag written to Google Sheets: status = Overdue; overdue flag passed to Client Communication Agent
Status field reads Overdue; handoff payload contains invoice_id, client_name, deposit_amount, days_overdue
T04
Xero webhook received but required field deposit_amount is null
Xero webhook payload with deposit_amount = null
Record not written to Google Sheets; error logged with invoice_id and field name; no downstream action triggered
Error log entry created; Google Sheets row absent for this invoice_id; no agent handoff sent
T05
Stripe payment amount does not match any open deposit record
Stripe test payment: amount = $1,500, no matching open record at that amount
Unmatched payment flagged in Google Sheets as status = Unmatched; human review task created
Unmatched row exists in tracker; no auto-reconciliation triggered; no confirmation email sent
T06
Stripe API returns 429 rate-limit error during polling
Mock Stripe response: HTTP 429 with Retry-After: 60 header
Polling job pauses for 60 seconds then retries once; error logged if second attempt also fails
No duplicate polling; retry logged; downstream agents not triggered on error; alert written to error log

Client Communication Agent — build complexity: Moderate. Estimated build time: 12 hours.

ID
Scenario
Input
Expected Output
Pass Criteria
T07
Happy path: overdue chaser email sent and HubSpot activity logged
Overdue flag payload from Deposit Monitor Agent: invoice_id, client_email, client_name, deposit_amount = $2,000, days_overdue = 3
Gmail sends chaser email to client_email; HubSpot activity record created against matching contact: type = Email, subject = Overdue Deposit, date, amount
Email delivered to test inbox within 60 seconds; HubSpot activity record visible on contact timeline within 30 seconds
T08
Happy path: deposit confirmation email sent after payment matched
Payment confirmed payload: invoice_id, client_email, deposit_amount, remaining_balance, final_due_date
Gmail sends confirmation email to client_email with deposit_amount, remaining_balance, and final_due_date populated from template variables
Email delivered to test inbox; all three template variables resolved correctly; no placeholder strings visible in body
T09
HubSpot activity log created for confirmation email
Payment confirmed payload as T08
HubSpot activity record created: type = Email, subject = Deposit Received Confirmation, date, amount
Activity record present on HubSpot contact timeline; no duplicate records created
T10
Duplicate chaser prevention: second overdue flag for same invoice within 24 hours
Two consecutive overdue flag payloads for invoice_id = INV-TEST-001 within 24-hour window
First chaser sent and logged; second chaser suppressed; suppression event written to log
Only one Gmail send and one HubSpot activity record for INV-TEST-001; suppression log entry present
T11
HubSpot contact not found for client email
Overdue flag payload with client_email that has no matching HubSpot contact
Chaser email still sent via Gmail; HubSpot write skipped; warning logged with client_email and invoice_id
Email delivered; HubSpot write absent; warning log entry contains client_email and invoice_id; no process halt
T12
Gmail send fails with authentication error
Overdue flag payload; Gmail OAuth token expired (simulated 401 response)
Send attempt fails; error logged with HTTP status and invoice_id; retry queued after token refresh; no HubSpot activity logged until send succeeds
Error log entry present; no email delivered on first attempt; retry triggered after token refresh; activity only logged on successful send

Internal Notification Agent — build complexity: Simple. Estimated build time: 6 hours.

ID
Scenario
Input
Expected Output
Pass Criteria
T13
Happy path: Slack alert posted on full settlement confirmation
Full settlement payload from Deposit Monitor Agent: client_name, invoice_ref = INV-TEST-001, cleared_amount = $5,000, xero_invoice_status = PAID
Slack message posted to designated project channel: client_name, invoice_ref, cleared_amount all present in message body
Slack message appears in test channel within 15 seconds; all three data fields resolved; no placeholder text
T14
Slack channel not found or bot not invited
Full settlement payload; target channel ID returns 404 (channel_not_found)
Slack post fails; error logged with channel_id and invoice_ref; alert escalated to error log; no retry loop
Error log entry present with channel_id; no infinite retry; process marked as requiring manual notification
T15
Duplicate settlement trigger: same invoice fires twice within 60 seconds
Two full settlement payloads for invoice_ref = INV-TEST-001 within 60 seconds
First Slack message sent; second suppressed by idempotency check on invoice_ref; suppression logged
Only one Slack message in test channel for INV-TEST-001; suppression log entry present
Test and QA PlanPage 2 of 4
FS-DOC-06Quality

03Phase 2 — integration and edge case tests

Phase 2 validates data flow across agent boundaries and the system's resilience to malformed inputs, unavailable tools, and human-delay scenarios. Integration tests continue the T sequence from T16. Edge-case tests use the E sequence starting at E01.

ID
Scenario
Input
Expected Output
Pass Criteria
T16
Full overdue path handoff: Deposit Monitor Agent to Client Communication Agent
Invoice created in sandbox Xero; due date set to yesterday; no Stripe payment present
Deposit Monitor Agent sets status = Overdue and passes payload; Client Communication Agent sends chaser email and logs HubSpot activity
Chaser email in test inbox; HubSpot activity record present; Google Sheets status = Overdue; end-to-end elapsed time under 5 minutes
T17
Full payment-confirmed path handoff: Deposit Monitor Agent to Client Communication Agent to Internal Notification Agent
Stripe test payment matched to open deposit record; invoice marked PAID in sandbox Xero
Deposit Monitor Agent confirms match and updates Google Sheets; Client Communication Agent sends confirmation email and logs HubSpot activity; Internal Notification Agent posts Slack alert
All three downstream outputs present; correct data fields in each; no duplicate actions; total elapsed time under 3 minutes from Stripe match
T18
Bookkeeper manual review step: unmatched payment routed correctly
Stripe test payment with amount not matching any open deposit record
Google Sheets row marked Unmatched; no auto-reconciliation; no confirmation email sent; no Slack alert posted; human review flag visible in tracker
Unmatched row in tracker; downstream agents produce no output for this invoice; human review flag column populated
T19
Second chaser sent after first chaser with no payment response (48-hour schedule)
Overdue flag payload; first chaser already logged at T minus 48 hours; no payment received
Second chaser email sent via Gmail; new HubSpot activity record created (not a duplicate of first); Google Sheets chaser_count incremented to 2
Second email in test inbox; chaser_count = 2 in Google Sheets; two distinct HubSpot activity records with different timestamps
T20
Final payment reminder triggered after deposit confirmed and final_due_date reached
Deposit confirmed; remaining_balance > 0; final_due_date = today
Client Communication Agent sends final payment reminder email via Gmail; HubSpot activity record created: type = Email, subject = Final Payment Reminder
Final reminder in test inbox; HubSpot record present; no confirmation email re-sent; Google Sheets status remains Deposit Confirmed
T21
Xero reconciliation confirmed after Stripe match
Stripe payment matched; reconciliation action sent to sandbox Xero
Xero invoice deposit line marked as received; outstanding balance updated to remaining_balance; no duplicate payment applied
Xero invoice status updated correctly; outstanding balance equals invoice_total minus deposit_amount; reconciliation idempotent if triggered twice
T22
Downstream agent payload missing required field after handoff
Deposit Monitor Agent passes payload with client_email field absent
Client Communication Agent detects missing field; email send skipped; error logged with invoice_id and missing field name; HubSpot write skipped; Internal Notification Agent not triggered
No email sent; no HubSpot record created; error log entry contains invoice_id and field name client_email; process does not halt entirely

Edge-case tests — the following scenarios cover conditions outside the happy path that the automation must handle safely without corrupting data or triggering unintended client communications.

ID
Scenario
Input
Expected Output
Pass Criteria
E01
Duplicate invoice webhook received for the same invoice_id
Two Xero webhook payloads for invoice_id = INV-TEST-001 within 5 seconds
First payload processed; second payload rejected by idempotency check; only one Google Sheets row created for INV-TEST-001
Single Google Sheets row for INV-TEST-001; idempotency rejection logged; no duplicate downstream actions
E02
Invoice raised with deposit_amount = 0 (no deposit required)
Xero webhook with deposit_amount = 0
Record not written to tracker; no polling initiated; no chaser or confirmation emails sent; event logged as skipped
Google Sheets has no row for this invoice_id; skip log entry present; no emails sent
E03
Missing client reference on Stripe payment prevents matching
Stripe test payment with blank payment reference field; amount matches an open deposit record
Payment flagged as Unmatched in Google Sheets; human review flag set; no auto-reconciliation; no confirmation email
Unmatched status in tracker; no Xero reconciliation action; no Gmail confirmation; human review flag column populated
E04
Stripe API unavailable for full polling cycle (simulated 503)
Mock Stripe response: HTTP 503 for all requests during one polling window
Polling job logs service unavailable error; retries after back-off interval (5 minutes); no overdue flags fired based on stale data during outage window
Error log entry with HTTP 503; no incorrect Overdue status written; retry attempted after back-off; second cycle proceeds normally when service restored
E05
HubSpot contact name differs from Xero client name (casing or spacing mismatch)
Overdue flag payload where Xero client_name = 'Acme Corp' and HubSpot contact company = 'acme corp'
Fuzzy name match resolves contact; HubSpot activity logged against correct contact; mismatch noted in log for data-quality review
HubSpot activity record present on correct contact; mismatch warning in log; chaser email delivered; no duplicate contact created
E06
Xero sandbox returns timeout on reconciliation request
Reconciliation action sent to Xero; response times out after 30 seconds
Action retried once after 60-second wait; if second attempt fails, reconciliation flagged as pending manual completion; error logged with invoice_id
Retry attempted once; error log entry present after second failure; Google Sheets status set to Reconciliation Pending; no process halt
E07
Human review timeout: unmatched payment not actioned within 48 hours
Unmatched payment row in Google Sheets; human_review_assigned_at = 48 hours ago; no status update
Escalation Slack message posted to designated channel noting invoice_id, client_name, and hours elapsed; Google Sheets escalation_flag set to true
Slack escalation message present in test channel; escalation_flag = true in Google Sheets; original Unmatched status not overwritten
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 (not a real client address) for all Gmail sends during this run. Create the test invoice in Xero using a clearly labelled internal contact (e.g. 'FullSpec QA Test Client') so it cannot be confused with a live client record. Make the Stripe test payment using a test card in live mode only if your Stripe account supports it; otherwise simulate payment confirmation via a direct API call. After the run is complete, void the test invoice in Xero, delete or archive the Google Sheets test row, remove the HubSpot test activity record, and delete the Slack test message. Document the void action with a timestamp in the FullSpec confirmation record.

The following table covers the complete production trace, including the process owner approval as the final recorded test case. Test IDs continue from Phase 2.

ID
Scenario
Steps Traced
Expected Output
Pass Criteria
T23
Full production invoice lifecycle: deposit received on time
1. Create invoice in production Xero (contact: FullSpec QA Test Client, deposit = $500, due = today + 3 days). 2. Confirm webhook received by automation platform. 3. Verify Google Sheets row created. 4. Simulate Stripe payment of $500 with correct reference. 5. Confirm Stripe polling detects payment within next cycle. 6. Confirm Xero deposit line reconciled. 7. Confirm Gmail confirmation email delivered to test inbox. 8. Confirm HubSpot activity logged. 9. Confirm Slack alert posted to project channel.
All nine steps produce the correct output in sequence with no manual intervention. Total elapsed time from invoice creation to Slack alert is under 30 minutes (accounting for polling interval).
All nine outputs verified by FullSpec team and documented with screenshots. Elapsed time within limit. No error log entries generated.
T24
Full production overdue path: chaser sent and logged
1. Create invoice in production Xero with due_date = yesterday. 2. Confirm overdue flag raised in Google Sheets. 3. Confirm chaser email delivered to test inbox with correct invoice amount. 4. Confirm HubSpot activity record created. 5. Confirm no Slack alert posted (settlement not confirmed).
Chaser email delivered; HubSpot activity record present; Slack channel silent for this invoice_id.
Email content verified (correct amount, client name, no placeholder text). HubSpot record visible on test contact timeline. Slack alert absent. All outputs documented.
T25
Error log verification: confirm logging is active in production
1. Submit a malformed webhook payload (missing deposit_amount field) to the production automation endpoint. 2. Check error log destination (Google Sheets error tab or designated log store).
Error log entry created within 60 seconds containing: timestamp, invoice_id, missing field name, HTTP status code, and source agent identifier.
Error log entry present and correctly structured. No downstream agent actions triggered. Log entry documented by FullSpec team.
T26
Process owner review and approval
1. Process owner reviews: Google Sheets tracker (T23 and T24 rows), Gmail test inbox (confirmation email and chaser email), HubSpot test contact timeline (two activity records), Xero invoice status (PAID, deposit reconciled), Slack project channel (one payment cleared alert). 2. Process owner confirms all outputs match the expected process described in the SOP. 3. FullSpec team records approval in the FullSpec confirmation document with process owner name, timestamp, and any noted exceptions.
Process owner confirms all six output categories are correct and the automation is approved for go-live. Any exceptions noted are logged and actioned before the live switch is enabled.
Process owner sign-off recorded in the FullSpec confirmation record. No outstanding exceptions remain unresolved. Go-live authorisation granted.
Once T26 is recorded, the FullSpec team will void the test invoice in Xero, remove all test data across connected tools, and enable the live trigger. The process owner will receive a confirmation email at support@gofullspec.com summarising the approved test run and the go-live timestamp.
Test and QA PlanPage 4 of 4

More documents for this process

Every document generated for Client Deposit & Payment Tracking.

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