Back to Internal Knowledge Base Management

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

Internal Knowledge Base Management

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

This document defines the full testing programme for the Internal Knowledge Base Management automation, covering both agents (Knowledge Triage Agent and Review and Publish Coordinator Agent) and all integrated tools (Google Forms, Notion, Slack, Google Docs). Testing runs in three sequential phases: unit, integration, and end-to-end production. The FullSpec team executes Phases 1 and 2 entirely in sandbox environments; your process owner joins Phase 3 for sign-off on the live system. No phase begins until every test case in the previous phase achieves a full pass.

01Testing approach

All testing proceeds through three phases in strict sequence. No phase begins until the previous phase has fully passed, meaning every test case returns the expected output and no blocking defects remain open. This approach ensures that integration and production tests are only run against logic that has been individually verified, reducing the risk of compounding failures in later stages.

Phase 1: Unit Testing

Each agent and tool node tested in isolation

Scope

Individual agent logic, trigger parsing, classification rules, duplicate detection, status watches, and Slack message templating — all tested node by node without cross-system calls.

Environment

Sandbox only. Notion test workspace, Google Forms test sheet, Slack test channel (#qa-sandbox), and Google Docs test folder. No production data or live records touched.

Credential rule

Sandbox API tokens only. Production Notion integration token, Slack bot token, and Google service account must not be loaded into the automation platform during Phase 1.

Pass condition

All cases T01 through T14 return expected outputs with zero blocking errors. Warnings are logged and reviewed but do not block promotion to Phase 2.

Who runs it

FullSpec team only. No process owner involvement required at this phase.

Phase 2: Integration and Edge Case Testing

Agent handoffs and failure scenarios across connected systems

Scope

End-to-end agent handoffs across Google Forms, Notion, Slack, and Google Docs. Edge cases including duplicate submissions, missing required fields, unavailable tools, and reviewer non-response within the defined escalation window.

Environment

Sandbox environment with live API calls to sandbox workspaces. All Notion databases, Slack channels, and Google Docs used are dedicated test instances, not production.

Credential rule

Sandbox credentials only. The integration must be re-pointed to production credentials only after Phase 3 is authorised. Credential swap is a deliberate, documented step.

Pass condition

All cases T15 through T22 pass and all edge cases E01 through E06 return the expected fallback or error handling behaviour with no data written to production systems.

Who runs it

FullSpec team only. Process owner may observe but is not required.

Phase 3: End-to-End Production Test

Full live-system verification with process owner approval

Scope

A complete production run tracing one content request from Google Form submission through triage, Notion task creation, Slack notifications, reviewer routing, publication, team announcement, and the first scheduled review reminder.

Environment

Production. Live Notion workspace, live Slack channels, live Google Forms endpoint. All test records must be voided or archived after the test run is complete.

Credential rule

Production credentials active. The FullSpec team performs the credential swap from sandbox to production tokens immediately before Phase 3 begins, with the process owner present.

Pass condition

All cases T23 through T27 pass, including the final process owner review-and-approval case (T27). Approval is recorded in the FullSpec confirmation record, not a separate signature block.

Who runs it

FullSpec team executes. Process owner is required for T27 (review and approval) and must be available for the full Phase 3 session.

Test and QA PlanPage 1 of 4

FS-DOC-06Quality

02Phase 1 — unit test cases

Sandbox credentials only during Phase 1. Do not load production Notion tokens, Slack bot tokens, or Google service account keys into the automation platform at any point during unit testing. All Notion writes, Slack messages, and Google Docs reads in this phase must target dedicated sandbox instances. The FullSpec team will confirm credential isolation before the first test run.

Knowledge Triage Agent — unit test cases

Scenario

Input

Expected output

Pass criteria

T01

Happy path: new article request, no duplicate

Google Form response: subject 'Expense Claim Policy', category 'Policy', urgency 'Normal', no overlapping Notion articles found

Request classified as 'New Article', priority set to 'Standard', owner category assigned as 'Operations', Notion task record prepared with all fields populated

Classification field equals 'New Article'; priority equals 'Standard'; owner category populated; Notion payload contains title, due date, and review interval

T02

Happy path: article update request

Google Form response: subject 'Remote Working Policy', category 'Update', urgency 'High'

Request classified as 'Update', priority set to 'High', existing Notion article ID referenced in task payload

Classification equals 'Update'; priority equals 'High'; existing article ID present in Notion task payload

T03

Duplicate detection: exact title match

Google Form response: subject matches an existing published Notion article title exactly

Request classified as 'Duplicate', workflow branches to Operations Manager exception path, no new Notion task created

Classification equals 'Duplicate'; no new Notion record created; exception flag raised and logged

T04

Duplicate detection: near-match title

Google Form response: subject 'Expense Reimbursement Guide' when 'Expense Claim Policy' exists in Notion

Request flagged as 'Possible Duplicate', routed to Operations Manager for review with both article titles listed

Flag equals 'Possible Duplicate'; both article titles included in exception payload; Operations Manager notified

T05

Failure: Google Form response missing required field (subject blank)

Google Form response received with subject field empty

Workflow halts at parsing step; error logged with field name; no Notion task created; error notification sent to FullSpec error channel

Workflow does not proceed past parse step; error log entry created; no orphaned Notion records

T06

Failure: Notion API returns 401 unauthorised during duplicate check

Valid form response triggers duplicate check; Notion sandbox returns 401

Agent catches error, logs Notion API failure with timestamp and status code, halts workflow, raises alert

Error caught and logged; workflow halted cleanly; no partial Notion write; alert raised within 60 seconds

T07

Priority escalation: urgency flag set to Critical

Google Form response with urgency field set to 'Critical'

Priority assigned as 'Critical', owner notified immediately via Slack sandbox channel, due date set to next business day

Priority equals 'Critical'; Slack message triggered within sandbox; due date equals next business day

Review and Publish Coordinator Agent — unit test cases

Scenario

Input

Expected output

Pass criteria

T08

Happy path: Notion status changes to 'Ready for Review'

Notion sandbox article task status updated to 'Ready for Review' by assigned owner

Agent detects status change, sends Slack direct message to designated reviewer with article link and review deadline

Slack DM sent to correct reviewer within 2 minutes of status change; message contains article link and deadline

T09

Happy path: reviewer approves article in Notion

Notion sandbox article task status updated to 'Approved' by reviewer

Agent triggers publication step: Notion article status set to 'Published', metadata written (owner, publish date, next review date), Slack announcement prepared

Notion status equals 'Published'; all metadata fields populated; Slack announcement payload generated correctly

T10

Happy path: Slack team announcement posted on publication

Publication step completes for a sandbox article

Formatted Slack message posted to sandbox team channel with article title, link, and one-line summary from metadata

Slack message appears in correct sandbox channel; contains title, link, and summary; posted within 2 minutes of publication

T11

Scheduled review reminder triggered

Sandbox Notion article reaches its review due date (simulated by setting due date to current date in test)

Agent sends Slack reminder to article owner with article link and prompt to confirm currency or submit update

Slack reminder sent to correct owner; message contains article link; sent within the scheduled reminder window

T12

Failure: Notion status watch fails to detect change (webhook timeout)

Notion sandbox status updated but webhook call to automation platform times out

Automation platform logs missed webhook event; polling fallback checks status within 5 minutes; if confirmed, workflow resumes

Polling fallback triggered within 5 minutes; workflow resumes from correct step; no duplicate actions fired

T13

Failure: Slack API rate limit hit during announcement

Slack sandbox API returns 429 Too Many Requests during announcement step

Agent catches 429 response, waits the retry-after interval, retries once, logs the delay

Retry fires after retry-after interval; Slack message delivered on retry; delay logged; no duplicate message sent

T14

Failure: reviewer sets Notion status to 'Changes Required' instead of 'Approved'

Notion sandbox article task status set to 'Changes Required' by reviewer

Agent detects non-approval status, sends Slack DM to article owner with reviewer comments link and revised due date; publication step not triggered

Publication step not triggered; Slack DM sent to owner; reviewer comment link included; Notion status remains 'Changes Required'

Test and QA PlanPage 2 of 4

FS-DOC-06Quality

03Phase 2 — integration and edge case tests

Integration tests — agent handoffs across connected systems

Scenario

Input

Expected output

Pass criteria

T15

Full handoff: form submission to Notion task creation

Google Form sandbox response submitted; Knowledge Triage Agent classifies and prepares payload

Notion sandbox task created with all fields: title, classification, priority, assigned owner category, due date, review interval

Notion task record exists with all required fields populated; no manual input required; creation timestamp within 3 minutes of form submission

T16

Full handoff: Notion task to Slack owner notification

Notion sandbox task created by triage agent; owner assignment written to task

Slack sandbox DM sent to correct owner with task link, summary of request, and due date

Slack DM received in sandbox by correct owner persona; all three content elements present; delivered within 2 minutes of task creation

T17

Full handoff: 'Ready for Review' status to reviewer Slack notification

Owner marks Notion sandbox task as 'Ready for Review'; Review and Publish Coordinator Agent detects change

Slack DM sent to designated reviewer with Google Docs draft link and review deadline

Reviewer receives DM; Google Docs link is valid and points to correct sandbox draft; deadline date is correct

T18

Full handoff: approval to publication and announcement

Reviewer updates Notion sandbox status to 'Approved'

Notion status updated to 'Published'; metadata written; Slack team announcement posted to sandbox channel

Notion record shows 'Published' status with metadata; Slack announcement in correct channel within 3 minutes of approval

T19

Full handoff: publication to scheduled review reminder

Notion sandbox article published with review date set to current date (simulated)

Slack reminder sent to article owner with article link and confirmation prompt

Reminder delivered to correct owner; article link valid; sent within scheduled window

T20

Duplicate detection cross-system: triage agent queries live Notion sandbox library

Form submission with subject closely matching two existing sandbox Notion articles

Triage agent queries Notion, identifies both near-matches, routes to Operations Manager exception with both titles listed

Exception routed correctly; both article titles present in exception payload; no new task created

T21

Google Docs draft link passed correctly between agents

Owner submits draft link in Notion sandbox task; Review and Publish Coordinator reads the field

Agent extracts Google Docs URL from Notion task field and includes it in reviewer Slack DM

URL in Slack DM matches URL in Notion task field exactly; link is accessible in sandbox

T22

End-to-end sandbox run: form to announcement without manual intervention

New article request submitted via Google Form sandbox; no duplicate detected; owner marks ready; reviewer approves

Complete workflow executes: Notion task created, owner notified, reviewer notified, article published, team announcement posted

All five stages complete without manual intervention; all timestamps within expected windows; no errors logged

Edge case tests

Scenario

Input

Expected output

Pass criteria

E01

Duplicate form submission: same request submitted twice within 10 minutes

Identical Google Form sandbox responses submitted at t=0 and t=8 minutes

Second submission detected as duplicate of in-progress task; second workflow run halted; single Notion task remains; ops manager alerted

Only one Notion task created; second run terminated cleanly; alert generated for ops manager; no duplicate Slack DMs to owner

E02

Missing data: form submission with category field blank

Google Form sandbox response with category field left empty

Triage agent logs field-missing error, assigns default category 'Uncategorised', routes to Operations Manager for manual category assignment before task creation

Task not auto-created without category; default 'Uncategorised' label applied; ops manager notified with original form data

E03

Unavailable tool: Notion API unreachable at task creation step

Triage agent attempts to write Notion task; Notion sandbox returns 503 Service Unavailable

Automation platform retries up to 3 times with exponential backoff (30s, 60s, 120s); if all retries fail, error logged and ops manager alerted via Slack

Three retry attempts logged with correct intervals; after final failure, error alert sent to ops manager Slack sandbox; original form data preserved in error log

E04

Unavailable tool: Slack unreachable during owner notification

Notion task created successfully; Slack sandbox returns 503 during DM send

Automation platform retries twice; if still unavailable, error logged with task ID and owner identifier; Notion task remains with status 'Pending Notification'

Retry attempts logged; Notion task status set to 'Pending Notification'; error record contains task ID and intended recipient; no silent failure

E05

Human timeout: reviewer does not respond within 3 business days of 'Ready for Review' notification

Notion sandbox task status 'Ready for Review' for 3 business days with no reviewer action

Review and Publish Coordinator Agent sends an escalation Slack DM to the Operations Manager with task link and original reviewer name; Notion task status updated to 'Escalated'

Escalation DM sent at exactly 3-business-day mark; message contains task link and reviewer name; Notion status equals 'Escalated'

E06

Human timeout: article owner does not acknowledge review reminder within 5 business days

Notion sandbox article passes review date; reminder sent; no owner response within 5 business days

Second reminder sent to owner with increased urgency flag; Operations Manager copied on second reminder; Notion article flagged as 'Review Overdue' in knowledge base

Second reminder delivered to owner and ops manager; Notion article status shows 'Review Overdue'; original reminder timestamp preserved in article record

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 email address and a clearly labelled test Google Form submission (e.g. subject prefixed with '[TEST]') for all production test cases. Do not use a real staff name as the article owner or reviewer during testing unless that person is aware and has consented. After Phase 3 is complete, the FullSpec team will void or archive all test records in Notion, remove the test Slack announcements from the team channel, and confirm in writing that no test data remains visible in the live knowledge base. Do not proceed to Phase 3 unless Phase 2 has a full pass record.

Scenario

Input

Expected output

Pass criteria

T23

Production run: new article request submitted via live Google Form

Test Google Form submission on live endpoint: subject '[TEST] Equipment Return Procedure', category 'Policy', urgency 'Normal', submitted by internal test address

Automation platform detects live form response; Knowledge Triage Agent classifies as 'New Article', priority 'Standard'; Notion production task created with all metadata fields populated

Notion production task visible in live workspace within 3 minutes; all fields correct: title, classification, priority, owner category, due date, review interval; no manual input by FullSpec or process owner

T24

Production run: owner notified via live Slack

Notion production task from T23 triggers Slack notification to test owner persona (internal test address mapped to Slack)

Slack DM received by test owner in live workspace with task link, request summary, and due date

Slack DM visible in live Slack workspace for test owner; all three content elements present; delivery within 2 minutes of task creation

T25

Production run: reviewer routing and publication on approval

Test owner marks Notion production task as 'Ready for Review'; reviewer (internal test address) approves in Notion

Review and Publish Coordinator Agent routes to reviewer via Slack DM; on approval: Notion status set to 'Published', metadata written, team Slack channel receives announcement

Reviewer receives DM with correct Google Docs link; on approval, Notion status equals 'Published'; all metadata fields written; Slack announcement posted to live team channel within 3 minutes

T26

Production error-log verification

Review all automation platform execution logs generated during T23 through T25

Logs show clean execution with no unhandled errors, no retries triggered, and correct timestamps for each workflow step across both agents

Zero unhandled errors in execution log; all step timestamps within expected windows; both agent runs logged with correct input and output payloads; FullSpec team reviews and signs off on log export

T27

Process owner review and approval

Process owner (Operations Manager) reviews the complete production test run: Notion task record, Slack messages received, publication output, team announcement, and execution logs presented by FullSpec team

Process owner confirms all outputs match the agreed automated flow design, all notifications are correctly worded, the Notion knowledge base record is accurate, and no unintended side effects occurred during the test run

Process owner verbally confirms pass on all outputs and provides approval. Approval is recorded by the FullSpec team in the FullSpec confirmation record for this process, timestamped and linked to the Phase 3 log export. No separate signoff block is required. This case represents final QA sign-off and authorises go-live.

After T27 is recorded as passed, the FullSpec team will swap all sandbox references to production, archive Phase 1 and Phase 2 sandbox workspaces, void all test records in the live Notion workspace, and confirm readiness for the staff handover and go-live session scheduled for the end of Week 4. Contact the FullSpec team at support@gofullspec.com with any questions about test results or phase promotion.

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