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

Pricing Approval Workflow

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

This document defines the complete test and quality assurance plan for the Pricing Approval Workflow automation. It is written for the FullSpec engineering team and covers every test case across three sequential phases: unit testing of individual agents, integration and edge case testing across agent handoffs, and a final end-to-end production run. No phase begins until the previous phase fully passes. The process owner joins testing in Phase 3 only and records approval at the close of that phase.

01Testing approach

Testing is structured across three phases that run in strict sequence. Phase 1 validates each agent in isolation against sandbox credentials. Phase 2 tests agent-to-agent handoffs and edge conditions that cannot be exercised at the unit level. Phase 3 runs a small set of cases against production credentials with real deal records, ending with the process owner confirming the workflow is fit for go-live. A phase must fully pass before the next phase opens. Any blocking failure resets the affected phase; downstream phases do not begin until the corrected phase is re-run and passes cleanly.

Phase 1: Unit Testing

Each agent tested in isolation against sandbox credentials

Scope

Individual agent logic: trigger detection, field extraction, validation, routing decision, write-back. No cross-agent handoffs tested here.

Environment

Sandbox only. HubSpot Developer sandbox account; Slack test workspace; Gmail test account; Google Sheets test sheet. No production data or credentials.

Credential rule

Sandbox API keys and OAuth tokens only. Production credentials must not be loaded into the automation platform during Phase 1.

Pass condition

All cases T01 through T15 return the expected output with zero blocking errors. Warnings must be documented and triaged before advancing.

Who runs it

FullSpec team. Process owner not required for this phase.

Phase 2: Integration and Edge Case Testing

Agent handoffs and exception paths tested end-to-end in sandbox

Scope

Full agent-to-agent handoffs (Intake to Routing, Routing to CRM Update), escalation path, reminder cadence, and all defined edge cases including duplicates, missing fields, tool unavailability, and approver timeout.

Environment

Sandbox. Same sandboxed tool accounts as Phase 1. Outbound emails and Slack messages must be sent only to internal test addresses.

Credential rule

Sandbox credentials only. Production credentials remain off-limits until Phase 3 is formally opened after Phase 2 sign-off.

Pass condition

All integration cases T16 through T22 pass, and all edge cases E01 through E08 are resolved to either a pass or an accepted-with-documented-behaviour outcome. No unhandled exceptions.

Who runs it

FullSpec team. Process owner not required for this phase.

Phase 3: End-to-End Production Test

Live credentials, real deal records voided after test

Scope

Full workflow traced on production credentials: HubSpot live org, production Slack workspace, Gmail production account, live Google Sheets approval log, and live HubSpot deal properties.

Environment

Production. Test deal records must use a clearly labelled test deal name (prefix: [TEST]). All test records are voided and archived immediately after the phase closes.

Credential rule

Production OAuth tokens and API keys active. Confirm all Slack interactive component scopes and HubSpot private app scopes are correct before opening Phase 3.

Pass condition

All cases T23 through T27 pass, including the final process owner review case (T27). Process owner approval recorded in FullSpec confirmation. No separate signoff block required.

Who runs it

FullSpec team runs T23 through T26. Process owner joins for T27, the final review-and-approval case.

Test and QA PlanPage 1 of 4

FS-DOC-06Quality

02Phase 1 — unit test cases

Sandbox credentials only for all Phase 1 tests. Do not connect production HubSpot, Slack, Gmail, or Google Sheets accounts at this stage. Use the designated sandbox API keys stored in the FullSpec secrets vault under the project slug sales-pricing-approval-workflow. If a test requires a Slack interactive button click, use the internal Slack test workspace bot account to simulate the click.

Request Intake Agent: covers trigger detection in HubSpot, field extraction, validation, and write to the Google Sheets approval log.

Scenario

Input

Expected output

Pass criteria

T01

Happy path: valid request submitted

HubSpot deal with all required fields populated: deal name, rep email, requested discount %, deal value, tier flag set to standard.

Structured row written to Google Sheets log within 10 seconds. All fields mapped correctly. No validation error.

Google Sheets row contains deal ID, rep email, discount %, deal value, timestamp, and status = PENDING.

T02

Missing discount field

HubSpot deal submitted with discount % field blank.

Agent raises a validation error. No row written to Sheets. Rep notified via Slack with field name missing.

Error log entry present. Google Sheets row absent. Slack message to rep references missing field by label.

T03

Missing deal value

HubSpot deal submitted with deal value field blank or zero.

Validation error. No Sheets row. Rep Slack notification lists deal value as missing.

Same as T02 but error cites deal value field.

T04

Deal below minimum discount threshold

HubSpot deal with discount % at 0.5%, below the minimum exception threshold.

Agent rejects the request as not qualifying for the exception workflow. Rep notified. No Sheets row.

Rejection Slack message sent. Sheets row absent. Error log entry marked BELOW_THRESHOLD.

T05

Duplicate deal ID submitted twice

Same HubSpot deal ID submitted a second time before the first request is resolved.

Agent detects existing PENDING row for the deal ID in Sheets and suppresses the duplicate. Rep notified of duplicate.

Only one row exists in Sheets for the deal ID. Duplicate Slack notification sent to rep. Error log entry marked DUPLICATE.

T06

HubSpot webhook delivery delay

HubSpot webhook delayed by simulated 30-second network lag.

Agent processes the event correctly on receipt. Timestamp in Sheets reflects event receipt time, not submission time.

Sheets row present and complete. Timestamp delta recorded in log. No duplicate row triggered.

T07

Google Sheets write failure

Simulate Sheets API returning a 500 error on write attempt.

Agent retries up to three times with exponential back-off. After three failures, writes to error log and sends alert to FullSpec monitoring channel.

Retry count = 3 in error log. Sheets row absent (expected). Monitoring Slack alert received within 60 seconds of final retry.

Approval Routing Agent: covers discount tier decision, Slack interactive message dispatch, Gmail finance escalation, and reminder cadence.

Scenario

Input

Expected output

Pass criteria

T08

Happy path: standard tier, Slack approval

Sheets row with discount % below finance escalation threshold. Tier = standard.

Slack message sent to sales manager sandbox account within 15 seconds. Message contains deal name, discount %, margin impact, and approve/deny buttons.

Slack message delivered. Buttons functional in sandbox. Sheets row status remains PENDING.

T09

Happy path: finance tier, Gmail escalation

Sheets row with discount % above finance escalation threshold. Tier = finance.

Gmail sent to finance test address. Email contains deal name, discount %, full deal context, and approve/deny link. Slack message sent to manager noting escalation.

Gmail received at test address within 30 seconds. Slack manager notification delivered. Sheets row status = ESCALATED.

T10

Approver clicks Approve in Slack

Slack interactive button click: Approve, with optional comment field populated.

Decision written to Sheets: status = APPROVED, approver name, timestamp, comment. Routing agent hands off to CRM Update Agent trigger.

Sheets row updated within 10 seconds of button click. All decision fields present. Handoff event fired.

T11

Approver clicks Deny in Slack

Slack interactive button click: Deny, with comment field populated.

Sheets row updated: status = DENIED, approver name, timestamp, comment. CRM Update Agent triggered with DENIED status.

Sheets row correct. Handoff event fired with DENIED payload. No approval notification sent to rep at this stage.

T12

First reminder fires after no response

Sheets row in PENDING status. Simulate approver taking no action for the configured reminder interval (default: 4 hours in sandbox shortened to 2 minutes for test).

Reminder Slack message sent to approver. Sheets row updated with reminder_count = 1. Status remains PENDING.

Reminder delivered. reminder_count field in Sheets = 1. Timestamp of reminder logged.

T13

Second reminder and escalation after extended no response

Sheets row in PENDING, reminder_count = 1. Simulate further inaction past the second reminder window.

Second reminder sent. If escalation_on_second_reminder = true, manager's manager (or fallback address) notified via Slack. reminder_count = 2.

Second reminder delivered. Escalation Slack message sent to fallback address. reminder_count = 2 in Sheets.

T14

Slack API unavailable during message send

Simulate Slack API returning 503 at point of approval message dispatch.

Agent retries three times. On continued failure, falls back to sending approval request via Gmail to the approver's email. Error logged.

Gmail fallback message received at approver test address. Error log entry present. Sheets row status = PENDING (not errored).

T15

Invalid approver Slack ID in configuration

Sheets row with tier that maps to a Slack user ID that does not exist in the sandbox workspace.

Agent catches the Slack user not found error, logs it, and sends a routing failure alert to the FullSpec monitoring channel. No approval message delivered.

Error log entry present citing invalid Slack user ID. Monitoring alert received. Sheets row status = ROUTING_ERROR.

CRM Update Agent: covers HubSpot deal property write-back and rep Slack notification for both approved and denied outcomes.

Scenario

Input

Expected output

Pass criteria

T16

Happy path: approved decision written to HubSpot

Handoff payload from Routing Agent: status = APPROVED, approved_price, approver_name, decision_date.

HubSpot deal properties updated: pricing_exception_status = Approved, approved_price, approver_name, decision_date. Rep Slack notification sent with outcome and approved price.

All four HubSpot properties present and correct on sandbox deal record. Rep Slack message delivered within 15 seconds.

T17

Happy path: denied decision written to HubSpot

Handoff payload: status = DENIED, approver_name, decision_date, denial_reason.

HubSpot deal properties updated: pricing_exception_status = Denied, approver_name, decision_date, denial_reason. Rep Slack notification sent citing denial and reason.

HubSpot properties correct. Rep Slack message includes denial reason text.

T18

HubSpot API write failure on update

Simulate HubSpot API returning 429 (rate limit) on property write attempt.

Agent retries with back-off. On success within retry window, write completes normally. On continued failure, error logged and monitoring alert sent.

If retry succeeds: HubSpot updated, no alert. If all retries fail: error log entry present, monitoring alert received, Sheets row flagged WRITE_FAILED.

Test and QA PlanPage 2 of 4

FS-DOC-06Quality

03Phase 2 — integration and edge case tests

Phase 2 tests the complete agent-to-agent handoff chain and all defined exception paths. IDs continue from Phase 1. Integration tests use the same sandbox environment. Run integration tests first, then edge case tests.

Scenario

Input

Expected output

Pass criteria

T19

Full standard-tier handoff: Intake to Routing to CRM Update (approved)

Valid HubSpot deal trigger with standard-tier discount. Full chain runs: Intake writes Sheets row, Routing sends Slack message, approver clicks Approve, CRM Update writes HubSpot and notifies rep.

End state: HubSpot deal = Approved, Google Sheets row = APPROVED, rep Slack notification received. Total elapsed time logged.

All three agents fire in sequence with no manual intervention. HubSpot, Sheets, and Slack all reflect correct final state.

T20

Full finance-tier handoff: Intake to Routing (Gmail escalation) to CRM Update (approved)

Valid HubSpot deal with finance-tier discount. Routing sends Gmail to finance approver. Finance approver clicks approve link in email.

Gmail received, approve link clicked, decision recorded in Sheets, HubSpot updated to Approved, rep notified in Slack.

Finance approver email received. Link click registers in Sheets within 10 seconds. HubSpot and rep Slack correct.

T21

Full chain ending in denial: rep notified with denial reason

Valid deal trigger, standard tier. Approver clicks Deny with comment.

HubSpot updated to Denied with reason. Rep Slack message includes denial reason. Sheets row = DENIED.

All three agents complete. Denial reason present in all three destinations: HubSpot, Sheets, Slack.

T22

Reminder chain through to resolution: two reminders then late approval

Valid deal, standard tier. Approver takes no action through two reminder cycles, then approves on the third prompt.

Two reminder Slack messages logged. Approval recorded after third prompt. All downstream steps (HubSpot update, rep notification) complete correctly.

reminder_count = 2 in Sheets before final decision. Final state correct. No duplicate approval notifications.

T23

Concurrent requests: two deals submitted simultaneously

Two separate HubSpot deal webhooks fired within one second of each other. Both valid, different reps, different tiers.

Both requests processed independently. Two separate Sheets rows. Two separate Slack approval messages to respective approvers.

No cross-contamination of deal data. Both Sheets rows distinct. Both HubSpot records updated correctly after decisions.

Edge case tests are listed separately below. These cover conditions that fall outside the happy path and that must be handled gracefully without data loss or unhandled exceptions.

Scenario

Input

Expected output

Pass criteria

E01

Duplicate submission: same deal submitted twice within 60 seconds

HubSpot webhook fires for deal ID already in PENDING state in Sheets.

Intake Agent detects existing row, suppresses second write, sends Slack message to rep: 'A request for this deal is already pending.'

Single Sheets row for deal ID. Duplicate suppression log entry. Rep notified. No second approval message sent to approver.

E02

Missing rep email on HubSpot deal record

Deal submitted with rep email property blank.

Intake Agent validation fails. No Sheets row written. Error log entry. Monitoring alert sent (no Slack message possible as no rep email).

Error log entry present citing missing rep_email. Monitoring alert received. Sheets row absent.

E03

Discount tier configuration value missing from automation platform

Routing Agent reads Sheets row but the finance escalation threshold variable is not set in the platform configuration.

Agent logs a configuration error. Routing halted. Monitoring alert sent. Sheets row status = CONFIG_ERROR. No approval message dispatched.

Configuration error present in log. Monitoring alert received. No approval message sent to any approver.

E04

Google Sheets API unavailable at Intake write step

Sheets API returns 503 during Intake Agent write attempt.

Three retries with exponential back-off. On continued failure: error log entry, monitoring alert, workflow halted for this request. HubSpot deal property set to INTAKE_FAILED.

Retry count = 3. Error logged. Monitoring alert received. HubSpot deal property reflects INTAKE_FAILED.

E05

HubSpot API unavailable at CRM Update step

CRM Update Agent receives decision payload but HubSpot returns 503.

Three retries. On failure: error log, monitoring alert, Sheets row flagged WRITE_FAILED. Rep Slack notification withheld until write succeeds.

Retry count = 3. Error logged. Monitoring alert received. Rep not notified until successful HubSpot write confirmed.

E06

Approver takes no action through all reminder cycles: request expires

Reminder count reaches the configured maximum (default: 3) with no approver response.

Sheets row status updated to EXPIRED. Manager's manager or admin notified via Slack. Rep notified that request has expired and must be resubmitted.

EXPIRED status in Sheets. Admin escalation Slack message sent. Rep expiry notification sent. No further reminders fired.

E07

Approver submits Slack response after request has already expired

Approver clicks Approve in Slack after Sheets row status = EXPIRED.

Routing Agent detects expired status. Response discarded. Approver notified via Slack that the request has expired and the rep must resubmit.

No Sheets update from late response. Approver Slack notification sent. HubSpot not updated. Error log entry marked LATE_RESPONSE.

E08

Invalid or malformed approve/deny link clicked in Gmail escalation

Finance approver clicks an approve link with a corrupted or expired token in the URL.

Link handler returns a clear error page or message. No Sheets write. Error log entry. Routing Agent sends a fresh approval email to the finance approver.

No state change in Sheets from corrupted click. Error log entry present. Fresh escalation Gmail delivered to finance approver within 60 seconds.

Test and QA PlanPage 3 of 4

FS-DOC-06Quality

04Phase 3 — end-to-end production test

Important before running Phase 3: all test deal records in HubSpot must use a clearly labelled name prefixed with [TEST] so they cannot be confused with live deals. All Slack approval messages and Gmail escalations must be sent only to the internal test addresses agreed with the process owner before this phase opens. Do not use a real prospect's deal record under any circumstances. Immediately after Phase 3 closes, void all test deal records in HubSpot (set deal stage to Closed Lost, add a note: 'TEST RECORD - QA Phase 3'), archive the corresponding Google Sheets rows, and remove the [TEST] entries from the live approval log view.

Before opening Phase 3, confirm that all production OAuth tokens are active and scoped correctly: HubSpot Private App token with crm.objects.deals.read and crm.objects.deals.write; Slack Bot token with chat:write, users:read, and interactive components enabled on the production workspace app; Gmail OAuth with send scope on the finance escalation account; Google Sheets OAuth with spreadsheets scope on the live approval log file.

Scenario

Input

Expected output

Pass criteria

T24

Production standard-tier approval: full chain traced

Live HubSpot org: test deal [TEST-QA-001] submitted with standard-tier discount (below finance threshold). All production credentials active.

Intake Agent writes to live Google Sheets log within 10 seconds. Routing Agent sends Slack approval message to sales manager internal test account. Manager clicks Approve. CRM Update Agent writes approved_price, approver_name, decision_date to HubSpot deal. Rep test Slack account receives outcome notification.

All four production tool states correct: HubSpot deal = Approved with correct properties; Sheets row = APPROVED with timestamp and approver; Slack approval message delivered; rep Slack notification delivered. Elapsed time from submission to rep notification logged.

T25

Production finance-tier escalation: Gmail path

Live HubSpot org: test deal [TEST-QA-002] with discount above finance escalation threshold.

Intake writes to live Sheets. Routing Agent sends Gmail to internal finance test address and Slack note to manager. Finance test account clicks approve link. CRM Update writes to HubSpot. Rep notified.

Gmail received at production finance test address. Approve link functional. HubSpot deal updated correctly. Sheets row = APPROVED. Rep Slack notification delivered.

T26

Production denial with reason: end-to-end trace

Live HubSpot org: test deal [TEST-QA-003] standard tier. Manager clicks Deny with denial reason text.

HubSpot deal = Denied with denial_reason property set. Sheets row = DENIED with reason. Rep Slack notification includes denial reason.

All three production tool states reflect denial. Denial reason text consistent across HubSpot, Sheets, and Slack notification. No approval notification sent.

T27

Process owner end-to-end review and approval

Process owner joins the session. FullSpec team presents the results of T24 through T26 live: shows HubSpot deal records, live Google Sheets approval log rows, Slack message history, and Gmail thread. Process owner verifies that the workflow behaviour matches the agreed specification including approval routing, escalation thresholds, field values in HubSpot, and audit log completeness.

Process owner confirms the automation is operating correctly across all tested scenarios. Any outstanding items are logged as post-launch tasks in the FullSpec project record. Process owner approval is recorded by the FullSpec team in the project confirmation log at support@gofullspec.com.

Process owner verbal or written confirmation received and logged by FullSpec. All test deal records [TEST-QA-001] through [TEST-QA-003] voided in HubSpot and archived in Sheets immediately after sign-off. Phase 3 marked closed in FullSpec project record. Workflow cleared for go-live.

After Phase 3 closes, the FullSpec team will send a QA completion confirmation to the process owner and the nominated contacts (Renata Solano, Tom Briggs, Claire Houten) at the email addresses held in the project record. If any case in T24 through T27 fails, Phase 3 is paused, the issue is resolved in sandbox, and the affected production cases are re-run in full before the phase is marked complete. Contact the FullSpec team at support@gofullspec.com with any questions during testing.

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