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

Content Calendar Management

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

This document defines the complete testing and quality assurance protocol for the Content Calendar Management automation, covering all three agents: Calendar Orchestrator, Review and Publish, and Performance Sync. Testing runs in three sequential phases. No phase begins until every test case in the preceding phase reaches a passing state. The FullSpec team runs Phases 1 and 2 in full; your process owner joins in Phase 3 to validate production behaviour and record sign-off. All test IDs are sequential across phases to allow unambiguous traceability in defect reports.

01Testing approach

Testing is structured as three phases that run in strict sequence. No phase begins until the previous phase fully passes. Each phase has a defined environment, credential rule, and pass condition. Phase 1 isolates individual agent logic. Phase 2 verifies that agents hand off to one another and that the system handles edge cases safely. Phase 3 confirms end-to-end behaviour in the production environment with real credentials and real content records.

Phase 1: Unit Testing

Individual agent logic verified in isolation

Scope

Each agent tested independently: trigger detection, data parsing, output formatting, and individual tool calls for Notion, Slack, Buffer, and HubSpot.

Environment

Sandbox only. All tool connections point to sandbox or test instances. No production databases, Slack workspaces, or Buffer channels are used.

Credential rule

Sandbox API keys only. Production credentials must not be present in any environment variable, config file, or secret store during Phase 1.

Pass condition

All test cases T01 through T18 return the expected output with no error state. Any failure blocks progression to Phase 2.

Who runs it

FullSpec team only. No action required from the process owner during this phase.

Phase 2: Integration and Edge Case Testing

Agent handoffs and failure-mode resilience verified

Scope

Cross-agent data handoffs, sequential trigger chains, and all identified edge cases including duplicate records, missing fields, tool unavailability, and human timeout scenarios.

Environment

Sandbox environment throughout. Integration tests use sandbox versions of Notion, Slack, Buffer, and HubSpot with controlled test data sets.

Credential rule

Sandbox API keys only. Credentials are scoped to test workspaces and databases; no writes are permitted to production stores.

Pass condition

All integration test cases T19 through T27 and all edge case tests E01 through E08 pass. Error handling must produce the correct fallback behaviour, not a silent failure.

Who runs it

FullSpec team only. No action required from the process owner during this phase.

Phase 3: End-to-End Production Testing

Full lifecycle run on production credentials with process owner present

Scope

Complete content lifecycle from Notion row creation through brief dispatch, draft submission, approval, Buffer scheduling, HubSpot logging, and performance sync.

Environment

Production environment. Real Notion database, real Slack workspace, real Buffer account, and real HubSpot instance. Test records must be voided after each run.

Credential rule

Production API credentials active. Use a dedicated internal test content row (e.g. topic: QA Test, channel: Internal). Delete or archive the test record immediately after each case closes.

Pass condition

All production test cases T28 through T32 pass, including error-log verification. The final case (T32) is process owner review and approval recorded in the FullSpec confirmation log.

Who runs it

FullSpec team leads execution. The process owner (Marketing Manager) must be present and available to complete human steps in T31 and T32.

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 Notion databases, Slack workspaces, Buffer accounts, or HubSpot instances. All test rows must be created in the designated sandbox environment. The FullSpec team will confirm sandbox connectivity before any test case is executed.

Calendar Orchestrator Agent — tests T01 through T07

Scenario

Input

Expected Output

Pass Criteria

T01

New Notion row triggers agent

A new content row is created in the sandbox Notion database with all required fields populated: topic, assignee, deadline, channel, format.

Agent detects the new row within 60 seconds and initiates brief generation.

Trigger fires; no duplicate executions; execution log shows single run.

T02

Brief generated with correct field values

Sandbox Notion row with topic: 'Product Launch Post', assignee: 'Writer A', deadline: 3 days, channel: LinkedIn, format: Short-form.

Slack message sent to Writer A sandbox channel containing topic, format, channel, and deadline in the correct brief template.

All five field values appear in the Slack message body; no placeholder tokens remain unfilled.

T03

Brief routed to correct Slack user

Notion row with assignee field set to sandbox user 'Writer B' (different Slack ID from Writer A).

Slack message delivered to Writer B channel only; Writer A receives nothing.

Slack delivery receipt shows correct recipient ID; no cross-delivery.

T04

Overdue reminder fires when deadline passes with no draft link

Sandbox Notion row where deadline is set to past date minus 1 day and draft link field is empty.

Slack reminder sent to the assigned writer and copied to the marketing manager sandbox channel.

Two Slack messages delivered: one to writer, one to manager; both contain the correct content title and deadline.

T05

Overdue reminder suppressed when draft link is present

Sandbox Notion row where deadline is past but draft link field contains a valid Google Docs URL.

No Slack reminder sent.

Zero Slack messages dispatched; execution log records 'draft present, reminder suppressed'.

T06

Notion API returns 401 Unauthorized

Sandbox Notion credential intentionally revoked before trigger fires.

Agent logs an error entry; no partial brief sent; Slack error alert fired to FullSpec monitoring channel.

Error log contains event timestamp, agent name, and error code 401; no Slack brief delivered.

T07

Assignee field is empty in Notion row

New sandbox Notion row where the assignee field is blank.

Agent does not send a brief; error entry logged; Slack alert sent to marketing manager sandbox channel indicating missing assignee.

No writer Slack message sent; manager alert delivered; error log entry present.

Review and Publish Agent — tests T08 through T14

Scenario

Input

Expected Output

Pass Criteria

T08

Draft link logged in Notion triggers reviewer notification

Sandbox Notion row status changes to 'Draft Submitted' and a Google Docs URL is added to the draft link field.

Slack message sent to the assigned reviewer sandbox channel containing the content title and a direct link to the Google Doc.

Slack message delivered within 60 seconds; link in message matches the URL stored in Notion.

T09

Reviewer notification routed to correct person

Sandbox Notion row with reviewer field set to 'Reviewer B' (different from default).

Slack notification delivered to Reviewer B sandbox channel only.

Slack delivery receipt confirms correct recipient; no message sent to Reviewer A.

T10

Approved status triggers Buffer scheduling

Sandbox Notion row status updated to 'Approved'; scheduled time and channel fields populated.

Buffer sandbox post created with correct copy stub, channel, and scheduled datetime.

Buffer API response confirms post created; post ID logged in Notion record; scheduled time matches Notion field value.

T11

Notion status updated to Scheduled after Buffer post created

Same sandbox row as T10 after Buffer post creation.

Notion record status field updated from 'Approved' to 'Scheduled'.

Notion API write confirmed; status field value reads 'Scheduled'; timestamp of update logged.

T12

HubSpot campaign record created on approval

Sandbox Notion row linked to a HubSpot campaign ID; status updated to 'Approved'.

HubSpot sandbox campaign record updated with publish date, channel name, and content title.

HubSpot API response 200; campaign record fields match Notion values; no duplicate record created.

T13

Needs Revision status routes rejection back to writer

Sandbox Notion row status changed to 'Needs Revision' by the reviewer.

Slack message sent to the assigned writer sandbox channel with status 'Revision required' and content title.

Slack message delivered; Buffer post not created; Notion status remains 'Needs Revision'.

T14

Buffer API returns 429 Too Many Requests

Sandbox Buffer credential rate limit intentionally triggered.

Agent pauses, retries after 60 seconds up to three times, then logs a failure alert to the FullSpec monitoring channel.

Retry log shows three attempts with timestamps; failure alert present; no silent discard of the post.

Performance Sync Agent — tests T15 through T18

Scenario

Input

Expected Output

Pass Criteria

T15

Weekly schedule trigger fires on Monday

Sandbox scheduler set to Monday 08:00 in the configured timezone.

Agent execution begins within 5 minutes of scheduled time; Buffer metrics pull initiated.

Execution log timestamp falls within the 08:00 to 08:05 window; no duplicate run within the same day.

T16

Buffer engagement metrics written back to Notion records

Sandbox Buffer account contains two published posts with known impression and click values; matching Notion records exist by post ID.

Notion records updated with correct impression count, click count, and sync timestamp for each matched post.

Both Notion records show updated metric fields; values match sandbox Buffer API response exactly.

T17

Notion record not updated when no Buffer post ID match found

Sandbox Notion row with a post ID that does not exist in the sandbox Buffer account.

No metric fields updated on that row; a 'no match' note logged against the record; no error thrown.

Notion row metric fields unchanged; execution log contains 'no Buffer match for post ID [X]' entry.

T18

Buffer API unavailable during scheduled sync

Sandbox Buffer endpoint returns 503 during the scheduled Monday run.

Agent logs the failure with timestamp; Slack alert sent to marketing manager sandbox channel; sync rescheduled for next available run.

Error log entry present; Slack alert delivered; no partial metric writes; next scheduled run proceeds normally.

Test and QA PlanPage 2 of 4

FS-DOC-06Quality

03Phase 2 — integration and edge case tests

Phase 2 validates that agents pass data to one another correctly across the full workflow chain, and that the system responds predictably to abnormal inputs and tool failures. All tests continue in the sandbox environment.

Integration test cases — T19 through T27

Scenario

Input

Expected Output

Pass Criteria

T19

Calendar Orchestrator brief triggers downstream draft submission flow

New sandbox Notion row; Calendar Orchestrator brief sent; writer adds draft link to same row within 30 minutes.

Review and Publish Agent detects the draft link addition and sends reviewer notification without any manual re-trigger.

Reviewer Slack notification arrives within 60 seconds of draft link being logged; no FullSpec team intervention needed.

T20

Overdue reminder and subsequent draft submission both fire correctly in sequence

Sandbox Notion row past deadline with no draft link; overdue reminder fires; writer then adds draft link.

Overdue reminder delivered first; then on draft link addition, reviewer notification sent with no duplication of the overdue reminder.

Exactly one overdue reminder and exactly one reviewer notification in the Slack sandbox workspace; no repeated messages.

T21

Full approval chain: draft submitted, approved, Buffer post created, Notion status updated, HubSpot logged

Sandbox Notion row moves through: Draft Submitted, Approved. Scheduled time and channel fields populated.

Buffer post created, Notion status set to 'Scheduled', HubSpot record updated, all within a single automated run.

All three downstream writes confirmed via API responses; field values consistent across Notion, Buffer, and HubSpot.

T22

Revision loop: rejection routes back to writer, then re-submission re-triggers reviewer notification

Sandbox Notion row status set to 'Needs Revision'; writer updates draft link field with a new URL.

Second reviewer notification sent containing updated draft link; Buffer not touched during revision loop.

Second Slack notification delivered; link in message matches the new URL; no Buffer post created during revision state.

T23

Performance Sync Agent matches post IDs correctly when multiple Notion rows are present

Sandbox Notion database contains five published rows with distinct Buffer post IDs.

All five rows updated with the correct metrics for their respective Buffer post IDs; no cross-contamination of values.

Each Notion row's impression and click fields match the corresponding sandbox Buffer post exactly.

T24

Notion status write by Review and Publish Agent does not re-trigger Calendar Orchestrator

Sandbox Notion row status updated to 'Scheduled' by Review and Publish Agent.

Calendar Orchestrator Agent does not fire a new brief or reminder as a result of the status change.

Execution log shows zero Calendar Orchestrator runs in the 5 minutes following the status write.

T25

HubSpot campaign record update does not create a duplicate when record already exists

Sandbox HubSpot campaign record already exists for the content piece; Review and Publish Agent attempts to log publish data.

Existing record is updated in place; no second record created.

HubSpot sandbox contains exactly one campaign record for the test content title after the agent run.

T26

Slack notification delivery confirmed before execution continues

Sandbox workflow step where Slack API returns a non-200 response on first attempt.

Agent retries the Slack call up to three times; on continued failure, logs error and does not proceed to Buffer scheduling.

Retry log shows three Slack attempts; execution halted at Slack step; Buffer not called; error alert in monitoring channel.

T27

End-of-week Performance Sync does not overwrite a row that was manually corrected

Sandbox Notion row has a manually entered metric value that differs from the Buffer API response.

The automated sync overwrites the field with the Buffer API value (documented expected behaviour per spec).

Notion field value matches Buffer API response after sync; behaviour noted in execution log for team awareness.

Edge case test cases — E01 through E08

Scenario

Input

Expected Output

Pass Criteria

E01

Duplicate Notion row created for same content piece

Two sandbox Notion rows with identical topic, assignee, and deadline fields created within 10 seconds.

Brief sent for both rows independently; no deduplication suppresses the second. Duplicate flagged in execution log.

Two Slack briefs delivered (one per row); execution log records both row IDs; no crash or silent discard.

E02

Notion row missing the deadline field

New sandbox Notion row with topic and assignee populated but deadline field left blank.

Agent logs a validation error; no brief sent; Slack alert sent to marketing manager sandbox channel indicating missing deadline.

No writer Slack message; manager alert delivered; error log entry contains row ID and field name 'deadline'.

E03

Notion row missing the channel field at scheduling step

Sandbox Notion row status set to 'Approved' but the channel field is blank.

Review and Publish Agent does not create a Buffer post; error logged; Slack alert sent to marketing manager.

No Buffer post created; error log entry contains row ID and field name 'channel'; manager alert delivered.

E04

Draft link in Notion is a non-Google Docs URL

Writer logs a Slack message URL instead of a Google Docs URL in the draft link field.

Reviewer notification still sent (link delivered as provided); execution log notes non-standard URL format.

Slack notification delivered; log entry flags URL format anomaly; no execution failure.

E05

Slack API completely unavailable for more than 10 minutes

Sandbox Slack endpoint returns 503 for a sustained period during brief dispatch.

Agent retries three times at 2-minute intervals; on final failure, logs error with full context; execution halted gracefully.

Error log contains three retry timestamps and final failure entry; no partial brief sent; no infinite retry loop.

E06

HubSpot API credential expires mid-workflow

Sandbox HubSpot token intentionally expired after Buffer post is created but before HubSpot write.

Agent logs the HubSpot write failure; Buffer post remains scheduled (not rolled back); Slack alert sent to FullSpec monitoring channel.

Buffer post confirmed in sandbox; HubSpot write failure logged with error code; monitoring alert delivered.

E07

Human reviewer takes no action in Notion for 72 hours after notification

Sandbox Notion row in 'Draft Submitted' state; no status change for 72 hours after reviewer Slack notification.

A follow-up Slack reminder sent to the reviewer and copied to the marketing manager after the timeout period.

Second Slack notification delivered at the 72-hour mark; execution log records the timeout event and reminder dispatch.

E08

Buffer post ID missing from Notion record during Performance Sync

Sandbox Notion row for a published piece where the Buffer post ID field was never populated.

Performance Sync Agent skips the row without error; logs 'missing Buffer post ID' against the row; no metric fields written.

Row metric fields unchanged; execution log contains skip entry with row ID; no error state thrown.

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 content row only (suggested topic: 'QA Test Run — Do Not Publish', channel: Internal). Use an internal or role-based email address as the test assignee and reviewer so no real team members receive unexpected notifications. Void or archive every test Notion record, Buffer post, and HubSpot campaign entry immediately after each test case closes. Do not leave test data in the production environment overnight. The FullSpec team will coordinate this cleanup with you before and after each Phase 3 session.

Scenario

Input

Expected Output

Pass Criteria

T28

Full brief generation on real Notion row creation

A new content row is added to the live Notion content database with all required fields: topic, assignee (internal test user), deadline (3 days from now), channel (Internal), format (Short-form).

A formatted Slack brief delivered to the internal test user in the production Slack workspace within 60 seconds of the Notion row being saved.

Slack message received by the internal test account; all five field values present; no additional unexpected messages sent to other team members.

T29

Draft submission triggers reviewer notification in production

A Google Docs URL is added to the draft link field of the production Notion test row; status updated to 'Draft Submitted'.

Reviewer notification delivered to the internal test reviewer account in Slack, containing the content title and a working Google Docs link.

Slack notification confirmed in the internal reviewer's Slack inbox; link opens the correct Google Doc; delivery within 60 seconds.

T30

Approval triggers Buffer scheduling, Notion status update, and HubSpot logging in production

Production Notion test row status changed to 'Approved'; scheduled time set to a date and time at least 7 days in the future to allow safe cancellation.

Buffer post created in the production account (scheduled, not yet published); Notion status updated to 'Scheduled'; HubSpot campaign record created or updated.

Buffer post visible in the scheduled queue with correct time and channel; Notion status field reads 'Scheduled'; HubSpot record contains publish date and channel. All three confirmed before test row is voided.

T31

Error log verification: confirm all execution logs are written correctly in production

Review execution logs generated during T28, T29, and T30 in the automation platform's production log store.

Each executed step has a corresponding log entry including: agent name, trigger event, timestamp, input data summary, API response code, and output confirmation.

FullSpec team confirms log entries are present and complete for all three prior test cases. Any missing or malformed entry is treated as a failure requiring investigation before sign-off.

T32

Process owner review and approval

The process owner (Marketing Manager) reviews the full Phase 3 test run: brief received, reviewer notified, Buffer post visible, Notion updated, HubSpot logged, error logs verified.

Process owner confirms that the automation behaved as documented, that all outputs match expectations, and that the team is ready to adopt the new workflow.

Process owner confirms acceptance in the FullSpec confirmation log. This sign-off is recorded by the FullSpec team and stored against this project. No separate signature block is required. Questions or outstanding items must be raised to support@gofullspec.com before this case is marked closed.

After T32 is closed and the process owner confirmation is recorded, the FullSpec team will void all production test records (Notion rows, Buffer posts, HubSpot entries) and confirm cleanup in writing. The automation is then considered QA-passed and ready for live operation. For any defects or questions arising during testing, contact support@gofullspec.com with the relevant test case ID and a description of the observed behaviour.

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