FS-DOC-06Quality
Test and QA Plan
Password Reset & Access Requests
[YourCompany.com] · IT Department · Prepared by FullSpec · [Today's Date]
This document defines the full test and quality-assurance programme for the Password Reset and Access Requests automation. It covers every test case across three sequential phases: unit testing of each agent in isolation, integration and edge-case testing across agent handoffs, and a final end-to-end run in the production environment. The FullSpec team runs all phases; your IT process owner joins Phase 3 to review results and record approval. No phase begins until the previous phase achieves a full pass on every test case in scope.
01Testing approach
Testing runs in three sequential phases. Each phase must reach a complete pass before the next phase opens. Phase 1 validates each agent independently against sandbox data. Phase 2 verifies that agents hand off correctly to one another and that the system behaves safely under abnormal inputs. Phase 3 confirms end-to-end behaviour in the live production environment using a controlled test record.
1Phase 1: Unit Testing
Estimated time: 1 business day
Scope
Each agent tested independently: Request Intake Agent, Verification and Approval Agent, Provisioning and Audit Agent.
Environment
Sandbox only. No production credentials loaded. Okta developer sandbox, Jira sandbox project, Slack test workspace, Google Workspace test domain.
Credential rule
All service account tokens must point to sandbox endpoints. Production API keys must not be present in the automation platform environment during Phase 1.
Pass condition
All cases T01 through T15 return the defined expected output with no manual intervention. Zero unhandled exceptions.
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 across the full workflow, plus all identified edge cases: duplicates, missing data, tool unavailability, and manager non-response timeout.
Environment
Sandbox only. Agent chain tested end-to-end against sandbox endpoints before any production credentials are introduced.
Credential rule
Same sandbox credential rule as Phase 1. No production keys present.
Pass condition
All cases T16 through T23 and E01 through E06 resolve within the defined expected output. Escalation routing delivers correctly to the IT queue in all denial and failure scenarios.
Who runs it
FullSpec team only.
3Phase 3: End-to-End Production Test
Estimated time: 1 business day
Scope
Full production workflow from Slack command or web form submission through to Jira ticket closure with audit log. Covers both the password reset path and the new access path.
Environment
Production. Live Okta tenant, production Jira project, live Slack workspace, production Google Workspace Admin. Test records voided after each run.
Credential rule
Production service account credentials active. Rotate any sandbox tokens out before Phase 3 begins. Confirm scopes match those in the Integration and API Spec.
Pass condition
All cases T24 through T28 pass, including the process owner review case (T28). FullSpec confirms sign-off in writing via support@gofullspec.com.
Who runs it
FullSpec team executes; process owner (IT Support Lead) joins to review results and record approval in T28.
Test and QA PlanPage 1 of 4
FS-DOC-06Quality
02Phase 1 — unit test cases
Sandbox credentials only. Before running any case in this phase, confirm that all service account tokens point to sandbox endpoints: Okta developer sandbox, Jira sandbox project (key: ITSAND), Slack test workspace, and Google Workspace test domain. Do not load production API keys into the automation platform environment until Phase 3.
Request Intake Agent — receives the Slack command or web form payload, classifies the request type, extracts key fields, and creates the Jira ticket. Build time: approximately 8 hours. Complexity: Moderate.
ID
Scenario
Input
Expected Output
Pass Criteria
T01
Happy path: password reset via Slack command
/it-request reset password — submitted by sandbox user alice@test.internal
Jira ticket created in ITSAND with type=password_reset, requester=alice@test.internal, timestamp populated
Ticket appears in Jira within 10 seconds; all fields populated; no manual step triggered
T02
Happy path: new access request via web form
Form payload: requester=bob@test.internal, system=Google Workspace, manager=carol@test.internal
Jira ticket created with type=new_access, system=Google Workspace, manager_email=carol@test.internal
Ticket created; classification set to new_access; manager field not blank
T03
Request classification: ambiguous free-text input
Slack message: 'I can't get in' with no system specified
Ticket created with type=unknown; Slack reply sent to requester asking for clarification; no provisioning triggered
Workflow pauses at intake; no downstream agent called; clarification message delivered
T04
Missing requester identity in form payload
Form payload with requester_email field blank
Intake agent rejects payload; error logged to automation platform; Slack alert sent to IT escalation channel
No Jira ticket created; error entry visible in run log; Slack alert delivered
T05
Jira API unreachable during ticket creation
Valid Slack command submitted; Jira sandbox endpoint returning 503
Intake agent retries twice with 30-second backoff; after second failure, error flagged to IT escalation channel; no duplicate tickets on recovery
Two retry attempts logged; Slack escalation message sent; no ticket created during outage
Verification and Approval Agent — handles Okta identity challenge for password resets and routes new access requests to the correct manager via Slack for one-click approval. Build time: approximately 10 hours. Complexity: Moderate.
ID
Scenario
Input
Expected Output
Pass Criteria
T06
Happy path: Okta identity challenge sent for password reset
Jira ticket with type=password_reset, requester=alice@test.internal
Okta sandbox pushes MFA challenge to alice's registered device; challenge_id logged to Jira ticket
Okta API call returns 200; challenge_id stored on ticket; no manual step required
T07
Identity challenge passed by requester
Okta webhook: challenge_status=verified for challenge_id matching open ticket
Verification flag set on Jira ticket; Provisioning and Audit Agent trigger fired
Jira ticket field verified=true updated; downstream trigger confirmed in run log
T08
Identity challenge failed — requester cannot verify
Okta webhook: challenge_status=failed after three attempts
Ticket status set to escalation_required; Slack message sent to IT escalation channel with ticket link; no provisioning triggered
No Okta reset performed; IT escalation Slack message delivered; ticket status correct
T09
Happy path: manager approval Slack message sent for new access
Jira ticket with type=new_access, manager_email=carol@test.internal
Structured Slack DM sent to carol@test.internal with requester name, system requested, and Approve/Deny buttons; approval_request_id stored on ticket
Slack message delivered to manager sandbox account; buttons rendered; approval_request_id on ticket
T10
Manager clicks Approve within the response window
Slack interaction payload: action=approve, approval_request_id matching open ticket
Ticket status set to approved; manager name and timestamp logged to Jira; Provisioning Agent trigger fired
Approval recorded on ticket; downstream trigger confirmed; no duplicate trigger
T11
Manager clicks Deny
Slack interaction payload: action=deny, approval_request_id matching open ticket
Ticket status set to denied; Slack message sent to requester informing them of the denial; ticket routed to IT escalation queue
No provisioning triggered; requester notified; IT escalation queue entry created
T12
No manager response after 2-hour reminder window
No Slack interaction received within 120 minutes of approval message send
Automated Slack reminder sent to manager; second 2-hour window opens; if still no response, ticket escalates to IT queue
Reminder message sent at correct interval; escalation fires only after second timeout; run log shows both reminder events
T13
Manager Slack account not found in directory
manager_email in Jira ticket resolves to no active Slack user in sandbox workspace
Error logged; IT escalation channel alerted with ticket ID and missing manager detail; no approval message sent
No Slack message attempted; IT alert delivered; ticket flagged for manual resolution
Provisioning and Audit Agent — executes the access change in Okta and Google Workspace, notifies the requester via Slack, and closes the Jira ticket with a full audit log entry. Build time: approximately 10 hours. Complexity: Moderate.
ID
Scenario
Input
Expected Output
Pass Criteria
T14
Happy path: password reset executed in Okta
Jira ticket with type=password_reset, verified=true
Okta API call resets user password; temporary password or reset link generated; Slack confirmation sent to requester; Jira ticket closed with audit note
Okta API returns 200; Slack message delivered; Jira ticket status=Done; audit note contains action, timestamp, and agent ID
T15
Happy path: new access provisioned across Okta and Google Workspace
Jira ticket with type=new_access, approved=true, system=Google Workspace, group=marketing-team
Okta role assigned; Google Workspace Admin API adds user to group marketing-team; Slack confirmation sent; Jira ticket closed with audit note referencing both API calls
Both API calls return 200; user visible in Google group within sandbox; Slack message delivered; audit note contains Okta and Google Workspace action records
Test and QA PlanPage 2 of 4
FS-DOC-06Quality
03Phase 2 — integration and edge case tests
Integration tests validate that data passes correctly between agents at each handoff point. All cases below use the sandbox environment with the same credential rules as Phase 1. IDs continue the sequence from Phase 1.
ID
Scenario
Input
Expected Output
Pass Criteria
T16
End-to-end handoff: Intake to Verification (password reset path)
Slack /it-request reset password from sandbox user; Jira ticket created by Intake Agent
Verification Agent picks up ticket within 15 seconds of creation; Okta challenge fires; challenge_id written back to ticket
No manual trigger needed between agents; run log shows unbroken handoff; challenge_id on ticket
T17
End-to-end handoff: Intake to Verification (new access path)
Web form payload with system=Google Workspace; Jira ticket created
Verification Agent detects type=new_access; sends manager approval Slack message within 15 seconds of ticket creation
Manager Slack message delivered; approval_request_id stored on ticket; run log shows clean handoff
T18
End-to-end handoff: Verification to Provisioning (reset approved)
Okta webhook: challenge_status=verified on open ticket
Provisioning Agent fires within 10 seconds of webhook receipt; Okta reset executed; Jira ticket closed
Provisioning executes without manual step; ticket closed; audit note present
T19
End-to-end handoff: Verification to Provisioning (new access approved)
Slack interaction payload: action=approve from manager
Provisioning Agent fires; Okta and Google Workspace updated; Slack confirmation sent; Jira ticket closed
Both provisioning API calls succeed; Slack message delivered; ticket closed with dual audit entries
T20
Duplicate submission: same user submits identical request twice within 5 minutes
Two identical Slack /it-request commands from the same user within 5 minutes
Second submission detected as duplicate; single Jira ticket created; requester informed that their request is already in progress
Only one Jira ticket visible; duplicate suppression message delivered to requester; no double provisioning
T21
Okta provisioning succeeds but Google Workspace API returns 403
Approved new access ticket; Okta call succeeds; Google Workspace Admin API returns 403 Forbidden
Partial failure logged to Jira ticket; IT escalation channel alerted with ticket ID and the specific step that failed; Slack message to requester states partial completion pending IT review
Okta change not rolled back; Google step failure flagged; IT alerted; requester not falsely told access is complete
T22
Jira ticket update fails after successful provisioning
Provisioning succeeds in Okta and Google Workspace; Jira API returns 500 on ticket update
Agent retries Jira update twice; on second failure, sends Slack alert to IT escalation channel with ticket ID and successful provisioning details for manual closure
Access change in place; IT alerted to close ticket manually; no silent failure
T23
Azure AD user not found during Okta challenge initiation
Requester email resolves correctly in Slack but Okta returns 404 for that user profile
Agent logs error; Jira ticket flagged as needs_manual_review; IT escalation channel alerted; no challenge sent
No Okta API action beyond the failed lookup; IT alert delivered; ticket status updated correctly
Edge-case tests cover scenarios that fall outside the happy path and require the system to fail safely or route correctly to a human. These use a separate ID sequence prefixed E.
ID
Scenario
Input
Expected Output
Pass Criteria
E01
Duplicate ticket: same requester, same system, open ticket already exists
New form submission for access to Google Workspace from user who already has an open ITSAND ticket for the same system
Intake Agent detects existing open ticket for same requester and system; no new ticket created; Slack message to requester with link to existing ticket
No duplicate ticket; requester receives link to existing ticket within 30 seconds of submission
E02
Missing data: system field blank on new access form submission
Form payload with request_type=new_access and system field empty
Intake Agent rejects payload; Slack reply sent to requester asking them to resubmit with the system name; no ticket created
No Jira ticket created; clarification Slack message delivered; run log shows rejection with reason
E03
Slack API unavailable during manager approval send
Verification Agent attempts to send manager approval message; Slack API returns 503
Agent retries three times with exponential backoff (30s, 60s, 120s); on third failure, falls back to sending approval request via Jira comment with @mention; IT escalation channel alerted
Fallback comment visible on Jira ticket; IT alert delivered; no silent failure; retry intervals logged
E04
Human timeout: manager does not respond after two reminder cycles (4 hours total)
Approval request sent; first reminder sent at 2 hours; still no response at 4 hours
Ticket automatically escalated to IT escalation queue; requester notified that IT is reviewing; no further automated reminders sent
Escalation fires at correct interval; requester message delivered; no third reminder sent; ticket status=escalated
E05
Okta API rate limit hit during bulk test run
Five simultaneous password reset requests causing Okta API to return 429 Too Many Requests
Agent queues requests and retries after the Retry-After header interval; no requests dropped; all five tickets eventually closed with audit notes
All five resets complete without manual intervention; run log shows 429 events and retry timing; no ticket left open
E06
Identity challenge fails: user has no registered MFA device in Okta
Password reset request from user with no Okta MFA device enrolled
Okta challenge cannot be sent; agent logs error; Jira ticket flagged as escalation_required; IT escalation channel receives alert with requester details and reason; no password reset executed
No reset attempted; IT alert includes requester name and specific failure reason; ticket status=escalation_required
Test and QA PlanPage 3 of 4
FS-DOC-06Quality
04Phase 3 — end-to-end production test
Important before running Phase 3: Use only the designated internal test accounts for both the requester and manager roles. The FullSpec team will confirm these accounts with the IT Support Lead before the session begins. All Jira tickets created during Phase 3 must be voided (resolved with a 'QA test — void' label) immediately after each case. Do not use a real staff member's Okta profile for the identity challenge test. Confirm that production service account tokens are active and scopes match the Integration and API Spec before starting T24.
ID
Scenario
Input
Expected Output
Pass Criteria
T24
Full production run: password reset path end to end
IT test account submits /it-request reset password in the production Slack workspace
Jira ticket created in production project within 10 seconds; Okta MFA challenge delivered to test account device; on successful verification, password reset or reset link issued; Slack confirmation sent to test account; Jira ticket closed with full audit note
All five steps complete without manual intervention; ticket status=Done; audit note contains action, timestamp, Okta call reference, and agent ID; Slack message received by test account
T25
Full production run: new access provisioning path end to end
IT test account submits web form requesting access to Google Workspace group prod-test-group; manager field set to IT Lead test account
Jira ticket created; manager receives Slack approval message; on Approve click, Okta role assigned and test account added to prod-test-group in Google Workspace; Slack confirmation sent to requester; Jira ticket closed with dual audit entries
User visible in Google Workspace group prod-test-group after provisioning; ticket closed; both API call references in audit note; Slack confirmation delivered
T26
Escalation path: manager denies access request in production
Same new access form submission as T25; manager clicks Deny in Slack
No provisioning executed; requester receives Slack message explaining denial; Jira ticket routed to IT escalation queue with denial recorded; IT escalation channel alerted
IT escalation queue entry visible; no Google Workspace or Okta change made; requester Slack message delivered; denial timestamp on ticket
T27
Error log verification: confirm audit trail completeness
Review run logs from T24 and T25 in the automation platform and Jira
Every action step has a corresponding log entry: trigger receipt, Jira ticket creation, Okta API call, Google Workspace API call (T25 only), Slack messages sent, Jira ticket closure. No gaps in the sequence.
FullSpec team confirms log completeness against the step checklist in the Integration and API Spec; any gap is a blocking failure requiring resolution before sign-off
T28
Process owner review and approval
IT Support Lead (process owner) reviews results of T24 through T27 in a shared session with the FullSpec team
Process owner confirms: all test cases passed; audit logs are complete and readable; escalation routing is correct; Slack messages match agreed content. FullSpec records the approval outcome and sends a written confirmation to the process owner at support@gofullspec.com.
PASS: process owner confirms approval in writing. FullSpec confirmation email sent. No separate signature block required.
Once T28 is recorded as a pass, the automation is cleared for live operation. FullSpec will void all Phase 3 test tickets, remove any test accounts from Google Workspace groups, and send the go-live confirmation to the IT Support Lead. The SOP Runbook and escalation contact details are delivered at the same time. For any questions during or after testing, contact the FullSpec team at support@gofullspec.com.
Test and QA PlanPage 4 of 4