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

Social Media Scheduling Automation

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

This document defines the complete quality assurance process for the Social Media Scheduling automation. It is written for the FullSpec development team and covers every test case required before the pipeline is approved for production use. Testing runs in three sequential phases: unit, integration and edge case, and end-to-end production. No phase begins until every test case in the previous phase has passed. The process owner joins testing at Phase 3 only, to perform a final review and record sign-off in the FullSpec confirmation system.

01Testing approach

All testing follows three phases in sequence. No phase begins until the previous phase fully passes. Phase 1 isolates each agent in a sandbox environment. Phase 2 tests handoffs between agents and covers edge cases that could arise in real operation. Phase 3 runs a live end-to-end trace through the production environment with real credentials, supervised by both the FullSpec team and the process owner.

Phase 1: Unit Testing

Each agent tested in isolation against sandbox credentials

Scope

Individual agent logic: Content Intake Agent, Approval Routing Agent, and Publishing and Reporting Agent tested independently.

Environment

Sandbox only. No production credentials, no live Buffer queue, no real Slack channels.

Credential rule

Use sandbox API keys for Airtable, Buffer, and Slack. Google Drive test folder must be isolated from any live content library.

Pass condition

All test cases T01 through T14 return the expected output with no unhandled errors.

Who runs it

FullSpec team only. Process owner is not involved in Phase 1.

Phase 2: Integration and Edge Case Testing

Agent handoffs and failure scenarios validated end to end in sandbox

Scope

Cross-agent handoffs across the full pipeline plus edge cases: duplicate records, missing assets, tool unavailability, and approval timeout.

Environment

Sandbox environment for all tool connections. Simulated Slack interactive responses used for approval button testing.

Credential rule

Sandbox credentials only. Do not use Buffer production queue or post to any live Slack workspace channel.

Pass condition

All integration cases T15 through T21 pass, and all edge cases E01 through E05 produce the correct fallback or error-handling behaviour.

Who runs it

FullSpec team only. Process owner is not involved in Phase 2.

Phase 3: End-to-End Production Test

Full live run traced through production with process owner review

Scope

Complete pipeline run using production credentials: real Airtable base, real Slack workspace, live Buffer account. One full content item traced from Airtable trigger to Buffer confirmation.

Environment

Production. All tool connections use live credentials agreed during discovery.

Credential rule

Production API keys active. Test record must be clearly labelled as a test item and voided in Airtable and Buffer after the run completes.

Pass condition

All cases T22 through T25 pass, including process owner approval recorded in the FullSpec confirmation system.

Who runs it

FullSpec team executes T22 through T24. Process owner completes T25 (review and approval sign-off).

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 Airtable bases, live Buffer queues, or active Slack workspaces at this stage. All Google Drive references must point to the designated test folder, not any folder accessible to the social media team.

Content Intake Agent — reads Airtable status changes and retrieves assets from Google Drive.

Scenario

Input

Expected output

Pass criteria

T01

Happy path: valid record triggers intake

Airtable record status set to 'Ready for Review'; caption field populated; Google Drive asset URL present and accessible.

Agent retrieves caption text and asset URL; assembles a complete content package object with channel targets and scheduled time.

Package object contains: caption (string), image_url (valid URL), channels (array, min 1 item), scheduled_at (ISO 8601 timestamp). No errors logged.

T02

Status change to a non-trigger value is ignored

Airtable record status set to 'In Progress'.

Agent does not fire. No package assembled. No downstream action triggered.

Execution log shows trigger evaluated and skipped. Zero downstream calls made.

T03

Caption field is empty

Airtable record status set to 'Ready for Review'; caption field blank; asset URL present.

Agent halts. Airtable record updated to 'Error: Missing Caption'. Coordinator notified via Slack DM.

Record status in Airtable reads 'Error: Missing Caption'. Slack DM sent to configured coordinator user ID. No package passed downstream.

T04

Google Drive asset URL is broken or returns 403

Airtable record status 'Ready for Review'; caption populated; asset URL points to a non-existent or permission-denied file.

Agent halts. Airtable record updated to 'Error: Asset Unreachable'. Coordinator notified via Slack DM.

Record status reads 'Error: Asset Unreachable'. Error detail (HTTP status code) logged to Airtable notes field. No package passed downstream.

T05

Channel targets field is empty

Airtable record 'Ready for Review'; caption and asset URL valid; channels field blank.

Agent halts. Airtable record flagged 'Error: No Channels Selected'. Coordinator notified.

Record status updated correctly. No content package assembled. Slack DM confirms missing field.

Approval Routing Agent — sends Slack approval messages and routes responses back to Airtable.

Scenario

Input

Expected output

Pass criteria

T06

Happy path: approval message sent to Slack

Valid content package delivered by Content Intake Agent.

Structured Slack message posted to the configured approvals channel. Message includes caption text, image preview URL, target channels, scheduled time, and interactive Approve and Reject buttons.

Slack API call returns 200. Message appears in the sandbox approvals channel with both buttons rendered. Airtable record status updated to 'Pending Approval'.

T07

Reviewer clicks Approve

Slack interactive callback payload with action value 'approve' received.

Airtable record status updated to 'Approved'. Content package forwarded to Publishing and Reporting Agent. Slack message updated to show 'Approved by [reviewer name]'.

Airtable record reads 'Approved'. Publishing agent receives the full package. Slack message thread shows confirmation reply.

T08

Reviewer clicks Reject with feedback comment

Slack interactive callback payload with action value 'reject' and a text comment.

Airtable record status set to 'In Revision'. Feedback comment written to Airtable notes field. Slack DM sent to coordinator summarising the rejection and feedback.

Record status reads 'In Revision'. Notes field contains the reviewer's comment verbatim. Coordinator DM received. No content passed to publishing agent.

T09

Slack app token is invalid or expired

Content package valid; Slack API call attempted with an expired bot token.

Agent catches the 401 error. Airtable record flagged 'Error: Slack Auth Failed'. Alert sent to the FullSpec monitoring webhook.

No message posted to Slack. Record status updated. Monitoring webhook receives error payload within 30 seconds.

T10

Approval channel does not exist or bot not a member

Slack API post attempted to a channel ID that does not exist in the sandbox workspace.

Agent catches channel_not_found error. Airtable record flagged 'Error: Slack Channel Not Found'. Alert logged.

Record status updated. Error detail includes the attempted channel ID. No downstream action triggered.

Publishing and Reporting Agent — submits approved content to Buffer, updates Airtable, and posts the weekly summary to Slack.

Scenario

Input

Expected output

Pass criteria

T11

Happy path: post scheduled in Buffer

Approved content package with valid caption, asset URL, channel list, and scheduled timestamp.

Buffer API call succeeds. Post appears in the sandbox Buffer queue at the correct time for each target channel. Airtable record updated to 'Scheduled' with Buffer post URL logged.

Buffer API returns 201 for each channel. Airtable record reads 'Scheduled'. Buffer URL field populated. No errors in execution log.

T12

Buffer API rate limit hit (429 response)

Buffer API returns 429 Too Many Requests during a multi-channel scheduling call.

Agent pauses and retries after the retry-after interval specified in the response header (default: 60 seconds). Up to 3 retries attempted before escalating.

Execution log shows retry attempts with timestamps. If all retries fail, Airtable record set to 'Error: Buffer Rate Limited' and coordinator notified. If retry succeeds, normal flow resumes.

T13

Airtable record update fails after Buffer schedules successfully

Buffer API returns 201 (success); subsequent Airtable PATCH call returns 422.

Agent logs the discrepancy. Airtable record remains in previous state. FullSpec monitoring webhook receives an alert containing the Buffer post URL and the Airtable record ID for manual reconciliation.

Monitoring webhook receives alert within 60 seconds. Alert payload includes Buffer post URL and Airtable record ID. Coordinator Slack DM sent with reconciliation instructions.

T14

Weekly summary Slack message sent correctly

All approved posts for the week have been scheduled in Buffer and Airtable records updated.

Agent compiles a summary message listing each scheduled post with channel, caption excerpt, and scheduled time. Message posted to the configured marketing Slack channel.

Slack API returns 200. Message is present in the sandbox marketing channel. Summary includes at minimum: channel name, scheduled time (formatted), and caption excerpt (first 80 characters) for each post.

Test and QA PlanPage 2 of 4

FS-DOC-06Quality

03Phase 2 — integration and edge case tests

Phase 2 tests cover the handoffs between agents and verify that data is passed correctly across the full pipeline. IDs continue from Phase 1. A separate edge case table follows, using the E01 sequence, covering failure scenarios that do not fit a single agent but arise from real operating conditions.

Scenario

Input

Expected output

Pass criteria

T15

Content Intake Agent to Approval Routing Agent: full handoff

Airtable record moves to 'Ready for Review' with all required fields populated.

Content package assembled by Intake Agent is received by Approval Routing Agent without data loss. Slack approval message contains all fields from the Airtable record.

Slack message fields (caption, image URL, channels, scheduled time) match the source Airtable record exactly. No field truncation or encoding errors.

T16

Approval Routing Agent to Publishing Agent: approve path handoff

Reviewer clicks Approve in Slack.

Publishing Agent receives the same content package that was delivered to the Approval Agent. No field mutation between agents.

Buffer scheduling call uses the exact caption, image URL, channel list, and timestamp from the original Airtable record. Diff between intake package and publishing input is zero.

T17

Reject and resubmit cycle

Reviewer rejects a post with feedback. Coordinator updates the Airtable record and resets status to 'Ready for Review'.

The pipeline re-triggers from the beginning. The updated caption or asset is retrieved from Google Drive. A fresh Slack approval request is sent.

New Slack approval message reflects the updated content. Previous rejection feedback remains in the Airtable notes field and is not overwritten. Cycle completes without duplicate records.

T18

Multi-channel scheduling: three or more channels from one Airtable record

Airtable record specifies three target channels (e.g. Instagram, Facebook, LinkedIn). Single caption and asset URL provided.

Publishing Agent makes a separate Buffer API call per channel, all using the same caption and image. All three Buffer posts created with the correct channel identifiers.

Three Buffer posts visible in sandbox queue, each assigned to the correct channel profile ID. Airtable record shows all three Buffer URLs logged.

T19

Airtable webhook fires twice for the same record (duplicate trigger)

Status field updated to 'Ready for Review' triggers two webhook events within a 5-second window (common in Airtable webhook behaviour).

Deduplication logic detects the second event matches an already-in-flight record ID. Second trigger is suppressed. Only one Slack approval message sent.

Exactly one Slack message appears in the approvals channel for the record. Execution log shows the second event was detected and discarded. No duplicate Buffer posts created.

T20

Handoff latency: Approval Agent response time under load

Ten Airtable records moved to 'Ready for Review' simultaneously.

All ten records processed in sequence without queue overflow. Each generates a Slack approval message within 2 minutes of the trigger.

All ten Slack messages received within the 2-minute window. No records stuck in an intermediate state. Execution log shows queue processing order.

T21

Publishing Agent Airtable write confirms Buffer post URL is valid

Buffer API returns a post URL for a scheduled item.

Agent writes the URL to the Airtable record. The URL is accessible and resolves to the correct Buffer post in the sandbox account.

Airtable record's Buffer URL field contains a non-empty string beginning with 'https://buffer.com'. HTTP GET to the URL returns 200 or 301 (redirect to post).

Edge case tests cover failure and boundary conditions that span agent boundaries or depend on external tool behaviour.

Scenario

Input

Expected output

Pass criteria

E01

Duplicate Airtable record with identical caption and asset URL

Two separate Airtable records with identical caption and image URL are both moved to 'Ready for Review' within the same minute.

Both records are treated as independent items. Each receives its own Slack approval message and its own Buffer scheduling call. No merging or suppression occurs.

Two distinct Slack messages in the approvals channel, each referencing a different Airtable record ID. Two Buffer posts created. Deduplication logic does not suppress legitimate distinct records.

E02

Google Drive asset deleted between trigger and retrieval

Airtable record triggers; in the time between trigger and asset retrieval, the Google Drive file is deleted.

Content Intake Agent catches a 404 from the Drive API. Record set to 'Error: Asset Not Found'. Coordinator notified via Slack DM with the deleted file name.

No package assembled. Airtable error status set within 30 seconds of the failed retrieval. Slack DM includes the file name extracted from the original asset URL.

E03

Buffer API is unavailable (503 or timeout)

Publishing Agent attempts to schedule a post; Buffer returns 503 or the connection times out after 10 seconds.

Agent retries up to 3 times with exponential backoff (15s, 30s, 60s). If all retries fail, Airtable record set to 'Error: Buffer Unavailable'. Coordinator and FullSpec monitoring webhook alerted.

Three retry attempts logged with timestamps. On final failure, Airtable record status updated. Monitoring webhook receives payload with record ID, channel list, and attempted post time for manual retry.

E04

Slack approval message receives no response within the configured timeout window (default: 48 hours)

Approval Routing Agent sends a Slack message. No button interaction is received within 48 hours.

Agent sends a reminder DM to the configured reviewer after 24 hours. After 48 hours with no response, Airtable record set to 'Pending: Approval Timeout'. Coordinator notified. Post not scheduled.

Reminder DM sent at the 24-hour mark (verified by execution log timestamp). Record status updated to 'Pending: Approval Timeout' at the 48-hour mark. No Buffer API call made.

E05

Airtable field schema mismatch (field renamed or removed by workspace admin)

A required Airtable field (e.g. 'Scheduled Publish Time') has been renamed by a workspace admin after the automation was configured.

Content Intake Agent cannot resolve the field. Execution halts with a schema error. Alert sent to the FullSpec monitoring webhook with the missing field name and record ID.

Monitoring webhook receives alert within 60 seconds. Error message includes the expected field name. No downstream agents triggered. Coordinator receives a Slack DM advising of the configuration issue.

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 content record clearly labelled 'TEST DO NOT PUBLISH' in both the caption and the Airtable record name. Set the Buffer scheduled time to at least 48 hours in the future so the post can be deleted from the queue before it publishes. After the test run is confirmed as passed, void the test record in Airtable (set status to 'Cancelled: Test') and delete the corresponding Buffer post immediately. Do not use a channel that is publicly visible to customers during testing.

Phase 3 runs against live production credentials. Confirm with the process owner that the Airtable base, Slack workspace, and Buffer account in use are the same accounts that will run in production after go-live. Any discrepancy in credentials at this stage will invalidate the test.

Scenario

Input

Expected output

Pass criteria

T22

Full production pipeline: trigger to Buffer schedule

A real Airtable content record labelled 'TEST DO NOT PUBLISH' is set to 'Ready for Review' in the production base. Caption and asset URL are valid. One channel selected. Scheduled time is 48 hours ahead.

Content Intake Agent fires within 60 seconds. Slack approval message appears in the live approvals channel with all fields correct. On approval, Buffer receives the scheduling call and the post appears in the live Buffer queue. Airtable record updates to 'Scheduled' with the Buffer post URL.

End-to-end latency from trigger to Buffer confirmation is under 3 minutes. All three agents execute without error. Airtable record shows 'Scheduled' status and a valid Buffer URL. Execution log is clean.

T23

Error log verification: confirm monitoring webhook is active in production

Deliberately trigger a controlled error in production: set a test record to 'Ready for Review' with the asset URL field blank.

Content Intake Agent catches the missing asset. Airtable record flagged 'Error: Asset Unreachable'. FullSpec monitoring webhook receives the alert payload.

Monitoring webhook receives the alert within 60 seconds. Alert payload contains: record ID, error type ('missing_asset'), timestamp, and coordinator Slack user ID. No post reaches Slack or Buffer.

T24

Rejection path in production: feedback logged and status reset

Use the T22 test record (reset to 'Ready for Review'). Reviewer clicks Reject in the live Slack channel and enters a feedback comment.

Airtable record status changes to 'In Revision'. Reviewer's comment appears in the Airtable notes field verbatim. Coordinator receives a Slack DM summarising the rejection.

Record status updated within 30 seconds of the Slack button interaction. Notes field contains the exact comment entered. Coordinator DM received. Buffer queue unaffected (no scheduling call made).

T25

Process owner review and approval sign-off

The process owner reviews the Phase 3 test run results: execution logs for T22, T23, and T24; Airtable record states; Buffer queue screenshot; Slack message screenshots; and the monitoring webhook alert from T23.

The process owner confirms all Phase 3 cases passed, that the pipeline behaves as specified, and that they accept the automation for production use. Sign-off is recorded in the FullSpec confirmation system.

FullSpec confirmation record is updated with the process owner's name, the date of review, and a pass/accept status. This record constitutes the official go-live approval. No separate signature block is required.

After T25 is recorded in the FullSpec confirmation system, the FullSpec team will void the test record in Airtable and delete the test post from the Buffer queue. The pipeline is then considered approved and ready for the go-live date of 12 February. For any questions about this test plan, contact the FullSpec team at support@gofullspec.com.

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