Back to Meeting & Decision Documentation

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

Meeting and Decision Documentation

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

This document defines the complete quality assurance process for the Meeting and Decision Documentation automation. It covers every test case the FullSpec team runs before any component reaches production, structured across three sequential phases: unit tests per agent, integration and edge case tests across agent handoffs, and a final end-to-end production run. No phase begins until the previous phase achieves a full pass. The process owner joins Phase 3 only. All earlier phases are executed entirely by the FullSpec team in isolated sandbox environments.

01Testing approach

Testing is structured in three phases that run in strict sequence. No phase begins until every test case in the previous phase has achieved a pass status. Phase 1 validates each agent in isolation against sandbox credentials. Phase 2 validates agent handoffs and resilience against abnormal inputs. Phase 3 executes a complete production run with real credentials, real meetings, and process owner sign-off as the final gate.

Phase 1: Unit Testing

Estimated duration: 2 business days

Scope

Each agent tested independently: Transcription Agent, Summary and Action Extraction Agent, Distribution Agent.

Environment

Sandbox only. No production credentials, no live Zoom recordings, no real Notion databases, no real ClickUp workspaces.

Credential rule

Sandbox API tokens and test OAuth applications only. Production keys must not be present in the test environment at any point during Phase 1.

Pass condition

All cases T01 through T12 return the expected output with no errors. Any single failure blocks progression to Phase 2.

Who runs it

FullSpec team. Process owner is not involved.

Phase 2: Integration and Edge Case Testing

Estimated duration: 2 business days

Scope

Agent-to-agent handoffs across the full automated flow, plus edge cases covering duplicate events, missing data, unavailable tools, and human review timeout scenarios.

Environment

Sandbox for integration tests. Staging Notion database and ClickUp workspace with test-only data. Gmail sandbox account. Slack test workspace.

Credential rule

Sandbox and staging credentials only. Staging tokens must be scoped to test databases and channels and must not have write access to any production resource.

Pass condition

All cases T13 through T19 and E01 through E06 return the expected output or graceful failure response. Any single failure blocks Phase 3.

Who runs it

FullSpec team. Process owner is not involved.

Phase 3: End-to-End Production Testing

Estimated duration: 1 to 2 business days

Scope

Full production flow from Zoom session close event through to Notion page creation, ClickUp task creation, Gmail follow-up, and Slack notification. Error log verification included.

Environment

Production credentials throughout. Live Zoom account with Cloud Recording enabled. Live Notion workspace, ClickUp workspace, Gmail account, Slack workspace, and Google Calendar.

Credential rule

Production OAuth tokens and API keys in use. Test records must be voided or deleted from production systems after each run. A dedicated internal test calendar event and test Slack channel are used.

Pass condition

All cases T20 through T24 pass, including process owner review and sign-off recorded in the FullSpec confirmation log (case T24).

Who runs it

FullSpec team executes T20 through T23. Process owner participates in T24 (review and approval gate).

Test and QA PlanPage 1 of 4

FS-DOC-06Quality

02Phase 1 — unit test cases

Sandbox credentials only throughout Phase 1. Use a dedicated Zoom test account with a pre-recorded sample audio file. Do not use a live Zoom OAuth token connected to any production account. Notion, ClickUp, Gmail, and Slack are not called during Phase 1 unit tests; mock the downstream inputs and outputs where the agent logic requires a handoff payload.

Transcription Agent — estimated build time: 6 hours, complexity: Moderate. Tests T01 through T04.

Scenario

Input

Expected output

Pass criteria

T01

Happy path: standard 30-minute recording

Zoom cloud recording URL, meeting ID, host email, 30-min MP4, clear audio, 3 speakers

Full text transcript with speaker labels (Speaker 1, Speaker 2, Speaker 3) and timestamps every 30 seconds. No blank segments.

Transcript length within 10% of word count expected from audio duration. All 3 speakers labelled. Zero empty blocks.

T02

Long recording: 90-minute meeting at upper length limit

Zoom cloud recording URL, 90-min MP4, 5 speakers

Complete transcript covering all 90 minutes. No truncation at any point. Speaker count consistent throughout.

Final timestamp within 60 seconds of 90:00. No mid-transcript cutoff. All 5 speakers present in output.

T03

Failure: recording unavailable or access denied

Invalid recording URL returning HTTP 403 from Zoom API

Agent raises a retrieval error, logs the meeting ID and error code, and halts without passing an empty payload downstream.

Error event logged with meeting ID, HTTP status code 403, and timestamp. No empty transcript passed to next agent. Alert triggered.

T04

Failure: audio too short (under 60 seconds, likely a test click)

Zoom recording URL for a 45-second session

Agent detects sub-threshold duration, skips transcription, logs a skip event, and does not trigger downstream agents.

Skip event logged. No transcript object created. Downstream agents not invoked. No error thrown to the orchestration layer.

Summary and Action Extraction Agent — estimated build time: 10 hours, complexity: Complex. Tests T05 through T09.

Scenario

Input

Expected output

Pass criteria

T05

Happy path: clear transcript with explicit decisions and named owners

Sample transcript containing 4 decisions and 5 action items with named owners and stated due dates

Structured summary object: meeting title, date, attendee list, decisions array (4 items), action items array (5 items each with owner name and due date).

All 4 decisions present verbatim or paraphrased accurately. All 5 action items extracted. Every item has a non-null owner field and a non-null due date field.

T06

Happy path: transcript with no explicit due dates stated

Sample transcript where owners are named but no deadlines are spoken

Action items extracted with owner populated and due date set to a default placeholder value (e.g. 'TBC') rather than null or blank.

Owner field populated for all items. Due date field contains 'TBC' string rather than null. No action item missing from output.

T07

Ambiguous transcript: no clear owner stated for any action

Sample transcript with vague language ('someone should look into this') and no named assignees

Action items extracted with owner field set to 'Unassigned'. Summary flagged with a low-confidence marker in the metadata.

Owner field value is 'Unassigned' for all ambiguous items. Confidence flag present in the summary metadata object. No hallucinated owner names.

T08

Notion page structure: fields map correctly to Notion database schema

Valid summary object from T05 output

Notion page payload constructed with correct property keys: Meeting Title (title), Date (date), Attendees (multi-select), Decisions (rich text), Action Items (rich text).

All five Notion property keys present in the outbound payload. Data types match the Notion database schema. No extra or missing keys.

T09

Failure: transcript input is empty string

Empty string passed as transcript payload

Agent raises a validation error before calling the language model, logs the empty input event, and does not create a summary object.

Validation error logged. No summary object created. No Notion or ClickUp calls initiated. Error contains meeting ID reference.

Distribution Agent — estimated build time: 6 hours, complexity: Moderate. Tests T10 through T12.

Scenario

Input

Expected output

Pass criteria

T10

Happy path: attendee list retrieved from Google Calendar and email sent via Gmail

Google Calendar event ID with 4 attendees, confirmed Notion page URL, summary text, action items list

Gmail API call with To field containing all 4 attendee email addresses, subject line containing meeting title, body containing summary and action items, Notion page link in footer.

All 4 addresses present in To field. Subject contains meeting title string. Body contains action items section header and Notion URL. Gmail API returns 200.

T11

Happy path: Slack post to mapped channel

Channel ID for test Slack workspace, condensed summary text (under 280 words)

Slack API chat.postMessage call with correct channel ID, formatted message block containing meeting title, top 3 action items, and Notion link.

Slack API returns HTTP 200. Message appears in test channel. Meeting title present. Notion URL present. No raw JSON visible in the posted message.

T12

Failure: Google Calendar event returns no attendees

Google Calendar event ID for an event with no attendees field populated

Agent logs a missing-attendee warning, skips the Gmail send, posts to Slack only, and flags the run for manual review.

Gmail send not executed. Slack post executed. Warning event logged with calendar event ID. Manual review flag set to true in the run metadata.

Test and QA PlanPage 2 of 4

FS-DOC-06Quality

03Phase 2 — integration and edge case tests

Integration tests validate the handoffs between agents and the end-to-end data flow within the sandbox environment. IDs continue from Phase 1.

Scenario

Input

Expected output

Pass criteria

T13

Handoff T1: Transcription Agent to Summary Agent via orchestration layer

Zoom session close event in sandbox; pre-loaded 30-min sample recording

Transcript payload received by Summary Agent within 90 seconds of Zoom event. Meeting ID present in both agent logs confirming the same session.

Summary Agent invoked automatically. Meeting ID consistent across both logs. Transcript character count matches Transcription Agent output. Latency under 90 seconds.

T14

Handoff T2: Summary Agent to Notion and ClickUp creation

Valid summary object including 3 action items with owners and due dates

Notion page created in sandbox database. Three ClickUp tasks created in sandbox workspace, each with assignee and due date populated.

Notion API returns page ID. ClickUp API returns task IDs for all 3 tasks. Assignee and due date fields non-null on all ClickUp tasks. Both API calls complete within 30 seconds of each other.

T15

Handoff T3: Notion and ClickUp confirmation triggers Distribution Agent

Notion page ID and ClickUp task IDs passed to orchestration layer

Distribution Agent invoked after both upstream confirmations are received. Gmail and Slack calls execute in sequence.

Distribution Agent log shows trigger event containing both Notion page ID and at least one ClickUp task ID. Gmail and Slack calls both complete with HTTP 200.

T16

Human review gate: ops manager approves draft before distribution

Summary draft held at review checkpoint; approval event fired after 4 minutes

Distribution Agent remains paused until approval signal received. Once approved, Gmail and Slack calls execute normally.

Distribution Agent does not execute before approval signal. Time between approval signal and Gmail send is under 60 seconds. No duplicate sends.

T17

Full sandbox end-to-end: Zoom event through to Slack post

Zoom session close event; 45-min sample recording; 4 sandbox attendees; sandbox Calendar event

Transcript created, summary created, Notion page created, 4 ClickUp tasks created, Gmail sent to 4 addresses, Slack message posted. All within 5 minutes of trigger.

All six downstream outputs confirmed (transcript, summary object, Notion page ID, 4 ClickUp task IDs, Gmail 200, Slack 200). Total elapsed time under 5 minutes from trigger to Slack post.

T18

ClickUp API unavailable during task creation

Valid summary object; ClickUp sandbox endpoint returns HTTP 503

Orchestration layer catches the 503, retries twice with 30-second backoff, logs a persistent failure, and continues to Notion creation and Distribution Agent without blocking.

Two retry attempts logged with timestamps. ClickUp failure event recorded. Notion page still created. Gmail and Slack still sent. Failure flagged in run summary for manual follow-up.

T19

Slack channel misconfigured: channel ID not found

Distribution Agent with an invalid Slack channel ID

Slack API returns channel_not_found error. Agent logs the error with the invalid channel ID, skips the Slack step, and marks the run as partially complete. Gmail send is not affected.

Slack error logged with invalid channel ID string. Gmail send completes successfully. Run status set to 'partial'. No unhandled exception thrown.

Edge case tests cover abnormal inputs and boundary conditions that fall outside the standard flow. These use the E-series ID prefix.

Scenario

Input

Expected output

Pass criteria

E01

Duplicate Zoom session close event fired twice for the same meeting ID

Two identical Zoom webhook payloads with the same meeting ID arriving within 10 seconds

Idempotency check in the orchestration layer detects the duplicate. Second event is discarded. Only one transcript, one Notion page, one email, and one Slack post are produced.

Exactly one Notion page for the meeting ID. Exactly one Gmail send. Exactly one Slack post. Duplicate event logged as discarded. No duplicate ClickUp tasks.

E02

Zoom recording payload missing the recording URL field

Zoom webhook payload with meeting ID present but no download_url field

Transcription Agent raises a missing-field validation error, logs the meeting ID, and halts. No downstream agents invoked.

Validation error present in log with meeting ID and field name 'download_url'. No transcript created. No Notion or ClickUp writes. Alert event created.

E03

Transcript delivered to Summary Agent contains only filler words and no discernible content

Transcript string containing only 'uh', 'um', 'yeah', 'okay' repeated 40 times

Summary Agent produces an output flagged as low-content with a confidence score below threshold. Action items array is empty. Notion page is created with a content-warning note in the summary field.

Confidence score below 0.3 in metadata. Action items array length is 0. Notion page created with content-warning string in summary body. No ClickUp tasks created.

E04

Gmail API rate limit hit during a batch of meeting distributions

Five Distribution Agent calls within 60 seconds, exceeding Gmail API sending quota for the test account

Orchestration layer queues excess sends and retries with exponential backoff. All five emails eventually sent within 10 minutes. No sends dropped.

All five Gmail sends confirmed with HTTP 200 across the retry window. No send permanently failed. Retry events logged for each queued item.

E05

Human review gate times out: ops manager does not respond within 30 minutes

Summary draft held at review checkpoint; no approval or rejection event fired within 30 minutes

Orchestration layer fires a timeout event, sends a reminder notification to the ops manager via Slack DM, and holds the draft for a further 15 minutes before escalating to a second reviewer.

Timeout event logged at T+30 minutes. Slack DM sent to ops manager account. Draft not distributed before approval. Escalation event logged at T+45 minutes if still no response.

E06

Notion API token expired mid-run

Summary object ready for page creation; Notion API returns HTTP 401 Unauthorized

Orchestration layer catches the 401, logs a credential failure event with the resource name 'Notion', halts the Notion and ClickUp steps, and sends an alert to the FullSpec monitoring channel.

HTTP 401 logged with resource label 'Notion'. No partial Notion page created. ClickUp step also halted to preserve data consistency. Alert message posted to monitoring channel 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: use a dedicated internal test calendar event booked between FullSpec team members only. Use an internal test email address (not a customer-facing address) for the Gmail send. After each production test run, void the test records: delete or archive the Notion page created, delete the ClickUp tasks created, and confirm the Slack message has been removed from the channel. Do not use a meeting that contains sensitive, confidential, or HR-related content. Confirm with the process owner that the test Zoom account has Cloud Recording enabled before the first run.

Scenario

Input

Expected output

Pass criteria

T20

Full production run: 30-minute internal test meeting, standard flow, no human edits

Live Zoom session close event on production account; 30-min recording; Google Calendar event with 3 internal test attendees

Transcript produced within 3 minutes of session close. Notion page created in production database with correct title, date, attendees, and action items. Three ClickUp tasks created with owners and due dates. Gmail follow-up sent to all 3 test addresses. Slack message posted to designated team channel.

All six outputs confirmed via API response logs. Total elapsed time from Zoom event to Slack post under 5 minutes. No manual intervention required. All production API calls return HTTP 200 or 201.

T21

Production run with human review gate: ops manager edits draft before send

Same setup as T20; ops manager presented with draft in review interface; edits one action item owner name

Edited draft reflects the changed owner name in all downstream outputs: Notion page, ClickUp task assignee, and Gmail body all show the corrected owner.

Owner name in Notion, ClickUp, and Gmail body all match the edited value, not the original AI-extracted value. Distribution occurs only after approval event. No version of the original (unedited) owner name appears in any output.

T22

Error log verification: confirm all run events are captured in the monitoring log

Completed run from T20 or T21

Monitoring log contains: trigger event with meeting ID and timestamp, transcript completion event, summary creation event, Notion page ID, ClickUp task IDs, Gmail message ID, Slack message timestamp. All events linked by a single run ID.

All seven event types present in the log for the run ID. No orphaned events with missing run IDs. Log entry timestamps are in ascending order matching the execution sequence.

T23

Production run with 90-minute meeting at maximum supported length

Live Zoom session close event; 90-min recording; 5 attendees on Calendar event

Transcript produced within 8 minutes of session close. Summary and action items extracted without truncation. Notion page, ClickUp tasks, Gmail, and Slack all complete successfully.

Transcript covers full 90 minutes with no cut-off. Summary object non-empty. At least one action item extracted. All downstream outputs confirmed. Total elapsed time from Zoom event to Slack post under 12 minutes.

T24

Process owner review and approval: final gate before go-live sign-off

Process owner (Operations Manager) reviews outputs from T20 and T21: Notion page, ClickUp tasks, Gmail received in inbox, Slack message in channel

Process owner confirms: notes are accurate, action items have correct owners and due dates, email formatting is acceptable, Slack post is readable and appropriately concise. Approval recorded in the FullSpec confirmation log.

Process owner provides written confirmation (email or FullSpec platform response) that all four output types meet quality expectations. Confirmation recorded in the FullSpec run log with process owner name, date, and approval status set to 'approved'. No separate signature block required. This case constitutes the go-live approval gate.

Once T24 is recorded as approved in the FullSpec confirmation log, the automation is cleared for full production operation. Any issues identified during Phase 3 are logged as defects, triaged by the FullSpec team, and resolved before the approval gate is re-run. Contact support@gofullspec.com for all defect reports and resolution tracking.

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