FS-DOC-06Quality
Test and QA Plan
Purchase Approval Workflow
[YourCompany.com] · Finance Department · Prepared by FullSpec · [Today's Date]
This document defines the complete quality assurance programme for the Purchase Approval Workflow automation. It is written for the FullSpec build team and covers every scripted test case across three sequential phases: unit testing of individual agents, integration and edge-case testing of agent handoffs and exception paths, and end-to-end production verification. No phase begins until the previous phase fully passes. The process owner joins Phase 3 to confirm the live workflow meets the agreed acceptance criteria, and that sign-off is recorded in the FullSpec confirmation system rather than a separate document.
01Testing approach
Testing runs in three sequential phases. Each phase must reach a full pass before the next phase is opened. Phase 1 isolates every agent and confirms it behaves correctly on its own. Phase 2 tests the connections between agents and verifies that the workflow handles abnormal inputs safely. Phase 3 executes a complete live run in the production environment with the process owner present to review and formally accept the outcome.
1Phase 1: Unit Testing
Each agent tested in isolation against sandbox data
Scope
Request Intake Agent, Approval Routing Agent, and PO Creation and Notification Agent — each tested independently
Environment
Sandbox only. No production Xero account, no live Slack workspace, no real Jotform submissions
Credential rule
Use sandbox API keys and test OAuth tokens exclusively. No production credentials may be loaded during Phase 1
Pass condition
All cases T01 through T12 return the expected output with zero manual intervention required
Who runs it
FullSpec team only
2Phase 2: Integration and Edge Case Testing
Agent handoffs and exception paths verified across all tools
Scope
End-to-end agent handoff chain plus all identified edge cases: duplicate submissions, missing fields, tool unavailability, and approval timeout
Environment
Sandbox for all tool connections. Slack test workspace, Jotform sandbox form, Google Sheets test register, Xero demo company
Credential rule
Sandbox credentials only. The Xero demo company and Slack test workspace must be clearly labelled to prevent accidental production writes
Pass condition
All cases T13 through T18 and E01 through E07 resolve to the expected outcome with no data written to a production system
Who runs it
FullSpec team only
3Phase 3: End-to-End Production Test
Live environment run with process owner sign-off
Scope
Full production workflow from Jotform submission through Xero draft PO and Gmail notification, including error-log verification
Environment
Production. Live Jotform form, live Google Sheets purchase register, live Slack workspace, live Xero account (Draft PO only), live Gmail
Credential rule
Production OAuth tokens and API keys active. All test records must be voided or deleted from Xero and the purchase register immediately after the phase completes
Pass condition
All cases T19 through T22 pass, error logs are clean, and the process owner formally approves in the FullSpec confirmation record (case T22)
Who runs it
FullSpec team executes; process owner reviews and approves in T22
Test and QA PlanPage 1 of 4
FS-DOC-06Quality
02Phase 1 — unit test cases
Sandbox credentials only during Phase 1. Do not load production API keys, OAuth tokens, or real Xero account details into any agent configuration until Phase 3 has been formally opened. All Jotform, Google Sheets, Slack, and Xero connections must point to test instances for every case in this section.
Request Intake Agent — estimated build time: 6 hours, complexity: Moderate. Tests T01 to T04 cover the intake agent in isolation.
ID
Scenario
Input
Expected output
Pass criteria
T01
Happy path: complete submission
Jotform webhook payload with all required fields: requester name, department, supplier, amount ($450), business justification
Row written to Google Sheets purchase register with sequential request ID (e.g. PR-0001), timestamp, and status 'Pending'. Confirmation email sent to requester via Gmail.
Row present in Sheets within 10 seconds of webhook receipt. Request ID is unique and sequential. Requester email delivered within 60 seconds. No error logged.
T02
Missing mandatory field: amount absent
Jotform webhook payload with requester name, department, and supplier but no amount field
No row written to Google Sheets. Gmail prompt sent to requester listing the missing field and a resubmission link.
Google Sheets register unchanged. Resubmit prompt email delivered within 60 seconds. Error event logged with field name 'amount' flagged as absent.
T03
Missing mandatory field: supplier absent
Jotform webhook payload with amount and requester details but supplier field empty
No row written to Google Sheets. Gmail prompt sent to requester identifying supplier as the missing field.
Google Sheets register unchanged. Correct field name referenced in the prompt email. Error event logged.
T04
Duplicate submission: same requester submits identical form within 5 minutes
Two identical Jotform webhook payloads with matching requester, amount, supplier, and timestamp within a 5-minute window
Only the first submission creates a row. The second triggers a duplicate-detection response to the requester noting the original request ID.
Exactly one row in Google Sheets. Duplicate notification email references the original request ID. No second ID created.
Approval Routing Agent — estimated build time: 10 hours, complexity: Complex. Tests T05 to T09 cover the routing agent in isolation using pre-seeded Google Sheets rows.
ID
Scenario
Input
Expected output
Pass criteria
T05
Happy path: amount within single-tier threshold ($0 to $999)
Google Sheets row with status 'Pending' and amount $450. Rules table maps this tier to approver A.
Structured Slack message sent to approver A with request details, inline Approve and Reject buttons, and a 48-hour response deadline timestamp.
Slack message delivered to correct approver within 30 seconds of row detection. Button payload includes request ID. No escalation triggered at this point.
T06
Happy path: amount in second-tier threshold ($1,000 to $4,999)
Google Sheets row with status 'Pending' and amount $2,200. Rules table maps this tier to approver B.
Structured Slack message sent to approver B. Message body reflects the higher spend tier label.
Slack message delivered to approver B (not approver A). Tier label correct in message body. Request ID present.
T07
Approver responds Approve within 48 hours
Approver A clicks Approve button in the Slack message for request PR-0001
Google Sheets row updated with status 'Approved', approver name, and UTC timestamp. Routing agent marks the case closed.
Google Sheets row reflects 'Approved' within 15 seconds of button click. Approver name matches the Slack user. Timestamp accurate to within 5 seconds of click event.
T08
Approver responds Reject within 48 hours
Approver A clicks Reject button and enters reason 'Over budget for this quarter'
Google Sheets row updated with status 'Rejected', approver name, timestamp, and rejection reason text.
Google Sheets row reflects 'Rejected' with the literal reason text within 15 seconds. No Xero action triggered.
T09
No response within 48 hours: escalation triggered
Google Sheets row with status 'Pending' and no Slack response recorded after simulated 48-hour timer
Gmail escalation email sent to the original approver and their line manager. Email references the request ID and original submission date.
Escalation email delivered to both recipients. Both addresses match the rules table entries for the relevant tier. Request status in Sheets remains 'Pending' until a decision is recorded.
PO Creation and Notification Agent — estimated build time: 6 hours, complexity: Moderate. Tests T10 to T12 cover the PO agent in isolation using pre-seeded approval decisions.
ID
Scenario
Input
Expected output
Pass criteria
T10
Happy path: approved request creates draft PO
Google Sheets row with status 'Approved', supplier 'Acme Supplies', amount $450, department 'Operations', and line item description from the original form
Draft purchase order created in Xero demo company with correct supplier, amount, line item description, and status 'Draft'. Gmail approval notification sent to requester including the Xero PO number.
Xero draft PO present within 30 seconds of trigger. PO number in Gmail notification matches Xero record. Requester email delivered. No PO status other than 'Draft'.
T11
Rejected request: no PO created, rejection email sent
Google Sheets row with status 'Rejected' and rejection reason 'Over budget for this quarter'
No Xero record created. Gmail rejection notification sent to requester with the recorded reason text.
Zero new records in Xero demo company. Gmail notification delivered. Reason text matches the decision recorded in Google Sheets exactly.
T12
Xero API error during PO creation
Approved Google Sheets row, but Xero sandbox returns a 503 Service Unavailable response on the first attempt
Agent retries up to three times with 30-second intervals. If all retries fail, an error alert is sent to the FullSpec monitoring channel in Slack and the Google Sheets row is flagged 'PO Creation Failed'.
Retry logic executes three times. After third failure, Sheets status is 'PO Creation Failed'. Monitoring alert delivered. No duplicate PO created on a subsequent successful retry unless the status is manually reset.
Test and QA PlanPage 2 of 4
FS-DOC-06Quality
03Phase 2 — integration and edge case tests
Phase 2 integration tests confirm that the three agents hand off correctly to one another across the full sandbox environment. Cases T13 to T18 follow the T sequence from Phase 1.
ID
Scenario
Input
Expected output
Pass criteria
T13
Full happy-path handoff: intake to routing
Complete Jotform submission in sandbox triggers intake agent, which writes the Sheets row, which triggers the routing agent
Routing agent receives the correct Sheets row, identifies the approver from the rules table, and delivers the Slack message without manual intervention.
Sheets row present and status 'Pending' before Slack message is sent. Slack message delivered. No orphaned rows or duplicate triggers. Total elapsed time under 60 seconds.
T14
Full happy-path handoff: routing to PO agent on approval
Approver clicks Approve in Slack on the sandbox message for a row created by T13
Routing agent writes 'Approved' to Sheets. PO agent detects the status change, creates Xero draft PO, and sends Gmail notification.
Sheets status updated before PO agent fires. Xero draft PO and Gmail notification both present within 60 seconds of button click. No duplicate PO.
T15
Full rejection handoff: routing to PO agent on reject
Approver clicks Reject in Slack with reason text
Routing agent writes 'Rejected' to Sheets. PO agent sends Gmail rejection notification. No Xero record created.
Sheets status 'Rejected' with reason. Gmail sent. Zero Xero records. Elapsed time under 60 seconds.
T16
Escalation handoff: 48-hour timer fires, then approver responds
Simulated 48-hour timer expires, escalation email sent by routing agent. Approver then clicks Approve on the original Slack message.
Escalation email delivered to both recipients. After approval, Sheets updated to 'Approved' and PO agent creates draft PO normally despite the prior escalation.
Escalation email timestamps correct. Post-escalation approval flow completes without duplication. Sheets contains one decision row, not two.
T17
Sheets write latency: routing agent polling delay
Intake agent writes Sheets row but Sheets API responds slowly (simulated 8-second delay before row is readable)
Routing agent retries the Sheets read up to five times at 5-second intervals before concluding the row is present and proceeding.
No false 'row not found' errors in logs. Routing agent proceeds correctly once the row is readable. Total additional delay logged and within acceptable bounds (under 60 seconds).
T18
Gmail delivery failure on requester notification
PO agent attempts to send Gmail notification but Gmail API returns a 429 rate-limit error
Agent retries twice after 60-second backoff intervals. If still failing, the failure is logged to the monitoring channel and the Sheets row is annotated 'Notification Pending'.
Retry logic documented in run log. Sheets annotation present on persistent failure. Monitoring channel alert delivered. PO in Xero unaffected.
Edge case tests cover inputs and conditions outside the happy path. IDs use the E01 series and are separate from the T sequence.
ID
Scenario
Input
Expected output
Pass criteria
E01
Duplicate submission from same requester for same supplier and amount within 60 minutes
Two complete Jotform payloads, identical fields, 45-minute gap between submissions
First submission processed normally. Second submission detected as a likely duplicate; requester receives a notification referencing the existing request ID and asking them to confirm if a second request is intended.
Only one active Sheets row. Requester notified of the duplicate flag. A manual override path is documented so a legitimate second request can be approved by the FullSpec admin.
E02
Amount field contains non-numeric characters
Jotform payload where amount field contains '$1.5k' rather than '1500'
Intake agent validation rejects the submission. Requester receives a prompt to resubmit with the amount as a plain number.
No Sheets row created. Prompt email delivered. Error event logged with field value captured for debugging.
E03
Amount exactly at a tier boundary ($1,000 exactly)
Jotform payload with amount set to $1,000 (boundary between tier 1 and tier 2)
Rules table boundary logic routes the request to the tier-2 approver (boundary amount is treated as the higher tier).
Slack message delivered to tier-2 approver. Tier label in message confirms 'Tier 2'. No routing to tier-1 approver.
E04
Approver not found in rules table for submitted department
Jotform payload from a department not listed in the rules table (e.g. 'Facilities')
Routing agent cannot identify an approver. An alert is sent to the FullSpec monitoring channel and to the finance manager email address. Sheets row status set to 'Routing Error'.
No Slack message sent to an incorrect party. Finance manager alerted within 60 seconds. Sheets row annotated with 'Routing Error'. Intake agent does not loop.
E05
Slack unavailable when routing agent attempts to deliver approval message
Routing agent fires but Slack API returns 503 for the message delivery attempt
Agent retries three times at 30-second intervals. On persistent failure, Gmail fallback message sent to the approver's registered email address with the same approval details.
Gmail fallback delivered. Slack retry count logged (3 attempts). Sheets row remains 'Pending' until a decision is recorded via either channel.
E06
Approver does not respond within 48 hours and line manager also does not respond within a further 24 hours
No Slack response after 48-hour timer. Escalation email sent per T09. No response from line manager within 24 hours of escalation.
A second escalation alert is sent to the FullSpec monitoring channel and to the finance manager flagging the request as unresolved. Sheets row annotated 'Escalation Unresolved'.
Two escalation events logged in the run history. Finance manager alert delivered. Sheets annotation present. No automated approval or rejection applied.
E07
Jotform webhook delivery fails (webhook not received by automation platform)
Jotform form is submitted but the webhook fires and returns a non-2xx response from the automation platform endpoint
Jotform retries the webhook up to three times per its native retry policy. If all retries fail, the submission is flagged in the Jotform submission log with a delivery error status.
Jotform submission log shows failed delivery status. FullSpec monitoring is configured to alert on the absence of expected webhook activity if no submission is received within a configured inactivity window.
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. test-approval@[YourCompany.com]) as the requester for all cases in this phase. Do not use a real supplier name that could trigger an actual procurement action. The Xero draft PO created during T19 must be voided in Xero immediately after the test is confirmed as passed. The test row must be deleted from the live purchase register in Google Sheets once the process owner has reviewed and signed off. FullSpec will confirm this cleanup has been completed and record it in the Phase 3 run log.
ID
Scenario
Input
Expected output
Pass criteria
T19
Full production run: approved request traced end to end
Live Jotform form submitted by the FullSpec team using the internal test address, department set to a real department from the rules table, amount $450 (tier 1), supplier marked 'TEST SUPPLIER - DO NOT ACTION'
Intake agent logs the row to the live purchase register with a real sequential ID. Routing agent sends the Slack approval message to the correct live approver (FullSpec team member acting as approver). Approver clicks Approve. PO agent creates a draft PO in the live Xero account and sends the Gmail confirmation to the test email address.
Each step completes within its target time window (intake under 15 seconds, Slack message under 30 seconds, PO creation under 30 seconds of approval, Gmail under 60 seconds of PO creation). All data fields in the Xero draft PO match the form submission exactly. Gmail confirmation contains the correct PO number. Full audit trail present in Google Sheets.
T20
Full production run: rejected request traced end to end
Live Jotform form submitted using the internal test address, amount $450, approver clicks Reject with reason 'Test rejection reason'
Sheets row updated to 'Rejected' with reason text. No Xero record created. Gmail rejection notification delivered to test email with reason text.
Sheets status 'Rejected' with exact reason text. Zero new Xero records. Gmail delivered within 60 seconds of rejection click.
T21
Error log verification: confirm clean run with no unexpected errors
Review the automation platform run log immediately after T19 and T20 complete
Run log shows two completed executions with all steps green. No error events, no retry events, and no skipped steps logged for either run.
Zero error or warning entries in the run log for T19 and T20 executions. Any informational log entries are reviewed and confirmed as expected. FullSpec team signs off the log as clean.
T22
Process owner review and approval
Process owner reviews the live purchase register row from T19, the Xero draft PO (before voiding), the Gmail confirmation received at the test address, and the run log reviewed in T21
Process owner confirms that the workflow output matches the agreed specification: correct approver notified, decision recorded accurately, draft PO fields correct, requester notification clear. Process owner approval is recorded in the FullSpec confirmation system, closing the QA programme.
Process owner confirms acceptance in the FullSpec confirmation record. No separate signoff document is required. FullSpec records the confirmation reference, date, and reviewer name. The test Xero PO is then voided and the test Sheets row deleted. QA programme is closed.
Once T22 is confirmed, the FullSpec team will void the test Xero draft PO, remove the test row from the live Google Sheets purchase register, and issue the QA completion confirmation to [YourCompany.com]. Contact the FullSpec team at support@gofullspec.com for any queries relating to test execution or results.
Test and QA PlanPage 4 of 4