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

Asset and Equipment Tracking

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

This document defines the structured test programme for the Asset and Equipment Tracking automation, covering the Asset Intake Agent, Maintenance Scheduler Agent, and Finance Sync Agent. Testing runs in three sequential phases: unit tests in a sandbox environment, integration and edge-case tests against connected sandboxes, and a final end-to-end run in production. The FullSpec team executes Phases 1 and 2 independently; the process owner joins Phase 3 to review outputs and record formal approval. No phase begins until all cases in the preceding phase have passed.

01Testing approach

Testing runs in three phases in strict sequence. No phase begins until the previous phase fully passes, with all test cases marked green and any failures resolved and re-tested. This gate approach ensures that integration and end-to-end issues are not masked by underlying unit-level defects.

Phase 1: Unit Tests

Each agent tested in isolation against sandbox credentials

Scope

Individual agent logic: field validation, ID generation, QR code trigger, Xero record construction, and reminder scheduling rules. No live cross-agent handoffs.

Environment

Sandbox only. Airtable test base, QR Code Generator sandbox endpoint, Xero demo company, Slack test workspace, Google Workspace sandbox calendar.

Credential rule

All credentials must be sandbox or demo credentials. No production API keys, tokens, or OAuth grants may be present in the environment during Phase 1.

Pass condition

All cases T01 through T16 return the expected output with no unhandled exceptions. Every failure mode produces the correct error state or alert.

Who runs it

FullSpec team only.

Phase 2: Integration and Edge-Case Tests

Agent handoffs and boundary conditions tested across connected sandboxes

Scope

Cross-agent data handoffs, tool-to-tool API calls, duplicate detection, missing-field handling, tool unavailability simulation, and human-action timeout scenarios.

Environment

Sandbox only. All five connected tools must be running their sandbox or demo instances simultaneously for handoff tests.

Credential rule

Sandbox credentials only. Integration credentials are stored in the automation platform's test environment variable set, not the production set.

Pass condition

All cases T17 through T26 pass, and all edge cases E01 through E08 either recover gracefully or produce the correct error notification.

Who runs it

FullSpec team only.

Phase 3: End-to-End Production Test

Full production run observed and approved by the process owner

Scope

One complete asset lifecycle run in the live production environment: intake through QR generation, assignment notification, maintenance scheduling, Xero fixed-asset entry, and audit report posting.

Environment

Production. Live Airtable base, live Xero company, live Slack workspace, live Google Calendar, and the production QR Code Generator API key.

Credential rule

Production credentials used. Access is restricted to the FullSpec team and the nominated process owner during this phase. No credentials are shared beyond these parties.

Pass condition

All cases T27 through T31 pass, including T31 (process owner review and sign-off). The process owner's approval is recorded in the FullSpec confirmation system.

Who runs it

FullSpec team executes; process owner (Operations Manager) observes and approves at T31.

Test and QA PlanPage 1 of 4

FS-DOC-06Quality

02Phase 1 — unit test cases

Sandbox credentials only during Phase 1. No production Airtable base, Xero company, or Slack workspace token may be used. The QR Code Generator must be pointed at its sandbox endpoint (api-sandbox.qr-generator.io). All test records created in this phase are disposable and must not be migrated to production.

Asset Intake Agent — validates new and updated asset records, generates asset IDs, triggers QR code creation, and sends Slack assignment notifications.

Scenario

Input

Expected output

Pass criteria

T01

Happy path: complete new asset record

Airtable row created with all required fields: asset name, category, purchase date, cost, assigned staff, maintenance interval.

Unique asset ID generated (format ASSET-YYYY-NNNN), QR code URL written back to the Airtable row, Slack assignment message sent to the named staff member.

Asset ID present in record; QR URL resolves to a valid label; Slack message received within 60 seconds of row creation.

T02

Record update triggers re-validation

Existing asset row updated: assigned staff member changed.

New Slack assignment notification sent to the updated assignee; QR URL unchanged; asset ID unchanged.

Slack message received by new assignee; no duplicate QR code generated; record shows updated assignee.

T03

Missing required field: no purchase date

Airtable row created with purchase date field left blank.

Agent flags the record with status 'Incomplete'; Slack alert sent to Operations Coordinator listing the missing field; no asset ID generated; no QR code triggered.

Record status set to 'Incomplete'; Slack alert received; asset ID field remains empty.

T04

Missing required field: no assigned staff

Airtable row created with assigned staff field blank.

Agent flags record as 'Incomplete'; Slack alert sent to Operations Coordinator; no assignment notification sent.

Record status 'Incomplete'; no Slack assignment message sent to an empty recipient; coordinator alert received.

T05

QR Code Generator API returns an error

Complete asset record submitted; QR Code Generator sandbox endpoint returns HTTP 503.

Agent retries up to three times with exponential backoff; after third failure writes 'QR generation failed' to the record's status field and sends a Slack alert to Operations Coordinator.

Three retry attempts logged; status field updated; Slack alert received; no unhandled exception thrown.

T06

Duplicate asset ID prevention

Two Airtable rows created in rapid succession (within 2 seconds) with identical asset name and serial number.

Each record receives a distinct, sequential asset ID. No collision. Second record is not rejected; both are valid.

Two unique asset IDs present; no ID duplication in the base.

T07

Slack notification delivery failure

Complete asset record created; Slack sandbox workspace returns HTTP 429 (rate limited).

Agent logs the failure, queues the notification, retries after 30 seconds, and sends the message on retry success. If retry fails, writes 'Slack notification pending' to the record.

Message delivered on retry; or status field updated with pending flag if retry also fails.

Maintenance Scheduler Agent — reads maintenance intervals from asset records, creates Google Calendar events, sends Slack reminders, and issues overdue loan alerts.

Scenario

Input

Expected output

Pass criteria

T08

Happy path: maintenance interval set, calendar event created

Asset record confirmed in Airtable with maintenance interval of 90 days and responsible staff assigned.

Google Calendar recurring event created 7 days before the maintenance due date; Slack reminder sent to responsible staff 7 days and 1 day before due date.

Calendar event visible in sandbox Google Calendar; two Slack reminders scheduled and triggered at correct intervals.

T09

Asset loan overdue: Slack alert triggered

Asset record loan return date is set to yesterday; status field still shows 'On loan'.

Overdue Slack alert sent to the borrower; copy sent to Operations Manager.

Two Slack messages received: one to borrower, one to Operations Manager. Messages contain asset ID and overdue date.

T10

Maintenance interval field blank

Asset record confirmed but maintenance interval field is empty.

Agent logs a warning to the automation platform's error log; Slack alert sent to Operations Coordinator to confirm interval; no calendar event created.

No calendar event created; Slack alert received by coordinator; error log entry present.

T11

Maintenance interval updated mid-cycle

Existing asset has a 90-day calendar event; coordinator updates interval to 60 days in Airtable.

Agent cancels the existing calendar event and creates a new one reflecting the 60-day interval.

Old event cancelled; new event created; no duplicate events exist for the asset.

T12

Google Calendar API unavailable

Asset confirmed with valid maintenance interval; Google Workspace sandbox returns HTTP 502.

Agent retries up to three times; after third failure logs the error and sends Slack alert to Operations Coordinator noting calendar event creation failure.

Retry attempts logged; Slack alert received; no unhandled exception; event flagged for manual creation.

Finance Sync Agent — pushes confirmed asset data to Xero as fixed-asset records and handles disposal write-off entries.

Scenario

Input

Expected output

Pass criteria

T13

Happy path: new asset confirmed, Xero fixed-asset record created

Airtable record status set to 'Confirmed'; fields present: asset name, purchase date, cost ($2,400), depreciation method (straight-line).

Xero fixed-asset record created with correct purchase date, cost, and depreciation method. Asset ID cross-referenced in the Xero record name.

Xero demo company shows new fixed-asset entry matching all field values from Airtable. No manual data entry required.

T14

Disposal flag set: write-off record created in Xero

Airtable record disposal flag set to true; asset status updated to 'Disposed'.

Xero write-off entry created for the asset; Airtable record marked inactive; Operations Coordinator notified via Slack.

Xero demo company shows disposal entry; Airtable status is 'Disposed/Inactive'; Slack notification received.

T15

Missing cost field: Xero push blocked

Asset record confirmed but cost field is blank.

Agent blocks the Xero push; flags the record with 'Finance sync pending: missing cost'; Slack alert sent to Finance Officer.

No Xero entry created; Airtable field updated with pending flag; Slack alert received by Finance Officer.

T16

Xero API authentication failure

Asset confirmed with all fields; Xero sandbox OAuth token is expired.

Agent detects 401 response; logs authentication error; sends Slack alert to Operations Manager and Finance Officer with guidance to refresh the Xero connection.

No partial record created in Xero; error logged with HTTP 401 code; Slack alert received by both parties.

Test and QA PlanPage 2 of 4

FS-DOC-06Quality

03Phase 2 — integration and edge case tests

Phase 2 validates that agents hand off data to each other correctly and that the full chain of tool calls behaves as expected when all sandboxes are connected simultaneously. Integration test IDs continue the T sequence from Phase 1.

Scenario

Input

Expected output

Pass criteria

T17

Full intake-to-assignment handoff: Intake Agent to Slack

New complete asset row created in sandbox Airtable.

Asset Intake Agent validates, generates ID, calls QR API, writes URL to record, then triggers Slack assignment notification in sequence with no manual intervention.

All four steps complete in under 90 seconds. Each step's output is present in the record and Slack workspace.

T18

Intake Agent to Maintenance Scheduler Agent handoff

Asset confirmed in Airtable with maintenance interval set.

On record confirmation, Maintenance Scheduler Agent automatically reads the interval and creates the Google Calendar event without a separate trigger.

Calendar event created within 60 seconds of confirmation; event recurrence matches the interval field value.

T19

Maintenance Scheduler Agent overdue alert to Operations Manager

Asset loan return date set to two days ago; record not updated.

Overdue alert Slack message sent to borrower and copied to Operations Manager (Jordan Mercer). Message contains asset name, ID, and number of days overdue.

Both Slack messages received with correct content. Operations Manager copy confirmed in sandbox Slack.

T20

Intake Agent to Finance Sync Agent handoff on confirmation

Asset record status changed to 'Confirmed' after intake.

Finance Sync Agent detects the confirmation trigger and creates the Xero fixed-asset record without a separate manual step.

Xero demo company shows the new entry within 120 seconds of confirmation. Asset ID in Xero record name matches Airtable.

T21

Monthly audit report generation and Slack post

Scheduler trigger fires (simulated) for monthly audit; Airtable sandbox base contains 15 records, two of which have no status update in 45 days.

Automation exports reconciliation summary, flags the two stale records, and posts the report to the operations Slack channel.

Slack message received in the operations channel; report lists all 15 assets; two stale records are clearly flagged.

T22

Disposal flow end to end: Airtable to Xero to Slack

Asset disposal flag set in Airtable sandbox.

Finance Sync Agent creates write-off in Xero; Airtable record marked inactive; Slack notification sent to Operations Coordinator.

All three outputs present within 120 seconds. Xero disposal entry, Airtable status update, and Slack message all confirmed.

T23

Xero unavailable during Finance Sync Agent handoff

Asset confirmed in Airtable; Xero sandbox endpoint returns HTTP 503.

Finance Sync Agent retries three times; queues the sync job; sends Slack alert to Finance Officer noting the sync will retry automatically.

Three retry attempts logged with timestamps; Slack alert received; sync job re-attempted and succeeds when endpoint recovers in the test.

T24

Parallel asset events: two new records created simultaneously

Two asset rows added to Airtable within 3 seconds of each other.

Both records processed independently; each receives a unique asset ID, QR code URL, and Slack notification. No data cross-contamination.

Two distinct asset IDs; two distinct QR URLs; two distinct Slack messages, each referencing only its own asset.

T25

Maintenance reminder Slack message content accuracy

Asset approaching maintenance due date (simulated to tomorrow).

Slack reminder includes: asset name, asset ID, due date, responsible staff name, and a link to the Airtable record.

All five content elements present in the Slack message. Link resolves to the correct Airtable sandbox record.

T26

Airtable webhook reliability: record update does not double-trigger

Asset record updated twice in rapid succession (within 1 second, simulating a save-and-re-save).

Automation de-duplicates the trigger; only one workflow run initiated; one QR code generated; one Slack message sent.

Automation platform execution log shows exactly one run. Single QR URL in record. Single Slack notification.

Edge-case tests below use the E prefix and cover boundary conditions, malformed data, and external dependency failures. These run within Phase 2 after integration cases T17 through T26 have all passed.

Scenario

Input

Expected output

Pass criteria

E01

Duplicate asset: identical serial number already exists in register

New Airtable row submitted with a serial number that matches an existing active record.

Agent detects the duplicate via serial number lookup; flags the new row with status 'Duplicate detected'; sends Slack alert to Operations Coordinator with the conflicting record link. No new asset ID generated.

Status field shows 'Duplicate detected'; no asset ID created for the duplicate; Slack alert received with link to original record.

E02

Missing data: asset name field is blank

Airtable row submitted with all fields except asset name.

Intake Agent flags record 'Incomplete: asset name required'; no downstream steps run; Slack alert sent to coordinator.

Record flagged correctly; no ID, QR code, or Slack assignment generated; coordinator alert received.

E03

Missing data: cost field contains non-numeric text

Asset record submitted with cost field containing the string 'TBC'.

Finance Sync Agent blocks push to Xero; writes 'Finance sync blocked: invalid cost value' to record; Slack alert sent to Finance Officer (Sam Okafor).

No Xero entry created; record flagged; Finance Officer receives Slack alert specifying the field and the invalid value.

E04

QR Code Generator API unavailable for extended period (all retries exhausted)

Complete asset record submitted; QR sandbox endpoint returns 503 across all three retry attempts.

Agent writes 'QR generation failed: manual label required' to the Airtable record; Slack alert sent to Operations Coordinator; all other downstream steps (Slack assignment, calendar, Xero) continue normally.

Asset ID generated; Slack assignment sent; calendar event created; Xero entry created. Only QR URL field shows failure flag. Coordinator alerted.

E05

Human action timeout: coordinator does not confirm QR label printed within 48 hours

QR URL written to record; 48-hour timer elapses with no 'Label printed' checkbox ticked by coordinator.

Automation sends a Slack reminder to Operations Coordinator asking them to confirm label has been attached.

Slack reminder received exactly once after 48 hours. No repeated spam. Reminder includes asset name and ID.

E06

Slack workspace unavailable during assignment notification

Complete asset record processed; Slack sandbox API returns HTTP 503.

Agent retries Slack notification twice; if both fail, writes 'Slack notification failed: manual assignment required' to record and logs the event.

Two retry attempts in log; record updated with failure flag; no unhandled exception. Process continues to calendar and Xero steps.

E07

Google Calendar API returns invalid scope error (403)

Maintenance Scheduler Agent attempts to create calendar event; API returns 403 insufficient scope.

Agent logs the scope error with detail; sends Slack alert to FullSpec team (support@gofullspec.com) and Operations Manager noting that OAuth re-authorisation is required; no calendar event created.

Detailed 403 error in platform log; Slack alert received at support address and by Operations Manager; no silent failure.

E08

Automation platform outage: workflow does not run at trigger time

Airtable record created during a simulated platform downtime window; platform recovers after 20 minutes.

On recovery, the automation platform processes the queued trigger; all agents run in order; outputs match those expected from a normal run.

Platform execution log shows delayed run with original trigger timestamp. All outputs (ID, QR URL, Slack, Calendar, Xero) present and correct after recovery.

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 asset record (for example, a spare laptop or a dummy peripheral with a clearly marked test serial number). Direct the Slack assignment notification to an internal team address, not to an external recipient. After all Phase 3 cases pass, the FullSpec team will void the test asset record in Airtable (set status to 'Test Voided'), reverse the Xero fixed-asset entry in the demo or test Xero period, and remove the test Google Calendar event. Do not use a real asset value above $500 for the production test record to limit any accounting adjustment required.

Phase 3 uses live production credentials and the live Airtable register. The FullSpec team runs each case with the process owner observing. Test IDs continue the T sequence from Phase 2.

Scenario

Production action

Expected output

Pass criteria

T27

Full intake run: new test asset entered in live Airtable base

Operations Coordinator (Priya Nair) creates a new asset row in the live Airtable base with all required fields populated. Asset cost set to $150 for test purposes.

Asset Intake Agent assigns a unique ASSET-YYYY-NNNN ID, calls the live QR Code Generator API and writes the URL to the record, sends a Slack assignment message to the designated internal test address.

All three outputs present in production systems within 90 seconds. QR URL resolves to a scannable label. Slack message received in the test Slack channel.

T28

Maintenance scheduling confirmed in live Google Calendar

Asset record confirmed with a 90-day maintenance interval in the live base.

Maintenance Scheduler Agent creates a recurring Google Calendar event in the live Operations calendar with a 7-day advance Slack reminder configured.

Event visible in the live Operations Google Calendar. Event recurrence is 90 days. Slack reminder scheduled and confirmed in platform execution log.

T29

Overdue loan alert fires in live Slack workspace

Loan return date on the test asset record is set to two days prior (backdated field update by FullSpec team); status remains 'On loan'.

Overdue alert sent to the internal test address and copied to Operations Manager (Jordan Mercer) in the live Slack workspace.

Two Slack messages received in production: one to the test assignee address, one to Jordan Mercer. Both contain asset ID and overdue duration.

T30

Xero fixed-asset entry created in live company

Test asset record status set to 'Confirmed' in the live Airtable base.

Finance Sync Agent creates a fixed-asset record in the live Xero company with purchase date, cost ($150), and straight-line depreciation method. Asset ID appears in the Xero record name.

Live Xero company shows the new fixed-asset entry. Finance Officer (Sam Okafor) confirms the record matches the Airtable field values. Entry is then reversed by the FullSpec team after confirmation.

T31

Process owner review and approval

Operations Manager (Jordan Mercer) reviews all Phase 3 outputs: the Airtable record with ID and QR URL, the Google Calendar event, the Slack messages (assignment, maintenance reminder schedule, overdue alert), and the Xero entry confirmation from Sam Okafor.

Process owner confirms all outputs are correct, complete, and match the expected behaviour documented in this plan. Approval is recorded in the FullSpec confirmation system against this test run.

FullSpec confirmation system updated with process owner approval, approver name (Jordan Mercer), and timestamp. Test asset record voided in Airtable. Xero entry reversed. Calendar event removed. Phase 3 declared complete.

On completion of T31, the FullSpec team issues a QA completion summary to support@gofullspec.com and to the process owner confirming all 31 test cases and 8 edge cases have passed. The automation is then cleared for go-live. Any case that fails in Phase 3 must be remediated and the affected cases re-run before go-live is approved.

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