FS-DOC-06Quality
Test and QA Plan
GDPR / Data Privacy Request Handling
[YourCompany.com] · Legal Department · Prepared by FullSpec · [Today's Date]
This document defines every test case the FullSpec team runs before the GDPR / Data Privacy Request Handling automation is cleared for production use. Testing is structured in three sequential phases: unit tests on individual agents, integration and edge-case tests across agent handoffs, and a final end-to-end run in the production environment. No phase begins until the previous phase achieves a full pass. The process owner joins the FullSpec team in Phase 3 to review outcomes and record formal approval.
01Testing approach
Testing runs in three phases in sequence. No phase begins until the previous phase fully passes. Each phase targets a different layer of the automation: isolated agent logic in Phase 1, cross-agent handoffs and failure modes in Phase 2, and a live end-to-end production run in Phase 3. The FullSpec team owns all execution through Phase 2; the process owner joins in Phase 3 to validate outputs against real business expectations and record approval.
1Phase 1 — Unit Testing
Each agent tested in isolation before any handoff is exercised
Scope
Individual agent logic: Intake and Triage Agent, Data Discovery Agent. Each agent is triggered and verified independently.
Environment
Sandbox only. No production credentials, live inboxes, or real HubSpot contacts are used.
Credential rule
Sandbox API keys and test accounts are used for all tools (Typeform test mode, Notion sandbox workspace, Gmail test alias, HubSpot sandbox portal, Slack test channel). No production secrets may be loaded.
Pass condition
All cases T01 through T10 return the expected output with zero failures. Any failure blocks progression to Phase 2.
Who runs it
FullSpec team only.
2Phase 2 — Integration and Edge-Case Testing
Agent handoffs and failure modes validated across connected tools
Scope
End-to-end handoffs between agents; exception and edge-case scenarios including missing data, duplicate submissions, tool unavailability, and reviewer timeout.
Environment
Sandbox only, with simulated tool failures and synthetic edge-case payloads injected by the FullSpec team.
Credential rule
Sandbox credentials only. No production data, contacts, or live Slack channels are activated during this phase.
Pass condition
All cases T11 through T17 and edge cases E01 through E06 pass. All error paths surface the correct fallback behaviour with an appropriate alert or log entry.
Who runs it
FullSpec team only.
3Phase 3 — End-to-End Production Test
Full workflow traced in the live environment before go-live clearance
Scope
Complete workflow from Typeform submission through to Notion case closure, using the live production environment and real tool credentials.
Environment
Production. Live credentials, real Notion workspace, live HubSpot portal (test contact record), and active Gmail and Slack accounts.
Credential rule
Production credentials are loaded for all tools. All test submissions must use an internal email address designated for testing. Test records must be voided in Notion and HubSpot after the phase completes.
Pass condition
All cases T18 through T21 pass, including the process owner review-and-approval case. FullSpec records the approval outcome in the confirmation log. No separate signoff block is required.
Who runs it
FullSpec team executes cases T18 through T20. The process owner participates in T21 (review and approval gate) and confirms the outcome to the FullSpec team.
Test and QA PlanPage 1 of 4
FS-DOC-06Quality
02Phase 1 — unit test cases
Sandbox credentials only. Do not load production API keys, live Gmail accounts, or real HubSpot contacts during Phase 1. Use Typeform test mode, the Notion sandbox workspace, the Gmail test alias, and the HubSpot sandbox portal for every case below.
Intake and Triage Agent — handles Typeform submission, Notion case record creation, and identity verification email via Gmail.
ID
Scenario
Input
Expected Output
Pass Criteria
T01
Happy path: Subject Access Request (SAR) submitted
Typeform submission with request type = SAR, requester name, email, and submission timestamp
Notion case record created with correct request type, deadline date (submission date + 30 days), and status = Awaiting Verification; Gmail verification email sent to requester address
Notion record exists within 30 seconds of submission; deadline date is accurate; Gmail delivery confirmed in sandbox sent folder
T02
Happy path: Erasure request submitted
Typeform submission with request type = Erasure
Notion case record with request type = Erasure, correct deadline, status = Awaiting Verification; verification email dispatched
Record type field correctly reflects Erasure; email subject line matches erasure template
T03
Happy path: Rectification request submitted
Typeform submission with request type = Rectification
Notion case record with request type = Rectification; verification email dispatched with rectification-specific template text
All three request type templates produce distinct email content; no generic fallback text appears
T04
Failure: Typeform submission missing requester email
Typeform submission with email field blank
Workflow halts at Gmail send step; error is logged in the automation platform error log; no Notion record is created without a valid contact address
Error log entry present; no partial Notion record created; no email send attempted
T05
Failure: Notion API returns 503 on record creation
Valid Typeform submission; Notion sandbox API is temporarily set to return 503
Automation retries up to three times with exponential backoff; after three failures, an alert is written to the error log and the task is flagged for manual intervention
Three retry attempts logged with timestamps; no silent failure; alert entry confirmed in error log
T06
Failure: Gmail send fails due to authentication error
Valid Typeform submission; Gmail sandbox credentials deliberately invalidated
Notion record is created successfully; Gmail step fails; error is logged; case status in Notion is set to Verification Email Failed
Notion record status field reflects the failure; error log entry present; no duplicate records created on retry
T07
Duplicate submission: same requester submits twice within one hour
Two identical Typeform submissions from the same email address within 60 minutes
First submission creates a Notion record normally; second submission is detected as a duplicate and logged without creating a second case record
Only one Notion record exists after both submissions; duplicate flag is present in the automation log
Data Discovery Agent — handles HubSpot data retrieval, Notion draft response compilation, and Slack reviewer notification. Triggered when the Notion case record identity status is set to Confirmed.
ID
Scenario
Input
Expected Output
Pass Criteria
T08
Happy path: Identity confirmed, HubSpot contact record found
Notion case record status updated to Identity Confirmed; HubSpot sandbox contact record with matching email address exists
Agent queries HubSpot via API and retrieves contact data, deal history, and notes; compiles them into a structured draft in the Notion case record; Slack message sent to reviewer channel with link to case
Notion draft section populated within 60 seconds; all retrieved HubSpot fields mapped correctly; Slack message contains correct Notion URL and reviewer prompt
T09
Failure: HubSpot contact not found for confirmed identity
Notion identity status = Confirmed; no matching HubSpot contact record in sandbox
Agent creates a draft noting no CRM records found; Notion case record updated with status = Data Retrieval Complete (No Records); Slack notification sent with a warning flag indicating zero records
Draft section states no records found; Slack message includes the no-records warning; case is not stalled or abandoned
T10
Failure: HubSpot API rate limit exceeded during data pull
Valid identity confirmed trigger; HubSpot sandbox is configured to return 429 Too Many Requests
Agent pauses and retries after the Retry-After header interval (default 10 seconds); successful on second attempt; or after three failures, logs an error and sets case status to Data Retrieval Failed
Retry logic confirmed in logs; no data loss; case status updated correctly on persistent failure
Test and QA PlanPage 2 of 4
FS-DOC-06Quality
03Phase 2 — integration and edge case tests
Integration tests verify that the Intake and Triage Agent correctly hands off to the Data Discovery Agent, that Slack notifications reach the reviewer, that the reviewer approval gate behaves correctly, and that the final send and audit log steps execute as expected. All cases below continue the T sequence from Phase 1.
ID
Scenario
Input
Expected Output
Pass Criteria
T11
Handoff: Intake Agent to Data Discovery Agent on identity confirmation
Notion case record status manually updated to Identity Confirmed in sandbox
Data Discovery Agent triggers within 60 seconds; HubSpot query initiated; no manual intervention required
Agent trigger timestamp logged; no orphaned records; handoff latency under 60 seconds
T12
Reviewer approval gate: reviewer approves via Notion
Draft response package present in Notion; reviewer sets approval field to Approved
Automation detects approval status change; Gmail sends approved response to requester; Notion case status updated to Response Sent; audit log entry created
Gmail send confirmed in sandbox sent folder; Notion status = Response Sent; audit log populated with reviewer name and approval timestamp
T13
Reviewer approval gate: reviewer requests amendment
Reviewer sets Notion approval field to Revise and adds an annotation note
Automation does not send the response; Slack sends a follow-up message to the reviewer channel noting the revision request; case status updated to Under Revision
No email dispatched; Slack revision alert confirmed; case status reflects Under Revision
T14
Audit log closure: case closed after approved response sent
Notion case record status = Response Sent
Automation updates the Notion record with completion date, outcome, and reviewer name; case status set to Closed
All audit fields populated: completion date, outcome, reviewer name; status = Closed; no fields left blank
T15
Slack notification delivery: reviewer channel message confirmed
Data Discovery Agent completes draft compilation
Slack message posted to the designated reviewer channel containing the Notion case URL, request type, and deadline date
Slack message appears in the correct channel; all three data fields present; message posted within 30 seconds of draft completion
T16
Slack unavailable: Slack API returns 500 during reviewer notification
Draft compiled; Slack sandbox configured to return 500
Automation retries twice; on persistent failure, logs error and sets Notion case status to Reviewer Notification Failed so manual follow-up can occur
Retry attempts logged; case status updated; no silent failure; case is not abandoned
T17
Full integration run: SAR from submission to case closed
End-to-end sandbox run: Typeform SAR submission, identity confirmation, HubSpot data pull, reviewer approval, Gmail send, Notion closure
All seven workflow steps execute in sequence without manual intervention; audit log complete at closure
No step errors; all Notion fields populated; Gmail delivery confirmed; audit log complete; total sandbox run time recorded for benchmarking
Edge-case tests cover scenarios that fall outside the standard happy path and are likely to occur in a real operating environment. These use IDs prefixed E to distinguish them from the sequential unit and integration cases.
ID
Scenario
Input
Expected Output
Pass Criteria
E01
Duplicate submission: same requester submits a second SAR within the 30-day window of an open case
Second Typeform submission from an email address already linked to an open Notion case
Automation detects the open case, logs the second submission as a duplicate, and does not create a new record; a note is appended to the existing Notion case
Only one active case record per requester email; duplicate note present; no second verification email sent
E02
Missing requester name field on Typeform submission
Typeform submission with name field left blank
Automation logs a data quality warning in the Notion record; case is created with a placeholder value and status = Incomplete Submission; no verification email sent until name is resolved
Notion record created with warning flag; email not dispatched; status = Incomplete Submission
E03
Notion workspace unavailable during case record creation
Valid Typeform submission; Notion API returns 503 for an extended period (simulated 5-minute outage)
Automation queues the record creation attempt and retries on a schedule; after the outage resolves, the record is created with the original submission timestamp preserved
Record eventually created with correct original timestamp; no data loss; retry queue behaviour confirmed in logs
E04
Typeform webhook fires but payload is malformed or empty
Webhook event received with an empty or structurally invalid JSON body
Automation rejects the payload, logs a parse error, and does not attempt to create a Notion record or send any email
Parse error logged; no downstream action taken; no empty or corrupt Notion records created
E05
Reviewer does not respond within 5 business days of Slack notification
Slack notification sent; reviewer approval field in Notion remains blank for 5 business days
Automation sends a second Slack reminder on day 5; if still unresolved by day 7, the case status is updated to Escalated and the Operations Manager is notified directly
Reminder message confirmed in Slack on day 5; escalation status and direct notification confirmed by day 7
E06
HubSpot returns data for a contact with multiple merged records
HubSpot sandbox contact with two merged profiles and conflicting email address fields
Agent retrieves data from both merged records, deduplicates where fields are identical, and flags conflicting fields in the Notion draft for human review
No data is silently dropped; conflict flags visible in Notion draft; Slack notification includes a note that manual review of merged records is required
Test and QA PlanPage 3 of 4
FS-DOC-06Quality
04Phase 3 — end-to-end production test
Important before running Phase 3: All test submissions must use an internal email address designated solely for testing (for example, qa-test@[YourCompany.com]). Do not use a real customer or employee email address as the requester. After Phase 3 is complete, the FullSpec team will void all test case records in Notion (setting status to Test Record — Void) and delete or archive the test contact created in HubSpot. Confirm with the Operations Manager that the test Gmail alias has been cleared before go-live.
Phase 3 runs against the live production environment with real credentials and real tool connections. Its purpose is to confirm that every component behaves correctly outside the sandbox, that error logs are accessible and correctly formatted, and that the process owner can review outputs and record formal approval. Cases continue the T sequence from Phases 1 and 2.
ID
Scenario
Input
Expected Output
Pass Criteria
T18
Full production run: SAR submitted through live Typeform intake form
FullSpec team submits a test SAR via the live Typeform form using the designated QA test email address
Live Notion workspace receives a correctly structured case record with a 30-day deadline; Gmail sends the identity verification email to the QA test address; all fields populated without manual input
Notion record visible in the live workspace within 60 seconds; deadline date correct; Gmail delivery confirmed in the live sent folder; no manual steps required
T19
Production data discovery: identity confirmed, HubSpot live data pull
FullSpec team sets identity status to Confirmed on the T18 case record using a pre-created test contact in the live HubSpot portal
Data Discovery Agent queries the live HubSpot portal via the production API key, retrieves all records for the test contact, compiles the draft response package in Notion, and sends a Slack notification to the live reviewer channel
HubSpot API call logged with correct OAuth token; Notion draft section populated with real retrieved data; Slack message delivered to the live reviewer channel within 30 seconds of identity confirmation
T20
Production error-log verification: confirm logs are accessible and correctly structured
FullSpec team inspects the automation platform error log and the Notion audit trail after completing T18 and T19
Error log shows zero errors for T18 and T19 runs; Notion case record contains a complete, timestamped audit trail covering submission, verification email, identity confirmation, data retrieval, and Slack notification events
Error log is accessible to the FullSpec team without requiring a platform rebuild; every audit event has a timestamp, event type, and outcome field; no blank or null audit entries present
T21
Process owner review and approval: production end-to-end sign-off
The process owner (Operations Manager) reviews the T18 case record in the live Notion workspace, including the draft response package and the full audit trail, and sets the Notion approval field to Approved
Automation detects the approval, dispatches the approved response email via Gmail to the QA test address, updates the Notion case status to Closed, and populates all audit log closure fields including reviewer name, approval timestamp, and completion date
Process owner confirms the draft accurately reflects expected output for a SAR; Gmail send to QA test address confirmed; Notion case status = Closed; all audit closure fields populated; FullSpec team records process owner approval in the FullSpec confirmation log to conclude Phase 3
Once T21 is confirmed, the FullSpec team will void all Phase 3 test records in Notion and HubSpot, clear the QA test Gmail alias, and issue the go-live clearance to the process owner. The confirmation log entry from T21 constitutes the formal approval record for this automation. No separate signoff block is required.
Test and QA PlanPage 4 of 4