FS-DOC-06Quality
Test and QA Plan
Device and Hardware Management
[YourCompany.com] · IT Department · Prepared by FullSpec · [Today's Date]
This document defines the full quality assurance process for the Device and Hardware Management automation, covering all three agents: the Asset Register Agent, the Device Lifecycle Comms Agent, and the MDM Sync Agent. Testing runs in three sequential phases. No phase begins until every test case in the previous phase has fully passed. The FullSpec team executes Phases 1 and 2 entirely in sandbox environments. Your team joins in Phase 3, where a controlled production run is conducted and the process owner records formal approval in the FullSpec confirmation system. Use this document alongside the Developer Handover Pack and Integration and API Spec.
01Testing approach
Testing is structured across three sequential phases: Unit, Integration, and End-to-end. Each phase must fully pass before the next begins. A single failing test case blocks progression. The FullSpec team owns Phases 1 and 2 in their entirety and leads Phase 3 execution, with the process owner joining to validate real-world outputs and record final approval.
1Phase 1: Unit Testing
Estimated time: 1 to 2 business days
Scope
Each agent is tested in isolation: trigger parsing, tool queries, record writes, API calls, and outbound messages are verified independently before any agent-to-agent handoff is tested.
Environment
Sandbox only. Airtable sandbox base, Jira sandbox project, Jamf sandbox environment, Gmail test account, Slack test workspace.
Credential rule
No production credentials may be used. All API keys, OAuth tokens, and webhook secrets must be sandbox-scoped. Production Jamf API roles must not be activated during this phase.
Pass condition
All test cases T01 through T15 return the expected output with no unhandled errors. Any failure halts the phase until resolved and re-tested.
Who runs it
FullSpec team only.
2Phase 2: Integration and Edge Case Testing
Estimated time: 1 to 2 business days
Scope
Agent-to-agent handoffs are tested end-to-end within the sandbox, verifying that outputs from one agent correctly trigger the next. Separate edge-case scenarios cover duplicates, missing data, tool unavailability, and human timeout paths.
Environment
Sandbox only. Same environment as Phase 1, with simulated error states injected for edge cases.
Credential rule
Sandbox credentials only. No production systems are touched. Injected failure states are simulated at the orchestration layer, not by disabling live services.
Pass condition
All integration test cases T16 through T22 and all edge-case tests E01 through E07 pass. Every edge case must route to the correct fallback or alert without crashing the workflow.
Who runs it
FullSpec team only.
3Phase 3: End-to-End Production Test
Estimated time: 1 business day
Scope
A complete, live run through all three agents using production credentials and real tool connections. Covers a new hire assignment event, a return and wipe event, and a procurement alert trigger.
Environment
Production. All credentials switched to live scopes under controlled conditions. Test records are voided after each run.
Credential rule
Production credentials are active. The FullSpec team enables them for this phase only, with the process owner present. Credentials are rotated after the test run if the build uses shared secrets.
Pass condition
All final test cases T23 through T27 pass, including T27 (process owner review and approval). Approval is recorded in the FullSpec confirmation system. No separate sign-off block is required.
Who runs it
FullSpec team executes. Process owner joins to observe and approve at T27.
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 use production Airtable bases, live Jamf API roles, real Gmail accounts, or the live Jira project during this phase. Every record written during testing must go to a clearly labelled sandbox environment. Any test that accidentally touches a production system must be halted immediately and reported to the FullSpec team lead.
Asset Register Agent — unit tests
ID
Scenario
Input
Expected output
Pass criteria
T01
Happy path: new hire event triggers Airtable query
Jira webhook payload: event_type=new_hire, role=engineer, spec=MacBook Pro 14
Automation queries Airtable asset register for unassigned MacBook Pro 14; returns matching device record with serial number
Airtable query returns exactly one available record; no error thrown; query completes in under 3 seconds
T02
Happy path: assignment record written to Airtable
Available device record from T01; assignee name, email, and start date from trigger payload
Airtable record updated with assigned_to, assignment_date, expected_return_date, and status='Assigned'
All four fields written correctly; timestamp recorded; record status changes from 'Available' to 'Assigned'
T03
Happy path: Jira ticket updated after assignment
Assignment record from T02; existing Jira ticket ID from trigger payload
Jira ticket status updated to 'In Progress'; assignment details written to ticket description field
Jira API returns 200; ticket status and description match the assignment data; no duplicate ticket created
T04
Failure: no matching device found in Airtable
Jira webhook payload for new hire; Airtable register contains no unassigned device matching the requested spec
Flow branches to procurement alert path; no assignment record is written
Procurement alert flag set to true; Airtable not updated with an assignment; workflow continues without error
T05
Failure: Airtable API returns a 429 rate-limit error
Simultaneous triggers for three new hire events
Automation retries the Airtable query with exponential back-off (3 attempts, 5s and 15s delays); alert raised if all retries fail
At least one retry succeeds within the retry window; if all retries fail, an error log entry is created and a Slack alert is sent to the IT channel
T06
Failure: offboarding event with no matching Airtable record
Jira webhook payload: event_type=offboarding, assignee_email=unknown@test.com; no record found in Airtable
Workflow flags the gap; creates a Jira comment noting 'No asset record found for this user'; does not crash
Jira comment written; no unhandled exception; Slack alert sent to IT channel with the unknown assignee email
Device Lifecycle Comms Agent — unit tests
ID
Scenario
Input
Expected output
Pass criteria
T07
Happy path: assignment confirmation email sent via Gmail
Completed Airtable assignment record with assignee name, email, device serial, and return date
Gmail sends a templated assignment confirmation email to the assignee; email contains device serial number, acceptable-use policy link, and expected return date
Gmail API returns 200; email appears in the sandbox inbox within 60 seconds; all dynamic fields populated correctly; no raw placeholder text visible
T08
Happy path: procurement alert posted to Slack
Procurement flag set to true by Asset Register Agent; device spec and requester details from trigger payload
Slack message posted to the IT channel with the requested spec, requester name, and a prompt for the IT manager to approve or source a device
Slack API returns 200; message appears in the correct sandbox channel; message content matches the spec from the payload
T09
Happy path: overdue return reminder email sent
Scheduled trigger fires on a record where expected_return_date is today and status is still 'Assigned'
Gmail sends an overdue return reminder to the assigned employee; Slack alert sent to IT channel with employee name and device details
Both Gmail and Slack messages sent within 2 minutes of trigger; email addressed to correct employee; Airtable log timestamp updated
T10
Happy path: quarterly audit request email sent to all assigned staff
Scheduled quarterly audit trigger fires; Airtable returns 15 records with status='Assigned'
Gmail sends 15 individual audit request emails, each addressed to the correct assignee with their specific device serial number
All 15 emails sent; no cross-contamination of recipient data; each email contains the correct serial number for that recipient
T11
Failure: Gmail OAuth token expired
Assignment confirmation email triggered; Gmail OAuth access token has expired
Automation attempts a token refresh using the stored refresh token; if refresh fails, error is logged and Slack alert is sent to IT channel
Token refresh succeeds in the happy-path variant; in the forced-failure variant, error log entry created and Slack alert sent within 30 seconds
T12
Failure: assignee email address missing from Airtable record
Assignment record written without an email address in the assignee_email field
Comms Agent skips the Gmail send; writes a flag to the Airtable record (email_send_failed=true); sends Slack alert to IT channel
No Gmail send attempted; Airtable record updated with failure flag; Slack alert includes the device serial number and the affected record ID
MDM Sync Agent — unit tests
ID
Scenario
Input
Expected output
Pass criteria
T13
Happy path: Jamf enrollment verified for new assignment
Device serial number from Airtable assignment record; Jamf sandbox environment with the device pre-enrolled
Jamf API call GET /api/v1/computers-preview returns enrollment status=enrolled; correct policy profile confirmed; Airtable record updated with jamf_status='Enrolled'
Jamf API returns 200 with enrolled status; Airtable field jamf_status updated within 10 seconds; no manual IT flag raised
T14
Happy path: remote wipe triggered on returned device
Return event written to Airtable with status='Returned'; device serial number present; Jamf sandbox device record active
Jamf API call POST /api/v1/mdm/commands issues an EraseDevice command; Airtable record updated with jamf_status='Wipe Pending'
Jamf API returns 200 for the wipe command; Airtable status updated to 'Wipe Pending'; Slack notification sent to IT channel confirming wipe initiated
T15
Failure: device not found in Jamf during assignment
Device serial number from Airtable that does not exist in the Jamf sandbox
MDM Sync Agent logs the enrollment gap; Airtable record updated with jamf_status='Enrollment Error'; Slack alert sent to IT coordinator for manual action
Jamf API returns 404; Airtable record updated with 'Enrollment Error'; Slack alert sent within 30 seconds; workflow does not crash
Test and QA PlanPage 2 of 4
FS-DOC-06Quality
03Phase 2 — integration and edge case tests
Phase 2 verifies that the three agents work correctly in sequence and that the orchestration layer routes data accurately between them. Integration tests use the same sandbox environments as Phase 1. Edge-case tests inject abnormal conditions to confirm that the automation degrades gracefully and always produces a recoverable state.
Integration tests: agent handoffs
ID
Scenario
Input
Expected output
Pass criteria
T16
Full assignment handoff: Asset Register Agent to MDM Sync Agent to Comms Agent
New hire Jira webhook fires; available device exists in Airtable; device is enrolled in Jamf sandbox
Asset Register Agent writes assignment record; MDM Sync Agent confirms Jamf enrollment; Comms Agent sends Gmail confirmation and Slack summary; Jira ticket updated
All four tool writes and two sends complete in sequence; Airtable record shows status='Assigned' and jamf_status='Enrolled'; Gmail and Slack messages received in sandbox; Jira ticket updated; total flow completes in under 90 seconds
T17
Return and wipe handoff: offboarding event through all three agents
Offboarding Jira webhook fires; Airtable record shows device assigned to the departing employee; Jamf sandbox device is enrolled
Asset Register Agent updates record to status='Return Pending'; MDM Sync Agent triggers wipe command; Comms Agent sends return confirmation to employee and Slack alert to IT channel
Airtable status transitions correctly through 'Return Pending' to 'Wipe Pending'; wipe command issued in Jamf; Gmail and Slack sent; Jira ticket updated with return event
T18
Procurement path handoff: no device available, alert sent to IT manager
New hire webhook fires; Airtable register contains no available devices matching the spec
Asset Register Agent sets procurement flag; Comms Agent posts Slack procurement alert to IT channel with spec details; no assignment record written; Jira ticket updated with 'Awaiting Procurement' status
Procurement alert received in Slack sandbox channel within 60 seconds; no erroneous assignment written to Airtable; Jira ticket status is 'Awaiting Procurement'
T19
Quarterly audit flow: scheduled trigger through Comms Agent
Scheduled quarterly audit trigger fires; Airtable returns 10 records with status='Assigned'
Comms Agent sends 10 individual Gmail audit request emails; each email contains the correct device serial; Airtable audit_last_sent timestamp updated on all 10 records
All 10 emails delivered to sandbox inboxes; serial numbers match Airtable records; timestamps updated; no duplicates sent
T20
Post-wipe re-enrollment and status update in Airtable
Jamf sandbox confirms wipe complete via webhook callback; device serial matches an Airtable record in 'Wipe Pending' state
MDM Sync Agent receives the wipe-complete callback; updates Airtable record to status='Available' and jamf_status='Ready for Enrollment'; Slack notification sent to IT channel
Airtable record status and jamf_status both updated correctly; Slack notification received; record is now queryable as available for a future assignment
T21
Jira ticket created for event originating outside Jira (HR webhook only)
HR system webhook fires with new hire data; no existing Jira ticket ID in the payload
Asset Register Agent creates a new Jira ticket in the IT service project; ticket contains assignee name, requested device spec, and a link to the Airtable record
New Jira ticket created with correct fields; ticket ID written back to Airtable record for future reference; no duplicate ticket created on re-run
T22
End-of-life flag written to Airtable on device age threshold
Scheduled trigger checks Airtable for devices where purchase_date is more than 1,095 days ago (3 years) and status is 'Available'
Asset Register Agent updates matching records with status='End of Life'; Comms Agent posts a Slack alert to the IT channel listing the flagged device serials
All records meeting the age threshold updated correctly; Slack alert lists correct serial numbers; no active assignments flagged incorrectly
Edge-case tests
ID
Scenario
Input
Expected output
Pass criteria
E01
Duplicate new hire webhook received for the same employee within 60 seconds
Two identical Jira webhooks fire for the same hire event (simulating a retry from the HR system)
Idempotency check detects the duplicate; second run skipped; no second Airtable record or Jira ticket created; deduplication log entry written
Only one Airtable record and one Jira ticket exist after both webhooks are processed; deduplication log entry present; no error thrown
E02
Airtable record missing the device serial number field
Assignment trigger fires; the matched Airtable device record has an empty serial_number field
Workflow halts the assignment; writes a validation error to the Airtable record; sends Slack alert to IT channel requesting the serial number be added manually
No assignment written without a serial number; Slack alert sent within 30 seconds; Airtable record flagged with validation_error=true
E03
Jamf API unavailable (simulated 503 response)
MDM Sync Agent attempts to verify Jamf enrollment; Jamf API returns 503 for all retry attempts
MDM Sync Agent retries 3 times with back-off; after all retries fail, Airtable record is updated with jamf_status='MDM Check Failed'; Slack alert sent to IT coordinator
Retry logic fires exactly 3 times; final failure recorded in Airtable and Slack; workflow does not crash; the Comms Agent does not send a confirmation email while the MDM status is unresolved
E04
Slack API unavailable during a procurement alert
Procurement flag set; Slack API returns 503
Automation retries Slack send twice; if all attempts fail, the procurement alert content is written as a comment on the Jira ticket as a fallback channel
Jira comment created with the full procurement alert text; Slack retry attempts logged; workflow continues without crashing
E05
Employee does not respond to quarterly audit email within 5 business days
Audit request email sent at T+0; no response detected in the Gmail sandbox after 5 business days (simulated via timestamp manipulation)
Comms Agent sends a single follow-up reminder email to the employee; Slack alert sent to IT coordinator noting the non-response; Airtable audit_status updated to 'Reminder Sent'
Follow-up email sent to the correct sandbox address; Slack alert received; Airtable field updated; no more than one follow-up sent per audit cycle
E06
Offboarding event fired for an employee with no device assigned in Airtable
Offboarding Jira webhook fires; Airtable query returns no assigned device for the departing employee
Workflow logs the event; creates a Jira comment noting no device record found; sends Slack alert to IT coordinator to confirm manually; does not attempt a wipe
No wipe command issued; Jira comment written; Slack alert sent; no unhandled exception thrown
E07
Physical handover confirmation not received within the expected window (human timeout)
Assignment record written; Slack prompt sent to IT coordinator to confirm physical handover; no confirmation received within 24 hours
Comms Agent sends a follow-up Slack message to the IT channel; Airtable record flagged with handover_confirmed=false and a warning note
Follow-up Slack message sent at the 24-hour mark; Airtable record updated with the flag and note; process does not auto-close or mark the device as confirmed without human input
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 IT test address (such as it-test@[YourCompany.com]) as the assignee for all production test runs. Do not use a real employee as the test subject. Every Airtable record, Jira ticket, Gmail message, and Jamf command created during Phase 3 must be clearly labelled as a test record and voided (deleted or status-set to 'Test Void') immediately after the process owner has confirmed the run. Any Jamf wipe command issued during Phase 3 must target a designated test device only. The FullSpec team will confirm the test device serial number with the IT coordinator before this phase begins. Production credentials are active during this phase: treat all actions as real.
ID
Scenario
Input
Expected output
Pass criteria
T23
Full production run: new hire device assignment traced end to end
Live Jira webhook fired with the test employee (it-test@[YourCompany.com]) as the new hire; production Airtable base contains a designated test device record marked as available
Asset Register Agent queries production Airtable, writes the assignment record; MDM Sync Agent calls production Jamf API and confirms enrollment; Comms Agent sends Gmail confirmation to the test address and posts Slack summary to the IT channel; Jira ticket updated in the live project
All five tool interactions completed and logged; Airtable record shows status='Assigned' and jamf_status='Enrolled'; Gmail received at it-test inbox; Slack message visible in the IT channel; Jira ticket updated; total elapsed time under 120 seconds
T24
Full production run: offboarding return and wipe traced end to end
Live Jira offboarding webhook fired for the test employee; Airtable record shows test device assigned; production Jamf shows test device enrolled
Asset Register Agent updates record to 'Return Pending'; MDM Sync Agent issues EraseDevice command to Jamf for the test device; Comms Agent sends return confirmation email to test address and Slack alert to IT channel; Jira ticket updated with return event
Airtable status transitions correctly; Jamf EraseDevice command issued and confirmed in Jamf audit log; Gmail and Slack both received; Jira ticket updated; test device wipe confirmed in Jamf console before proceeding
T25
Production procurement alert: no device available for a new hire
Live Jira webhook for a new hire; production Airtable contains no available test device matching the requested spec (achieved by temporarily marking the test device as assigned)
Asset Register Agent sets procurement flag; Comms Agent posts Slack procurement alert to IT channel with spec and requester details; no assignment record written; Jira ticket updated with 'Awaiting Procurement'
Slack alert received in production IT channel within 60 seconds; no erroneous assignment written to Airtable; Jira ticket status correct; IT manager can action the alert from Slack
T26
Error log verification: forced Jamf failure in production
MDM Sync Agent triggered with a deliberately invalid device serial number (not present in production Jamf)
Jamf API returns 404; Airtable record updated with jamf_status='Enrollment Error'; Slack alert sent to IT coordinator; error entry written to the automation platform run log
Automation run log contains the error entry with a timestamp, the serial number attempted, and the Jamf 404 response code; Airtable and Slack updated correctly; no silent failure
T27
Process owner review and approval of Phase 3 results
The process owner (IT Manager or delegated IT Coordinator) reviews all Phase 3 test run outputs: Airtable records, Gmail messages, Slack messages, Jira tickets, Jamf audit log, and the automation platform run log
Process owner confirms that all five test cases (T23 through T27) passed as expected, that the automation platform run log is complete and accurate, and that all test records have been voided
Process owner records formal approval in the FullSpec confirmation system. Approval is timestamped and linked to this document version. All test records confirmed voided before approval is submitted. This approval gates go-live and replaces any separate sign-off block.
After T27 approval is recorded in the FullSpec confirmation system, the FullSpec team will schedule the monitored go-live window with the IT coordinator. The two-week monitored run begins at that point. Any issues raised during the monitored run are handled by the FullSpec team under the build warranty. Contact the FullSpec team at support@gofullspec.com with your confirmation reference number.
Test and QA PlanPage 4 of 4