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

Quality Control Checklist Automation

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

This document defines the structured test and quality assurance approach for the Quality Control Checklist automation. It covers all test cases across three sequential phases: unit testing of individual agents, integration and edge-case testing of agent handoffs and failure scenarios, and end-to-end production validation. The FullSpec team runs Phases 1 and 2 entirely in sandbox environments. The process owner joins Phase 3 for production sign-off. No phase begins until the previous phase has fully passed every test case documented here.

01Testing approach

Testing proceeds in three phases in sequence. No phase begins until the previous phase fully passes all assigned test cases. Phase 1 validates each agent in isolation using sandbox credentials and synthetic data. Phase 2 validates handoffs between agents and the system's behaviour under edge-case conditions. Phase 3 runs a controlled end-to-end test in the live production environment with the process owner present. All results are logged in the FullSpec test tracker and shared with the process owner at the close of each phase.

Phase 1: Unit Testing

Each agent tested in isolation with synthetic data

Scope

QC Review Agent and Reporting Agent tested independently against controlled inputs

Environment

Sandbox only — no production records written

Credential rule

Sandbox API keys for Google Forms, Airtable, Slack, and Gmail must be used; no production credentials permitted

Pass condition

All test cases T01 through T10 return expected outputs with zero deviations

Who runs it

FullSpec team only

Phase 2: Integration and Edge-Case Testing

Agent handoffs and failure-mode scenarios validated

Scope

End-to-end agent handoffs from Google Forms trigger through to Slack alert and Airtable corrective action; plus edge cases covering duplicate submissions, missing fields, tool unavailability, and human timeout

Environment

Sandbox for all integration tests; production read-only access may be granted for schema validation only

Credential rule

Sandbox credentials only; production write access is not permitted during Phase 2

Pass condition

All integration test cases T11 through T17 and all edge-case cases E01 through E05 pass without unhandled errors or data corruption

Who runs it

FullSpec team only

Phase 3: End-to-End Production Test

Live environment validation with process owner sign-off

Scope

Full production run using a designated internal test inspector identity, tracing a real form submission through every downstream step to Gmail report delivery

Environment

Production — live Airtable base, live Slack workspace, live Gmail account

Credential rule

Production credentials used; test records must be clearly labelled TEST and voided or deleted immediately after sign-off

Pass condition

All test cases T18 through T21 pass; process owner reviews outputs and records approval in the FullSpec confirmation

Who runs it

FullSpec team executes; process owner observes and approves

Test and QA PlanPage 1 of 4

FS-DOC-06Quality

02Phase 1 — unit test cases

Sandbox credentials only: All Phase 1 tests must be executed using sandbox API keys for Google Forms, Airtable, Slack, and Gmail. No production credentials are to be configured or used at this stage. Any test that inadvertently writes to a production table must be flagged immediately to the FullSpec lead and the affected record must be deleted before testing continues.

QC Review Agent — Complexity: Moderate. Estimated build time: 16 hours. The following table covers the happy path and the key failure modes for this agent.

Scenario

Input

Expected Output

Pass Criteria

T01

Happy path — all items pass

Google Forms submission with all checklist items marked PASS, batch ID: BATCH-001, inspector: Sam Tran

Airtable inspection record created with status PASS; no corrective action created; no Slack alert sent

Airtable record exists with correct field values; corrective action table unchanged; Slack channel silent

T02

Single minor failure detected

Form submission with one item marked FAIL at severity MINOR, batch ID: BATCH-002

Airtable inspection record created with status FAIL-MINOR; no corrective action created; no Slack alert sent

Record status field equals FAIL-MINOR; corrective action count unchanged; no Slack message posted

T03

Single critical failure detected

Form submission with one item marked FAIL at severity CRITICAL, batch ID: BATCH-003

Airtable inspection record created; linked corrective action record created with priority HIGH and due date populated; Slack alert posted to operations channel

Inspection record and corrective action record are linked; Slack message contains batch ID, failed criterion, severity label, and Airtable deep link

T04

Multiple critical failures in one submission

Form submission with three items marked FAIL at severity CRITICAL, batch ID: BATCH-004

One corrective action record per critical failure created in Airtable (three total); one consolidated Slack alert listing all three failures

Three corrective action records exist linked to the same inspection record; Slack message lists all three failed criteria without duplication

T05

Mixed severity failures — critical and minor together

Form submission with one CRITICAL failure and two MINOR failures, batch ID: BATCH-005

Corrective action created for the critical failure only; minor failures noted on the inspection record; Slack alert sent referencing the critical failure

Exactly one corrective action record created; inspection record contains all three failure notes; Slack message references only the critical item

T06

Form submission with no batch identifier

Form submission where the batch ID field is blank

Automation halts before writing to Airtable; error event logged in the platform error log; no partial record created

No Airtable record created; error log entry present with timestamp and field name; Slack alert not sent

T07

Airtable write failure — simulated API timeout

Valid form submission; Airtable sandbox API configured to return a 503 response on first attempt

Automation retries up to three times with exponential back-off; on continued failure an error is logged and the FullSpec error Slack channel receives a system alert

Retry log shows three attempts; error notification arrives in the designated system-alert channel within 60 seconds of final failure

T08

Slack API unavailable — simulated

Valid form submission with a critical failure; Slack sandbox token configured to return 401

Airtable records are still written successfully; Slack failure is caught and logged; error notification sent via fallback Gmail to the process owner address

Airtable inspection and corrective action records present and correct; Gmail fallback message received within 2 minutes; error log records the Slack failure

T09

Corrective action auto-assignment by failure category

Form submission with a CRITICAL failure in category PACKAGING; Airtable assignment rules map PACKAGING to assignee David Mensah

Corrective action record assigned to David Mensah in Airtable; Slack direct message sent to David Mensah with task details and due date

Assigned-to field on the corrective action record equals David Mensah; DM received in Slack sandbox with correct content

T10

Severity rule boundary — MAJOR threshold

Form submission with one item marked FAIL at severity MAJOR (below CRITICAL threshold)

Airtable inspection record created with status FAIL-MAJOR; corrective action created at priority MEDIUM; Slack alert sent to operations channel

Corrective action priority field equals MEDIUM; Slack message tone matches MAJOR template (not CRITICAL); record correctly linked

Reporting Agent — Complexity: Simple. Estimated build time: 8 hours. The following table covers the happy path and the key failure modes for this agent.

Scenario

Input

Expected Output

Pass Criteria

T11

Happy path — Monday 07:00 scheduled trigger fires

Scheduled trigger activates; Airtable sandbox contains 12 inspection records from the previous 7 days with mixed pass and fail results

Gmail summary email sent to the management distribution list containing pass rate, top failure categories, and count of open corrective actions

Email received within 2 minutes of trigger; subject line contains the correct date range; all three summary sections present and figures match Airtable source data

T12

No inspections in the previous 7 days

Scheduled trigger activates; Airtable sandbox contains zero records in the query window

Gmail email sent with a no-inspections-this-week notice; email does not contain broken tables or null values

Email received; body contains the expected no-data message; no template placeholders visible; no runtime error in platform logs

T13

Gmail send failure — simulated authentication error

Scheduled trigger activates normally; Gmail sandbox OAuth token configured as expired

Automation logs the Gmail failure; error event written to platform error log; system alert posted to the FullSpec error channel in Slack

No email delivered; error log entry present with OAuth error code; Slack system alert received within 60 seconds

Test and QA PlanPage 2 of 4

FS-DOC-06Quality

03Phase 2 — integration and edge case tests

Phase 2 validates that the two agents hand off correctly end to end and that the system behaves safely under abnormal conditions. Integration tests continue the T sequence from T14. Edge-case tests use the E sequence beginning at E01.

Integration test cases — agent handoffs

Scenario

Input

Expected Output

Pass Criteria

T14

Full handoff — form submission to Slack alert within SLA

Inspector submits a Google Forms entry with one CRITICAL failure in the sandbox

Airtable record written, corrective action created, and Slack alert posted; all three completed within 60 seconds of form submission

Timestamps on all three events fall within a 60-second window from the Google Forms webhook receipt timestamp

T15

Reporting Agent reads corrective action data written by QC Review Agent

QC Review Agent writes three corrective action records to Airtable sandbox during the test week; Reporting Agent scheduled trigger fires on Monday

Weekly summary email lists open corrective action count as 3 and references the correct failure categories

Email open-corrective-actions count matches the exact number of unresolved records in the Airtable sandbox; category labels match

T16

Concurrent submissions — two inspections submitted within 5 seconds

Inspector A and Inspector B both submit forms simultaneously in the sandbox; one has a CRITICAL failure, one is all-pass

Two separate Airtable records created with no field cross-contamination; one corrective action and Slack alert for the failing submission only

Record count in Airtable increases by exactly two; corrective action linked to the correct inspection record; no field values from one record appear in the other

T17

End-to-end latency benchmark

Standard form submission with one CRITICAL failure submitted to the sandbox

All downstream steps (Airtable write, corrective action creation, Slack alert, assignment DM) complete within 90 seconds total

Platform execution log shows total elapsed time under 90 seconds; all four downstream steps appear in the log with individual durations

Edge-case test cases

Scenario

Input

Expected Output

Pass Criteria

E01

Duplicate form submission — same batch ID submitted twice within 1 minute

Inspector submits the same Google Forms entry twice (identical batch ID, timestamp within 60 seconds)

Automation detects the duplicate via Airtable batch-ID lookup; second record is rejected and a warning is logged; no duplicate corrective actions created

Airtable contains exactly one record for the batch ID; platform log contains a duplicate-detected entry; no duplicate Slack alert posted

E02

Missing inspector name field

Form submitted with the inspector name field left blank (all other required fields populated)

Automation writes the record to Airtable with inspector name as UNKNOWN; record is flagged with a data-quality warning tag; no automation halt

Airtable record present with inspector field value UNKNOWN and data-quality tag applied; downstream steps proceed normally

E03

Airtable base unavailable for more than 10 minutes

Valid form submitted; Airtable sandbox API configured to return 503 for all requests over a 10-minute window

Automation retries with back-off during the outage window; once Airtable recovers, the queued submission is processed; no data is lost

After Airtable recovers, the record appears in the base with the original submission timestamp; platform log shows retry attempts during the outage window

E04

Slack channel deleted or renamed mid-run

Valid form submitted with a CRITICAL failure; target Slack channel is renamed between trigger and the Slack step

Automation catches the channel-not-found error; falls back to posting to the designated backup channel; error is logged

Message appears in the backup channel with correct content; error log records channel-not-found with the original channel name and the fallback action taken

E05

Human timeout — corrective action not confirmed within 72 hours

Corrective action record created in Airtable sandbox with status OPEN; 72-hour timer elapses without the status being changed to RESOLVED

Automation sends an escalation Slack direct message to the Operations Manager and adds an OVERDUE tag to the Airtable corrective action record

Slack DM received by the Operations Manager sandbox user; Airtable record status field shows OVERDUE tag; timestamp of escalation recorded on the record

Test and QA PlanPage 3 of 4

FS-DOC-06Quality

04Phase 3 — end-to-end production test

Important before running Phase 3: Use a designated internal test inspector identity (for example, test.inspector@[YourCompany.com]) and a test batch identifier prefixed with TEST- for every submission. Do not use a real inspector name or a live batch ID. After the process owner has reviewed and approved all outputs, every record created during Phase 3 must be voided or permanently deleted from the production Airtable base, and the test Gmail messages must be removed from the management distribution list inbox. The FullSpec team will confirm deletion before the process goes live.

Scenario

Steps Traced

Expected Production Output

Pass Criteria

T18

Full production run — critical failure submission traced end to end

1. Submit Google Forms entry with one CRITICAL failure using the test identity and batch ID TEST-P001. 2. Confirm Airtable write. 3. Confirm corrective action creation. 4. Confirm Slack alert in the live operations channel. 5. Confirm Slack DM to the assigned corrective action owner.

All five downstream events complete in production within 90 seconds; Airtable inspection and corrective action records present with correct data; Slack alert and DM received with correct content

All five events verified in production platform execution log; Airtable records match input data exactly; both Slack messages received with correct batch ID, failure details, severity label, and Airtable deep link

T19

Production run — all-pass submission confirms no corrective action is triggered

Submit Google Forms entry with all checklist items marked PASS using test identity and batch ID TEST-P002

Airtable inspection record created with status PASS; no corrective action record created; no Slack alert posted to the operations channel

Airtable record present with status PASS; corrective action table count unchanged from before the test; operations Slack channel shows no new message

T20

Error-log verification — confirm platform error logging is operational in production

FullSpec team triggers a deliberate controlled error (invalid field value injected via the automation platform test console) in the production environment

Error is caught by the platform error handler; entry written to the platform error log with timestamp, error type, and affected step; system alert posted to the FullSpec error Slack channel

Error log entry present and readable; system alert received in the FullSpec error channel within 60 seconds; no unhandled exception reaches the production Airtable base or Gmail

T21

Process owner review and approval — final Phase 3 sign-off

Process owner (Operations Manager) reviews: the Airtable inspection record from T18, the corrective action record from T18, the Slack alert from T18, the all-pass record from T19, and the error log entry from T20. FullSpec team presents the execution logs and answers any questions.

Process owner confirms all outputs are correct and match expectations; confirms the test records are clearly labelled TEST and agrees to their deletion; records approval in the FullSpec confirmation form

Process owner approval recorded in the FullSpec confirmation. All TEST-prefixed Airtable records deleted. Phase 3 marked PASSED in the FullSpec test tracker. System is cleared for go-live on the agreed date.

Once T21 is marked PASSED and the process owner's approval is recorded in the FullSpec confirmation, the automation is cleared for go-live. No separate sign-off document is required. For any questions during or after testing, 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