Back to IT Helpdesk Request Handling

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

IT Helpdesk Request Handling

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

This document defines the structured test and quality assurance programme for the IT Helpdesk Request Handling automation. It is written for the FullSpec engineering team executing the build, with the process owner joining Phase 3 for final acceptance. Testing runs in three sequential phases: unit, integration, and end-to-end production. No phase begins until all cases in the preceding phase carry a passing result. All test outcomes are logged in the FullSpec confirmation record for this project.

01Testing approach

Testing is structured across three phases that must be completed in order. Each phase has a defined scope, environment, credential rule, and pass condition. Phase 1 and Phase 2 are run entirely by the FullSpec team in sandbox environments. Phase 3 moves to the production environment and requires the process owner to participate in the final acceptance case. No phase begins until every test case in the previous phase has a confirmed pass result and any failures have been resolved and re-tested.

1
Phase 1: Unit Testing
Each agent tested in isolation before any handoff is verified
Scope
Each of the three agents tested independently: Triage and Priority Agent, Assignment and Notification Agent, Escalation and Resolution Logger. No cross-agent handoffs tested at this stage.
Environment
Sandbox only. Freshdesk sandbox account, Slack test workspace, PagerDuty sandbox, Notion test database.
Credential rule
No production API keys permitted. All credentials must point to sandbox or test-tier accounts. Credentials stored in the automation platform's environment variable store under the SANDBOX_ prefix.
Pass condition
All cases T01 through T14 return the expected output with no manual intervention. Any failure blocks progression to Phase 2.
Who runs it
FullSpec team only. Process owner is not required for Phase 1.
2
Phase 2: Integration and Edge Case Testing
Agent handoffs and failure-mode scenarios verified end to end in sandbox
Scope
Full agent-to-agent handoff chain. Triage Agent output consumed by Assignment Agent; Assignment Agent output triggering Escalation and Resolution Logger. Separate edge-case table covers duplicate submissions, missing data, tool unavailability, and human timeout.
Environment
Sandbox only. All four tool integrations active simultaneously in the sandbox environment.
Credential rule
Same SANDBOX_ credential set used in Phase 1. No credential changes between Phase 1 and Phase 2.
Pass condition
All integration cases T15 through T22 pass and all edge cases E01 through E07 either resolve correctly or route to the defined fallback path without data loss.
Who runs it
FullSpec team only. Process owner is not required for Phase 2.
3
Phase 3: End-to-End Production Test
Full production run with live credentials; process owner sign-off required
Scope
Complete workflow traced from intake trigger to Notion knowledge base entry using live production credentials. Includes error log verification and process owner acceptance review.
Environment
Production. Live Freshdesk account, live Slack workspace, live PagerDuty account, live Notion workspace. Test records must be voided after each run.
Credential rule
Production API keys loaded under the PROD_ prefix in the automation platform environment store. Sandbox credentials must be disabled before Phase 3 begins.
Pass condition
All cases T23 through T27 pass, including the final process owner review and approval case (T27). Owner sign-off is recorded in the FullSpec confirmation record.
Who runs it
FullSpec team executes T23 through T26. Process owner joins for T27 (acceptance review and sign-off).
Test and QA PlanPage 1 of 4
FS-DOC-06Quality

02Phase 1 — unit test cases

Sandbox credentials only. Do not connect or reference any production API key during Phase 1. All Freshdesk, Slack, PagerDuty, and Notion credentials must point to sandbox or test-tier accounts for every case below. If a sandbox credential is unavailable, halt testing and notify the FullSpec team lead before proceeding.

Agent 1: Triage and Priority Agent

ID
Scenario
Input
Expected Output
Pass Criteria
T01
Happy path: software issue, P2
Request text: 'My laptop cannot connect to the VPN since yesterday. I need it for client calls.' Received via intake form.
Category: Software. Priority: P2. New Freshdesk sandbox ticket created with category and priority pre-filled.
Freshdesk sandbox ticket exists with correct category and P2 flag within 30 seconds of trigger.
T02
Happy path: hardware issue, P1
Request text: 'Server rack in room B3 has gone offline. Multiple users affected.' Received via Slack slash command.
Category: Hardware. Priority: P1. Ticket created with P1 flag.
Freshdesk sandbox ticket has category Hardware and P1 priority. Trigger source recorded as Slack.
T03
Happy path: access request, P3
Request text: 'Please grant me access to the marketing shared drive.' Received via email.
Category: Access Request. Priority: P3. Ticket created.
Freshdesk sandbox ticket has category Access Request and P3 priority.
T04
Happy path: general query, P4
Request text: 'Where do I find the printer drivers for the office printer?' Received via intake form.
Category: General Query. Priority: P4. Ticket created.
Freshdesk sandbox ticket has category General Query and P4 priority.
T05
Failure: empty request body
Intake form submitted with blank description field. Subject line only: 'Help needed'.
Agent flags ticket as incomplete. Priority held at P4. Ticket created with incomplete flag. Requester notified via Slack to resubmit with detail.
Freshdesk sandbox ticket created with incomplete flag. Slack DM sent to requester within 60 seconds. No priority escalation.
T06
Failure: ambiguous category, no keyword match
Request text: 'Things are not working properly.' No further detail.
Agent assigns category: Unclassified. Priority: P4 (default). Ticket created. IT Manager notified for manual review.
Ticket category is Unclassified. P4 assigned. Slack alert sent to IT Manager sandbox user for manual classification.
T07
Failure: Freshdesk API timeout on ticket creation
Valid classified request submitted; Freshdesk sandbox endpoint returns 503.
Automation retries up to three times with 10-second intervals. If all retries fail, error logged and FullSpec alert fired.
Retry logic executes three times. Error event visible in automation platform run log. No duplicate ticket created on recovery.

Agent 2: Assignment and Notification Agent

ID
Scenario
Input
Expected Output
Pass Criteria
T08
Happy path: ticket assigned to least-loaded technician
Freshdesk sandbox ticket created by Triage Agent (P2, Software). Three sandbox technicians present: Tech A has 2 open tickets, Tech B has 5, Tech C has 1.
Ticket assigned to Tech C. Slack message sent to sandbox requester and to Tech C.
Freshdesk ticket assignee is Tech C. Two Slack messages visible in sandbox workspace within 60 seconds.
T09
Happy path: P1 ticket triggers immediate Slack alert
P1 Hardware ticket received from Triage Agent.
Ticket assigned to available technician. Slack alert to technician marked as urgent. Requester notified.
Slack message to technician contains P1 label and ticket link. Requester message contains ticket number and assignee name.
T10
Happy path: requester notification content correct
P3 Access Request ticket assigned to Tech A.
Slack DM to requester contains: ticket number, category (Access Request), priority (P3), assignee name (Tech A).
All four fields present in the Slack DM body. Verified by string match in test log.
T11
Failure: no available technician (all at capacity threshold)
P2 ticket created; all sandbox technicians have 10+ open tickets (capacity threshold set to 10 in config).
Ticket remains unassigned. IT Manager sandbox account receives Slack alert: 'No technician available for ticket #X. Manual assignment required.'
Freshdesk ticket status is Open, unassigned. Slack alert to IT Manager sent within 60 seconds.
T12
Failure: Slack API returns 429 rate-limit error on notification send
Assignment completed in Freshdesk. Slack notification call returns 429.
Automation retries after 60-second backoff. If retry succeeds, message delivered. Delay logged in run log.
Slack message eventually delivered. Run log shows 429 error and retry timestamp. No duplicate messages sent.

Agent 3: Escalation and Resolution Logger

ID
Scenario
Input
Expected Output
Pass Criteria
T13
Happy path: P1 ticket breaches SLA threshold, PagerDuty alert fires
P1 sandbox ticket open for longer than the configured SLA window (4 hours for P1). SLA field in Freshdesk shows breach.
PagerDuty sandbox incident created with ticket ID, elapsed time, and category. IT Manager receives alert.
PagerDuty sandbox incident visible. Incident title contains Freshdesk ticket ID. Alert fires within 5 minutes of SLA breach detection.
T14
Happy path: ticket resolved, Notion knowledge base entry written
Technician marks sandbox Freshdesk ticket as Resolved. Ticket has category Software, resolution notes: 'Reinstalled VPN client, tested connectivity.'
Notion sandbox database receives new page with fields: Category, Ticket ID, Resolution Summary, Fix Steps, Date Resolved.
Notion sandbox page created. All five fields populated. Page title matches Freshdesk ticket ID. Created within 60 seconds of resolution event.
Test and QA PlanPage 2 of 4
FS-DOC-06Quality

03Phase 2 — integration and edge case tests

Phase 2 verifies that agents pass data correctly to one another and that the full sandbox workflow executes without manual intervention. Integration test IDs continue the T sequence from Phase 1. Edge case tests use a separate E sequence.

ID
Scenario
Input
Expected Output
Pass Criteria
T15
Full handoff: Triage Agent to Assignment Agent (P2 Software)
Intake form submission: 'Excel keeps crashing when I open files over 10 MB. Blocking my end-of-month reporting.' Submitted in sandbox.
Triage Agent classifies as Software, P2. Freshdesk ticket created. Assignment Agent picks up ticket, assigns to least-loaded technician, sends both Slack notifications.
Freshdesk sandbox ticket has correct fields. Both Slack messages present. Total elapsed time from trigger to notification under 90 seconds.
T16
Full handoff: Triage Agent to Assignment Agent (P1 Hardware)
Slack slash command: '/itsupport Server down in B3. No one can access shared drives.' Submitted in sandbox.
P1 Hardware ticket created. Assignment Agent assigns immediately. Slack alert to technician flagged urgent. IT Manager notified.
Freshdesk ticket P1. Technician Slack message contains urgent label. IT Manager DM received. All within 60 seconds.
T17
SLA breach handoff: Assignment Agent ticket to Escalation Logger (P1)
P1 ticket in sandbox assigned but not resolved. SLA window (4 hours) manually expired in sandbox environment.
Escalation and Resolution Logger detects breach. PagerDuty sandbox incident fired. Incident linked to Freshdesk ticket ID.
PagerDuty sandbox incident exists. Incident metadata contains correct ticket ID and elapsed time.
T18
Resolution handoff: Freshdesk resolution event to Escalation Logger (Notion write)
Technician resolves P3 Access Request in sandbox Freshdesk. Adds resolution note: 'Granted Marketing Drive access via Google Workspace admin console.'
Notion sandbox page created with all required fields populated from Freshdesk resolution data.
Notion page present. Category: Access Request. Fix Steps field is not empty. Date Resolved matches sandbox resolution timestamp.
T19
P2 ticket breach then resolved: both Escalation Logger actions fire in correct order
P2 ticket breaches SLA. PagerDuty alert fires. Technician then resolves ticket in sandbox.
PagerDuty incident fires first. After resolution, Notion page created. PagerDuty incident updated to resolved state.
Both events logged in automation run history in correct sequence. PagerDuty incident status: Resolved. Notion page present.
T20
Multi-ticket volume: five simultaneous intake submissions
Five intake form submissions sent to sandbox within a 10-second window, each with different categories and priorities.
Five distinct Freshdesk tickets created with correct classifications. Five assignment decisions made independently. Ten Slack messages sent (requester plus technician per ticket).
Exactly five Freshdesk tickets. No duplicate IDs. Ten Slack messages in sandbox workspace. No tickets merged or lost.
T21
P4 ticket does not trigger PagerDuty escalation
P4 General Query ticket open in sandbox beyond P4 SLA window (48 hours, manually expired).
No PagerDuty incident created. No IT Manager alert. Ticket remains open.
PagerDuty sandbox shows zero new incidents. Escalation Logger run log confirms P4 exclusion rule applied.
T22
Notion write failure gracefully handled without blocking Freshdesk state
P3 ticket resolved in sandbox. Notion API returns 500 on write attempt.
Automation retries Notion write twice. If all attempts fail, error logged and Slack alert sent to IT Manager. Freshdesk ticket status remains Resolved.
Freshdesk ticket is Resolved regardless of Notion outcome. Slack error alert sent to IT Manager sandbox user. Run log shows retry attempts.

Edge case tests

ID
Scenario
Input
Expected Output
Pass Criteria
E01
Duplicate submission: same request sent twice within 60 seconds
Identical intake form submitted twice by the same requester within 60 seconds (same email, same subject, same body).
Automation detects duplicate via requester email and request hash. Second submission suppressed. Requester receives Slack message: 'Your ticket #X is already logged.'
Only one Freshdesk ticket created. Requester receives deduplication message. Run log shows duplicate suppression event.
E02
Missing requester email in intake submission
Intake form submitted without an email address in the requester field. Slack submission source.
Triage Agent creates ticket using Slack user ID as requester identifier. Priority and category assigned normally. Slack DM sent to Slack user ID.
Freshdesk ticket has Slack user ID in requester field. Slack notification delivered. No hard failure or dropped ticket.
E03
Freshdesk sandbox completely unavailable (connection refused)
Triage Agent attempts to create ticket. Freshdesk returns connection refused.
Automation halts after three retries. Incoming request payload stored in automation platform error queue. FullSpec alert fired to support@gofullspec.com. Requester notified: 'We received your request and are processing it shortly.'
Error queue contains original payload. No data lost. FullSpec alert email received. Requester Slack message sent.
E04
PagerDuty sandbox unavailable during SLA breach event
SLA breach detected for P1 ticket. PagerDuty API returns 503.
Automation retries three times. On final failure, Slack direct message sent to IT Manager as fallback escalation channel. Error logged.
IT Manager receives Slack escalation DM. Run log shows PagerDuty failure and fallback trigger. No silent failure.
E05
Request submitted in a language other than English
Intake form submitted with body entirely in Spanish: 'Mi computadora no enciende. Necesito ayuda urgente.'
Triage Agent assigns category: Hardware (keyword 'computadora' matches hardware dictionary). Priority: P2 (urgency signal detected). Ticket created. Notion knowledge base entry language recorded as non-English.
Freshdesk ticket has Hardware category and P2 priority. Resolution Logger records language flag in Notion page metadata.
E06
Human technician does not resolve ticket within extended SLA window (P2, 8 hours)
P2 ticket assigned. Technician takes no action for 8 hours (manually expired in sandbox).
First PagerDuty alert fires at 4-hour mark. Second escalation Slack message sent to IT Manager at 8-hour mark with elapsed time and ticket link.
Two distinct escalation events in run log. PagerDuty incident exists. IT Manager receives second Slack message at 8-hour timestamp.
E07
Notion database schema mismatch: required field renamed by user
Resolution Logger attempts to write to Notion. The 'Fix Steps' property has been renamed to 'Resolution Steps' in the live database by a team member.
Automation catches property-not-found error. Slack alert sent to IT Manager with field mismatch detail. Freshdesk ticket remains Resolved. Partial Notion page not created.
No corrupted Notion page created. IT Manager Slack alert contains specific field name that caused failure. Run log records schema mismatch error.
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 (such as it-test@[YourCompany.com]) as the requester for all production test submissions. Do not use a real employee request or a real ticket category that would trigger live escalations unless intentional. Every Freshdesk ticket, PagerDuty incident, and Notion page created during Phase 3 testing must be voided and deleted from production records after each test run is complete. Confirm with the IT Manager that PagerDuty on-call schedules are suppressed or set to the test contact for the duration of Phase 3.

Phase 3 runs against live production credentials and live tool accounts. The FullSpec team executes cases T23 through T26 and invites the process owner to observe the final run before T27. The process owner's review and approval in T27 constitutes formal acceptance. That approval is recorded in the FullSpec project confirmation and no separate signature document is required.

ID
Scenario
Input
Expected Output
Pass Criteria
T23
Full production run: P2 Software ticket traced end to end
Test email sent from it-test@[YourCompany.com] to the production intake address: 'The accounting software keeps timing out when generating month-end reports. Blocking finance team.' Received via Google Workspace intake.
Triage Agent: category Software, P2. Freshdesk production ticket created with all fields. Assignment Agent: ticket assigned to the least-loaded technician. Requester Slack DM sent with ticket number, category, priority, and assignee. Technician Slack alert sent with ticket summary and Freshdesk link. Technician resolves ticket. Notion production page created with category, fix steps, and resolution summary.
All eight automated steps execute without error. Freshdesk ticket ID traceable through run log from trigger to Notion write. Total elapsed time from intake to requester notification under 120 seconds. Notion page present with all required fields. Test ticket deleted from Freshdesk and Notion after verification.
T24
Production P1 SLA escalation verified end to end
Test Freshdesk P1 ticket created via intake (subject: 'PRODUCTION TEST: P1 escalation check'). SLA breach window manually triggered in Freshdesk using the SLA policy override for test purposes.
PagerDuty production incident created. IT Manager receives live PagerDuty alert. Incident details contain Freshdesk ticket ID and elapsed time.
PagerDuty incident exists in production account. Alert received by the designated test on-call contact. Incident resolved and deleted from PagerDuty after verification. Freshdesk test ticket deleted.
T25
Production error log verification
Review automation platform run logs for the T23 and T24 production runs.
Run logs show: trigger timestamp, agent execution steps in correct order, API response codes (200 or 201 for all successful calls), and no unhandled exceptions.
All API calls return 2xx status codes in run log. No error events present. Log entries correspond to correct ticket IDs. FullSpec team confirms log integrity before proceeding to T26.
T26
Production Notion knowledge base entry quality check
Notion page created during T23 reviewed against the required schema.
Notion page contains: Category (Software), Ticket ID (matching Freshdesk ID from T23), Resolution Summary (non-empty), Fix Steps (non-empty), Date Resolved (matching Freshdesk resolution timestamp).
All five fields populated and accurate. No field is blank or contains placeholder text. FullSpec team screenshots the Notion page before deleting it for the test record.
T27
Process owner review and acceptance: final sign-off
Process owner (IT Manager) is walked through the complete Phase 3 run log and the captured outputs from T23 through T26 by the FullSpec team. Owner reviews: the Freshdesk ticket creation and assignment, both Slack notification examples, the PagerDuty escalation alert from T24, and the Notion knowledge base entry screenshot from T26.
Process owner confirms that all outputs match expected operational behaviour. Owner approves the automation as ready for go-live. Approval is recorded in the FullSpec project confirmation record with the owner's name, role, and date.
Process owner verbally or in writing confirms acceptance of all Phase 3 outputs. FullSpec logs the confirmation with owner name, role (IT Manager), and timestamp. No unresolved queries remain. Go-live is cleared. No separate signature block is required.
After T27 is recorded, the FullSpec team will send a go-live clearance confirmation to the process owner and to support@gofullspec.com. Any post-go-live issues during the first two weeks should be reported to support@gofullspec.com with the Freshdesk ticket ID and the automation run log reference.
Test and QA PlanPage 4 of 4

More documents for this process

Every document generated for IT Helpdesk Request Handling.

Launch Plan
Operations · Owner
View
ROI and Business Case
Finance · Owner
View
Process Runbook / SOP
Operations · Owner
View
Developer Handover Pack
Technical · Developer
View
Integration and API Spec
Technical · Developer
View