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

Strategic Planning Workflow

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

This document defines the full quality assurance programme for the Strategic Planning Workflow automation, covering the Planning Data Agent and the Progress Tracking Agent. It is written for the FullSpec engineering team and is structured as three sequential test phases: unit testing in sandbox, integration and edge-case testing in sandbox, and end-to-end validation in the production environment. No phase begins until all cases in the previous phase achieve a passing result. The process owner joins Phase 3 to confirm the owner-facing approval flow before the workflow goes live.

01Testing approach

Testing runs in three phases in strict sequence. No phase begins until every test case in the previous phase carries a passing status. Phase 1 validates each agent in isolation using sandbox credentials only. Phase 2 confirms that agents hand off correctly to one another and that the workflow handles abnormal inputs gracefully. Phase 3 runs the complete cycle in the live production environment and records the process owner's review and approval of the output.

Phase 1: Unit Testing

Estimated duration: 1 to 2 business days

Scope

Individual agent logic: Planning Data Agent and Progress Tracking Agent tested separately, covering trigger handling, data reads, Notion writes, Slack sends, and HubSpot and Google Sheets queries.

Environment

Sandbox only. All API connections point to test workspaces and sandbox accounts.

Credential rule

No production credentials may be used. Sandbox tokens for Notion, Slack, Google Sheets, and HubSpot must be loaded into a separate credential store labelled QA-SANDBOX before Phase 1 begins.

Pass condition

All cases T01 through T14 return expected outputs with no unhandled errors. Any failure blocks progression to Phase 2.

Who runs it

FullSpec team only. No process owner involvement required.

Phase 2: Integration and Edge Case Testing

Estimated duration: 1 to 2 business days

Scope

Agent-to-agent handoffs, system boundary behaviour, and all defined edge cases including missing data, duplicate submissions, unavailable tools, and human timeout scenarios.

Environment

Sandbox only. Integration tests fire against sandbox endpoints; no live Slack channels or production Notion databases are written to.

Credential rule

Continue using QA-SANDBOX credential set. Do not rotate or replace credentials mid-phase without re-running affected prior cases.

Pass condition

All cases T15 through T22 pass, and all edge cases E01 through E07 produce the specified fallback or error-handling behaviour. No case may be marked waived without written sign-off from the FullSpec lead engineer.

Who runs it

FullSpec team only. No process owner involvement required.

Phase 3: End-to-End Production Test

Estimated duration: 1 business day plus owner review window

Scope

Full planning cycle run from date trigger through to Slack distribution and weekly progress report, executed in the live production environment against real API endpoints.

Environment

Production. Live credentials active. Test records must be voided after each run per the instructions in Section 04.

Credential rule

Production credential set loaded and scoped to the minimum required permissions. Sandbox credential set must be disabled before Phase 3 begins to prevent environment bleed.

Pass condition

All cases T23 through T27 pass, including the process owner review and approval case (T27). Owner confirmation is recorded in the FullSpec delivery confirmation document.

Who runs it

FullSpec team executes T23 through T26. The process owner participates in T27 to confirm the review and approval flow is working as expected.

Test and QA PlanPage 1 of 4

FS-DOC-06Quality

02Phase 1 — unit test cases

Sandbox credentials only for all Phase 1 cases. Do not connect to production Notion databases, live Slack channels, or real HubSpot or Google Sheets accounts during this phase. Use the QA-SANDBOX credential set exclusively. Any test that incidentally writes to a production resource is a blocking failure and must be investigated before continuing.

Planning Data Agent — unit test cases (T01 to T09)

Scenario

Input

Expected Output

Pass Criteria

T01

Happy path: date trigger fires correctly

Scheduled date trigger fires at configured cycle start datetime in sandbox scheduler

Workflow execution begins; Planning Data Agent initialised with correct quarter label and cycle ID

Execution log shows trigger received; cycle ID generated; no errors in initialisation step

T02

Notion template duplication: single department

One sandbox department record passed to agent; Notion sandbox workspace active

A new Notion page created from the standard goal submission template, named with department name and quarter label

Page exists in sandbox Notion database with correct title format; template fields present and blank; no extra pages created

T03

Notion template duplication: multiple departments

Eight sandbox department records passed simultaneously

Eight unique Notion pages created, each named correctly, with no duplicates

Eight pages present in sandbox database; each has a distinct department name; creation timestamps within a 60-second window

T04

Slack kickoff message sent to department head

Department head sandbox Slack user ID and linked Notion submission page URL

Direct Slack message delivered to sandbox user containing the submission page link and deadline date

Slack sandbox API confirms message delivered (HTTP 200); message body contains correct Notion URL and deadline; no extra messages sent

T05

Google Sheets financial data pull

Sandbox Google Sheets file with three populated rows: revenue, pipeline, expenses

Agent reads all three rows and writes values to the correct fields in the master sandbox Notion page

Notion master page fields match the sandbox Sheets values exactly; no values are truncated or reformatted; write confirmed via Notion API response

T06

HubSpot pipeline data pull

Sandbox HubSpot account with two open deals totalling $120,000 pipeline value

Agent retrieves deal total and writes the correct pipeline figure to the master Notion page

Notion master page pipeline field reads $120,000; HubSpot API call logged with correct deal stage filter; no additional fields overwritten

T07

Submission reminder: incomplete pages only

Three Notion submission pages in sandbox: two marked complete, one still blank

Slack reminder sent only to the department head linked to the incomplete page; no message sent to the two completed departments

Exactly one Slack message dispatched in sandbox; recipient matches the incomplete department head user ID; message text references the correct page link

T08

Consolidation: all submissions complete

Three completed sandbox Notion submission pages with goal data populated

Agent merges all three submissions into the master Notion page under the correct departmental sections

Master Notion page contains three department sections with correct goal data; no fields blank; consolidation timestamp recorded

T09

Failure mode: Google Sheets API returns 403 Forbidden

Sandbox Sheets token deliberately revoked before agent fires

Agent logs the API error, does not proceed to write to Notion, and raises an alert to the error notification channel

Execution log contains 403 error entry; Notion master page financial fields remain unchanged; error Slack message delivered to the configured ops channel

Progress Tracking Agent — unit test cases (T10 to T14)

Scenario

Input

Expected Output

Pass Criteria

T10

Happy path: Monday trigger fires and update requests sent

Monday 08:00 sandbox scheduled trigger; three sandbox department head Slack user IDs with linked Notion goal pages

Structured Slack update request delivered to each of the three sandbox users with a link to their Notion goal page

Three Slack messages confirmed delivered in sandbox; each contains the correct Notion page URL; trigger timestamp is Monday 08:00 or within a 5-minute tolerance

T11

Notion goal status read: all departments responded

Three sandbox Notion goal pages updated with completion percentages (80%, 60%, 100%)

Agent reads all three pages and assembles a summary object containing department name and completion percentage for each

Internal summary object contains three entries with correct department names and percentages matching sandbox Notion values

T12

Weekly progress report posted to leadership Slack channel

Summary object from T11 passed to report formatter; sandbox leadership Slack channel ID configured

Formatted progress report posted to sandbox leadership channel listing each department and goal completion percentage

Single message posted to sandbox channel; message contains three department rows with correct percentages; no duplicate messages; post timestamp recorded

T13

Trigger does not fire outside active cycle

Monday trigger fires but no active planning cycle flag is set in the orchestration layer

Agent checks cycle-active status, finds it false, logs a skip event, and sends no Slack messages

Zero Slack messages dispatched; execution log contains skip-cycle entry with reason; no Notion pages read

T14

Failure mode: Slack API rate limit exceeded on report post

Sandbox Slack API stubbed to return HTTP 429 on the channel post call

Agent catches the 429 response, waits the retry-after interval (60 seconds in sandbox), retries once, and logs the outcome

Execution log shows initial 429, retry attempt after delay, and final result; if retry also fails, error is written to ops log; no silent failure

Test and QA PlanPage 2 of 4

FS-DOC-06Quality

03Phase 2 — integration and edge case tests

Integration tests confirm that the Planning Data Agent and Progress Tracking Agent hand off state correctly, that trigger sequencing is preserved, and that the owner approval notification reaches the correct recipient before distribution fires. All cases continue the T sequence from Phase 1.

Scenario

Input

Expected Output

Pass Criteria

T15

Full Planning Data Agent sequence: trigger to consolidation

Date trigger fires in sandbox; four sandbox department records; all Notion pages completed within the test window

All four Notion submission pages created, kickoff Slack messages sent, financial data pulled from Sheets and HubSpot, and master Notion page fully consolidated in sequence

Each step completes in order with no skipped nodes; master Notion page contains financial data and all four department sections; total execution time logged

T16

Handoff: Planning Data Agent triggers owner approval notification

All sandbox submissions complete; master Notion page consolidation step finishes successfully

Owner approval Slack notification dispatched to the configured owner Slack user ID with a direct link to the master Notion page

Exactly one notification delivered to owner sandbox user; message contains correct Notion master page URL; notification fires only after consolidation is confirmed complete

T17

Handoff: owner approval flag triggers Slack distribution

Owner sets the approval property on the sandbox Notion master page to Approved

Automation detects the property change and sends the plan distribution Slack message to all sandbox leadership channel members

Distribution message posted to sandbox leadership channel within 2 minutes of approval flag being set; message contains correct Notion page link; no distribution fires without the approval flag

T18

Handoff: Progress Tracking Agent reads up-to-date Notion data after Planning Data Agent write

Planning Data Agent has written financial data to master Notion page; Progress Tracking Agent Monday trigger fires in the same sandbox environment

Progress Tracking Agent reads the correct financial and goal fields written by the Planning Data Agent without conflict or stale cache

Progress report contains the values written by the Planning Data Agent in the same test cycle; no field collisions or overwrites; Notion API version timestamps confirm correct read order

T19

End-of-cycle: Progress Tracking Agent stops firing after cycle closes

Cycle-active flag set to false in orchestration layer after sandbox quarter end date

Monday trigger fires but agent checks the flag, logs a cycle-ended skip, and sends no Slack messages

Zero Slack messages dispatched; execution log records cycle-ended status; no Notion reads performed

T20

Multi-agent execution does not produce duplicate Slack messages

Both agents active simultaneously in sandbox; Monday trigger and a late-submission reminder fire within the same minute

Each agent sends only its own designated messages; no department head receives both a progress update request and a submission reminder in the same send window

Slack sandbox message log shows correct message counts per recipient; no duplicate or cross-agent messages delivered to any single user

T21

Correct Notion page linked in all Slack messages across both agents

All Notion sandbox page IDs registered in the orchestration layer before agents run

Every Slack message that includes a Notion link resolves to the correct page for the recipient's department or role

Manual check of all Slack message payloads in sandbox confirms each URL is the correct Notion page for the intended recipient; no cross-linked pages

T22

Retry behaviour on transient Notion API timeout during consolidation

Sandbox Notion API stubbed to return HTTP 504 on the first consolidation write, then HTTP 200 on retry

Agent retries the write after a configurable backoff delay, succeeds on second attempt, and logs the retry event

Execution log shows initial 504, backoff delay entry, successful retry, and final consolidation confirmation; master Notion page written correctly

Edge case tests — E01 to E07

Scenario

Input

Expected Output

Pass Criteria

E01

Duplicate Notion submission page created for the same department

Duplication step called twice for the same department record within a single cycle (e.g. trigger fires twice due to scheduler misconfiguration)

Agent detects the existing page for that department, skips creation, logs a duplicate-detected warning, and does not overwrite the existing page

Only one Notion page per department exists after the run; warning entry present in execution log; no data loss on the original page

E02

Department head submits a blank Notion page before the deadline

Notion submission page for one department exists but all goal fields are empty; submission deadline has passed

Agent treats the page as incomplete, includes the department in the incomplete list, sends a Slack reminder, and flags the department on the master page as awaiting input

Blank page not merged into master plan; department flagged as incomplete on master Notion page; Slack reminder sent to that department head only

E03

HubSpot returns zero deals in the current pipeline

HubSpot sandbox account has no open deals for the active quarter

Agent writes $0 pipeline value to the master Notion page and logs an informational note that no active deals were found, rather than raising an error

Master Notion page pipeline field reads $0; execution log contains informational entry; no error raised; workflow continues to next step

E04

Google Sheets financial tab is missing expected column headers

Sandbox Sheets file has the correct sheet name but the revenue, pipeline, and expenses column headers have been renamed

Agent fails to map the columns, logs a schema mismatch error with the expected and found header names, and does not write incomplete data to Notion

Notion master page financial fields remain unchanged; error log entry includes expected header names and the names actually found; ops channel receives alert

E05

Slack delivery fails for one department head (user deactivated)

One sandbox Slack user ID is deactivated before kickoff messages are sent

Agent receives a Slack API error for that user, logs the failed delivery with the user ID, continues sending to all other department heads, and raises an alert for the failed recipient

All active department heads receive their Slack messages; execution log records the failed user ID and Slack error code; alert posted to ops channel; workflow does not halt

E06

Owner does not approve the consolidated plan within 48 hours

Owner approval Slack notification sent; no approval flag set on the Notion master page within the 48-hour timeout window

Automation sends a second reminder to the owner after 48 hours and logs a timeout warning; distribution step does not fire until the approval flag is set

Second reminder delivered to owner sandbox user at the 48-hour mark; distribution Slack message is not sent; timeout warning in execution log; plan remains in pending-approval state

E07

Monday trigger fires but one department head's Notion goal page has been deleted

Progress Tracking Agent fires; one of the expected Notion goal page IDs returns HTTP 404 from the Notion API

Agent logs the missing page error for that department, assembles the progress report using the remaining departments, and flags the missing department in the report with a note that data was unavailable

Progress report posted to sandbox leadership channel contains all departments except the deleted one; missing department row marked as data unavailable; error logged with page ID; no silent omission

Test and QA PlanPage 3 of 4

FS-DOC-06Quality

04Phase 3 — end-to-end production test

Important before running Phase 3: Use a dedicated internal test email address and a test Slack user account for all owner-facing notifications. Do not send kickoff or reminder messages to real department heads during this run. Create all Notion test pages under a clearly labelled QA folder so they can be identified and voided immediately after the test completes. The test Notion master page, all department submission pages, and any Slack messages posted during Phase 3 must be deleted or archived before the first real planning cycle is initiated. Confirm with the process owner that they understand they are approving a test record, not a live plan, before T27 begins.

Credential check before Phase 3: disable the QA-SANDBOX credential set in the orchestration layer and confirm production credentials are active for Notion, Slack, Google Sheets, and HubSpot. Verify that HubSpot and Google Sheets field mappings confirmed during discovery are present and correct before firing the trigger.

Scenario

Input

Expected Output

Pass Criteria

T23

Full production cycle: trigger to Notion page creation and Slack kickoff

Date trigger fires manually in the production orchestration layer using the configured cycle start datetime; two internal test department records registered

Two Notion submission pages created in the production Notion workspace under the QA test folder; kickoff Slack messages delivered to the internal test Slack accounts with correct page links and deadline

Both Notion pages present in production workspace with correct naming format; Slack messages confirmed delivered to test accounts; HubSpot and Google Sheets data written to Notion master page fields correctly

T24

Production financial data pull and master Notion page population

Production Google Sheets file and HubSpot account accessible; at least one open deal in HubSpot and at least one populated financial row in Sheets

Agent reads live financial and pipeline values and writes them to the correct fields on the production Notion master test page

Notion master page fields match the live values in Google Sheets and HubSpot at the time of the run; field mapping confirmed correct against the confirmed discovery schema; no extra fields overwritten

T25

Production submission consolidation and owner approval notification

Internal test team manually completes the two sandbox department submission pages in the production Notion QA folder

Agent consolidates both submissions into the master Notion test page and sends the owner approval Slack notification to the real owner Slack account

Master Notion test page contains both department sections with correct goal data; owner receives a single Slack notification with the correct Notion page link; no distribution fires before approval

T26

Production distribution and progress tracking Monday send

Owner sets the approval flag on the production Notion test master page; Monday trigger fired manually to simulate the first progress check-in

Distribution Slack message posted to the production leadership channel with correct Notion link; Monday progress update requests sent to internal test Slack accounts

Leadership channel receives the distribution message with the correct Notion URL; test Slack accounts receive structured update requests; execution log confirms both steps completed in sequence with no errors

T27

Process owner review and approval confirmation (owner sign-off case)

Process owner logs into the production Notion workspace, opens the QA master test page, reviews the consolidated content, and sets the approval property to Approved

Owner confirms verbally or via written note to the FullSpec team that the consolidated plan is presented correctly, that the approval notification was clear, and that the distribution message they received on the leadership channel is accurate

Owner approval recorded in the FullSpec delivery confirmation document. FullSpec team documents the owner's name, the datetime of approval, and any observations or corrective actions required before the first live cycle. This case constitutes the process owner's formal sign-off on the automated workflow. No separate signature block is used.

Post-Phase 3 cleanup: immediately after T27 is complete, archive or delete all QA Notion pages, remove the test department records from the orchestration layer, and confirm with the process owner that the production environment is clean and ready for the first live planning cycle. Contact support@gofullspec.com if any test case in Phase 3 requires a corrective rebuild before go-live.

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