Back to Document Retention & Archiving

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

Document Retention and Archiving

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

This document defines the complete quality assurance programme for the Document Retention and Archiving automation. It is written for the FullSpec build team and covers every test case required before any component is promoted to production. Testing runs in three sequential phases: unit tests on each agent in isolation, integration and edge-case tests across agent handoffs and exception scenarios, and a final end-to-end production run. No phase begins until the previous phase has fully passed. The process owner joins Phase 3 only, to review and formally approve the live run.

01Testing approach

All testing runs in three phases in strict sequence. No phase begins until every test case in the previous phase has achieved a pass status. Phase 1 targets each agent individually in a sandbox environment. Phase 2 tests agent-to-agent handoffs and edge conditions. Phase 3 executes a complete production run with live credentials and requires sign-off from the process owner as its final recorded action.

1
Phase 1: Unit Testing
Estimated time: 1 to 2 business days
Scope
Each agent tested in isolation: Document Classification Agent and Retention Schedule Monitor independently verified against defined inputs and expected outputs.
Environment
Sandbox only. No production credentials, live SharePoint sites, or real documents used at this phase.
Credential rule
Sandbox API keys and test OAuth tokens only. Production credentials must not be present in any environment variable or config file during Phase 1.
Pass condition
All cases T01 through T12 return the expected output with zero critical failures. Amber warnings may be documented for review but do not block progression if the core output is correct.
Who runs it
FullSpec team only. Process owner is not involved in Phase 1.
2
Phase 2: Integration and Edge Case Testing
Estimated time: 1 to 2 business days
Scope
Full agent handoff chain tested end to end in the sandbox. Edge cases covering duplicates, missing metadata, unavailable external tools, and human approval timeouts.
Environment
Sandbox environment with stubbed external services where a live sandbox tier is unavailable (DocuSign, Slack). SharePoint and Microsoft 365 test tenants used throughout.
Credential rule
Sandbox credentials only. Slack webhook must point to a private test channel, not a live legal channel. DocuSign sandbox account required.
Pass condition
Integration tests T13 through T19 all pass. Edge-case tests E01 through E06 all demonstrate correct fallback behaviour with no data corruption or silent failure.
Who runs it
FullSpec team only. Process owner is not involved in Phase 2.
3
Phase 3: End-to-End Production Test
Estimated time: 1 business day
Scope
Single complete workflow run using live production credentials, real monitored folders, and live Slack channels. Traced from document upload through to destruction alert and register logging.
Environment
Production. Live SharePoint tenant, production Microsoft 365 retention register, live Slack legal channel, and live DocuSign account.
Credential rule
Full production OAuth tokens and service account credentials active. All credentials stored in the automation platform's encrypted secrets vault, not in plain-text config.
Pass condition
Cases T20 through T23 all pass. Process owner reviews the full audit log output and records formal approval. Approval is logged in the FullSpec confirmation record. No separate signoff block is required.
Who runs it
FullSpec team executes T20 through T22. Process owner joins for T23 (review and approval). FullSpec records the outcome.
Test and QA PlanPage 1 of 4
FS-DOC-06Quality

02Phase 1 — unit test cases

Sandbox credentials only. Before running any test in this phase, confirm that no production SharePoint site URL, production Microsoft 365 tenant credential, live DocuSign API key, or real Slack webhook is present in the environment. Use dedicated sandbox or test-tenant values exclusively. Any test document used must be a synthetic file with no real matter data.

Document Classification Agent: reads each incoming document, assigns a type from the defined taxonomy, matches the correct retention period, and writes structured metadata. Build complexity: Moderate. Estimated build time: 14 hours.

ID
Scenario
Input
Expected Output
Pass Criteria
T01
Happy path: NDA received via DocuSign
Completed DocuSign envelope containing a two-party NDA PDF; envelope metadata includes sender email and timestamp.
Document type: NDA; retention period: 7 years; destruction date: calculated correctly from execution date; matter reference extracted from subject line; metadata written to SharePoint file properties.
All five metadata fields populated with correct values; SharePoint file properties updated within 60 seconds of trigger; no error logged.
T02
Happy path: employment contract uploaded to SharePoint
PDF file dropped into the monitored SharePoint ingestion folder; filename contains matter number prefix.
Document type: Employment Contract; retention period: 7 years post-termination (flagged for manual end-date confirmation); matter reference parsed from filename; metadata applied.
Classification matches taxonomy entry for Employment Contract; retention period field populated; matter reference matches filename prefix; audit log entry created.
T03
Happy path: regulatory filing via Dropbox Business
PDF regulatory filing dropped into monitored Dropbox Business folder; no matter number in filename.
Document type: Regulatory Filing; retention period: 10 years; matter reference field populated as UNKNOWN pending manual update; responsible party set to default legal manager.
Classification correct; matter reference flagged as UNKNOWN rather than blank; Slack alert sent to legal manager indicating missing matter reference.
T04
Happy path: court correspondence document
Word document uploaded to SharePoint ingestion folder; content includes court header and case reference number.
Document type: Court Correspondence; retention period: 6 years; case reference extracted and written to matter reference field.
Document type and retention period match taxonomy; case reference correctly parsed from body text; file moved to correct archive folder path.
T05
Failure mode: unrecognised document type
Scanned image PDF with no extractable text content; no filename metadata; arrives in SharePoint ingestion folder.
Classification result: UNCLASSIFIED; document quarantined to an exceptions folder; Slack alert sent to legal manager with document name and ingestion timestamp; no metadata written.
File is not assigned a false classification; exceptions folder receives the file; Slack message delivered within 90 seconds; audit log records UNCLASSIFIED event with reason: no extractable text.
T06
Failure mode: DocuSign envelope missing required fields
DocuSign envelope arrives with no sender name and no subject line.
Agent logs an incomplete-metadata event; document parked in exceptions folder; responsible party field set to UNKNOWN; alert sent to legal manager.
No metadata fields are silently left blank; UNKNOWN is written explicitly for missing fields; alert delivered; audit log entry created.
T07
Failure mode: SharePoint metadata write error
Classification completes successfully but the SharePoint API returns a 403 Forbidden on the metadata write call.
Agent retries the write call up to three times with exponential backoff; after third failure, an error event is logged and a Slack alert is sent to the FullSpec monitoring channel.
Retry logic fires correctly; final failure logged with HTTP status code and timestamp; no silent drop of the classification result; Slack alert includes document name and error code.
T08
Failure mode: duplicate document detected
Identical filename and file hash already present in the retention register for the same matter reference.
Agent flags the incoming document as a probable duplicate; file moved to a duplicates review folder rather than the archive; alert sent to legal manager with both the original and duplicate file references.
No overwrite of the existing register entry; duplicate file isolated; alert contains both file identifiers; audit log records duplicate-detected event.

Retention Schedule Monitor: runs on a daily schedule, checks every retention register entry against the current date, and routes documents that have reached or passed their destruction date to the legal manager via Slack. Build complexity: Moderate. Estimated build time: 12 hours.

ID
Scenario
Input
Expected Output
Pass Criteria
T09
Happy path: single document reaches destruction date today
Retention register row where destruction_date equals today's date; document_type: NDA; responsible_party: Legal Manager.
Slack message delivered to legal manager containing document name, document type, matter reference, retention period served, and a structured approval prompt with approve and defer options.
Slack message delivered within the daily run window (within 5 minutes of scheduled trigger); all five data fields present in message body; register row status updated to PENDING APPROVAL.
T10
Happy path: multiple documents due on same day
Three register rows all with destruction_date equal to today; different document types and matter references.
Three separate Slack messages sent, one per document; no batching that would obscure individual approval decisions.
Three distinct Slack messages received; each contains the correct document-specific data; no cross-contamination of matter references between messages.
T11
Happy path: legal manager approves destruction
Legal manager clicks the approve action in the Slack message for a single document.
Register row status updated to DESTROYED; destruction date, approver name, and approval timestamp written to the register; audit log entry created.
Register row reflects DESTROYED status within 30 seconds of approval click; approver name matches the Slack user who clicked; audit log entry contains all three data points.
T12
Failure mode: retention register unavailable at scheduled run time
Microsoft 365 API returns a 503 Service Unavailable during the daily scheduled read of the retention register.
Monitor logs the API failure with timestamp; retries after 15 minutes; if the second attempt also fails, a Slack alert is sent to the FullSpec monitoring channel and the run is marked as FAILED for that day.
Retry fires after exactly 15 minutes; second failure triggers Slack alert to monitoring channel; no documents are incorrectly flagged or skipped silently; run status written to the execution log.
Test and QA PlanPage 2 of 4
FS-DOC-06Quality

03Phase 2 — integration and edge case tests

Phase 2 tests the full handoff chain between the Document Classification Agent and the Retention Schedule Monitor, and between the monitor and the downstream Slack approval workflow and register logging step. All tests run in the sandbox environment. IDs continue from Phase 1.

ID
Scenario
Input
Expected Output
Pass Criteria
T13
Agent handoff: Classification Agent writes register row correctly consumed by Monitor
NDA uploaded to sandbox SharePoint ingestion folder; Classification Agent runs and writes a register row with destruction_date set to today for test purposes.
Retention Schedule Monitor, on its next scheduled run, reads the new register row and sends the correct Slack alert to the test legal manager account.
Monitor correctly reads the Classification Agent output without manual intervention; Slack alert data matches the register row exactly; no duplicate or missing rows in the register.
T14
Handoff: Slack approval response correctly updates register
Sandbox Slack user clicks the approve action on a destruction alert message.
Register row updated to DESTROYED status; approval metadata (user, timestamp) written; audit log entry created. Subsequent Monitor run skips this row.
Register row status is DESTROYED before the next scheduled Monitor run; Monitor does not re-alert on a DESTROYED row; audit log entry persists independently of the row status.
T15
Handoff: Slack approval response for defer
Sandbox Slack user clicks the defer action on a destruction alert message.
Register row status updated to DEFERRED; deferred_until date set to 30 days from today; Monitor will not re-alert until that date.
DEFERRED status written within 30 seconds; deferred_until date calculated correctly; Monitor skips the row on the following daily run; audit log records the deferral event with user and timestamp.
T16
Handoff: Classification Agent output routes file to correct SharePoint folder
Three documents of different types (NDA, Regulatory Filing, Court Correspondence) uploaded in sequence.
Each file moved to the correct taxonomy-defined folder path in sandbox SharePoint; metadata applied before the move; register rows created with correct folder_path values.
All three files land in distinct correct folders; no file lands in the root or ingestion folder after processing; folder_path in the register matches the actual SharePoint location.
T17
Handoff: end-to-end audit trail from ingestion to register entry
Single NDA uploaded; full workflow executes: classification, metadata write, folder move, register log.
Audit log contains four sequential entries: CLASSIFIED, METADATA_WRITTEN, FILE_MOVED, REGISTER_LOGGED; each entry includes document ID, timestamp, and agent or tool that performed the action.
All four audit entries present; timestamps are in ascending chronological order; no gaps in the sequence; document ID is consistent across all four entries.
T18
Handoff: DocuSign trigger fires Classification Agent correctly
Sandbox DocuSign envelope marked as completed; webhook fires to the automation platform.
Classification Agent receives the envelope payload, extracts the PDF attachment, classifies it, and proceeds through the full ingestion chain.
Classification Agent is triggered within 30 seconds of the DocuSign webhook event; classification result is correct for the document type in the test envelope; full handoff chain completes.
T19
Handoff: Dropbox Business trigger fires Classification Agent correctly
File dropped into the monitored sandbox Dropbox Business folder.
Classification Agent receives the new-file event, downloads the file, classifies it, and proceeds through the ingestion chain.
Agent triggered within 60 seconds of file drop; classification result correct; file moved from Dropbox ingestion folder to the correct SharePoint archive path; register row created.

Edge case tests cover scenarios that fall outside the normal happy path but are realistic in legal operations: duplicate submissions, incomplete or missing data, external tool unavailability, and human approval timeouts. These use the E-series ID prefix.

ID
Scenario
Input
Expected Output
Pass Criteria
E01
Duplicate document submitted within 24 hours of original
Identical file (same hash, same filename) re-uploaded to the SharePoint ingestion folder within 24 hours of the first ingestion.
Agent detects the duplicate via hash comparison against the register; file quarantined to duplicates folder; original register entry unchanged; Slack alert sent to legal manager.
No second register row created; no metadata overwrite; duplicate file isolated; Slack alert delivered; audit log records DUPLICATE_DETECTED.
E02
Document arrives with missing matter reference and no inferrable metadata
PDF with no filename matter prefix, no body text matter number, and no DocuSign sender metadata to cross-reference.
Agent classifies the document type if content is readable; matter reference set to UNRESOLVED; responsible party set to default legal manager; Slack alert sent requesting manual matter reference entry.
Classification attempt made and result recorded even if matter reference is UNRESOLVED; UNRESOLVED written explicitly; alert delivered with document name and classification result; audit log entry created.
E03
SharePoint API unavailable during folder move step
Classification and metadata write succeed; SharePoint returns 503 on the folder move API call.
Automation retries the move up to three times with exponential backoff; on final failure, document remains in the ingestion folder with a MOVE_FAILED status tag; Slack alert sent to monitoring channel.
File not lost or silently left in an ambiguous state; MOVE_FAILED status written to the register row; Slack alert includes document name, step that failed, and HTTP error code; retry count logged.
E04
Slack unavailable when destruction alert is due to be sent
Retention Monitor identifies a document due for destruction; Slack API returns 503.
Monitor retries the Slack send up to three times; on final failure, logs the unsent alert as ALERT_FAILED in the execution log and sends a fallback email to the legal manager via Microsoft 365.
Fallback email sent within 10 minutes of the Slack failure; email contains the same document details as the intended Slack message; execution log records ALERT_FAILED with timestamps.
E05
Legal manager does not respond to destruction alert within 5 business days
Slack destruction alert sent; no approve or defer action taken by the legal manager within 5 business days.
Monitor sends a single reminder Slack message on day 5; if still no response after a further 2 business days, the alert is escalated to the Compliance Lead via a second Slack message; register row status set to ESCALATED.
Reminder message sent on day 5 only (not before); escalation sent on day 7 only; register row status updated at each stage; audit log records reminder and escalation events with timestamps.
E06
Document type present in taxonomy but retention period entry is blank in the ruleset
PDF correctly identified as an Employment Contract; the ruleset entry for Employment Contract has a blank retention_period field.
Agent classifies the document type correctly; retention period field set to RULESET_INCOMPLETE; document moved to a pending-review folder rather than the standard archive; Slack alert sent to legal manager and Compliance Lead.
No default or guessed retention period written; RULESET_INCOMPLETE written explicitly; document isolated in pending-review folder; both recipients receive the Slack alert; audit log records the event.
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 and a dedicated test matter reference (e.g. MATTER-TEST-001) for all documents submitted in this phase. Do not use a real client matter number. Any register row, Slack message, folder entry, or audit log entry created during Phase 3 must be voided and removed from the production register and production SharePoint immediately after the process owner has completed their review. Confirm this cleanup has been completed before the process goes live to real document sources.

Phase 3 runs a single complete workflow trace against production infrastructure. Live credentials are active for all connected tools: SharePoint, Microsoft 365, DocuSign, Slack, and Dropbox Business. The FullSpec team executes T20 through T22, then invites the process owner to review the outputs and complete T23 as the formal approval step. The outcome of T23 is recorded in the FullSpec confirmation record and constitutes the go-live sign-off for this process.

ID
Scenario
Steps Traced
Expected Output
Pass Criteria
T20
Full production ingestion run: document uploaded, classified, archived, and registered
1. Test NDA PDF uploaded to the live monitored SharePoint ingestion folder using the internal test email address and MATTER-TEST-001. 2. Classification Agent fires. 3. Metadata written to live SharePoint file properties. 4. File moved to the production NDA archive folder. 5. Register row added to the live Microsoft 365 retention register.
Document type: NDA; retention period: 7 years; destruction date correctly calculated; matter reference: MATTER-TEST-001; responsible party: Legal Operations Manager. Register row present with all five fields. File located in the correct production archive folder.
All five metadata fields correct in live SharePoint; register row created within 2 minutes of upload; file present in the correct production folder path; audit log shows four sequential entries (CLASSIFIED, METADATA_WRITTEN, FILE_MOVED, REGISTER_LOGGED) with correct timestamps.
T21
Production destruction alert: Monitor identifies test document as due and sends live Slack alert
1. Manually set the destruction_date on the MATTER-TEST-001 register row to today's date. 2. Trigger a manual Monitor run (or wait for the scheduled daily run). 3. Observe the Slack message delivered to the live legal Slack channel.
Slack message delivered to the production legal manager Slack channel. Message contains: document name, document type (NDA), matter reference (MATTER-TEST-001), retention period served (7 years), and approve/defer action buttons.
Slack message delivered within 5 minutes of the Monitor run; all five data fields present and correct; approve and defer buttons functional; register row status updated to PENDING APPROVAL; audit log records ALERT_SENT.
T22
Production error log and audit trail verification
1. Review the automation platform execution log for the full T20-to-T21 run. 2. Review the Microsoft 365 audit log entries. 3. Confirm no silent errors, dropped steps, or missing log entries.
Execution log shows a clean run with no ERROR or WARNING entries for T20 and T21. Audit log contains all expected entries with correct actor labels (agent name or tool name), timestamps, and document identifiers.
Zero ERROR entries in the execution log for the T20-T21 run; all audit log entries present and in correct chronological sequence; document ID consistent across all log entries; no orphaned or partial entries.
T23
Process owner review and production approval
1. FullSpec presents the process owner with: the production register row for MATTER-TEST-001, the SharePoint file location, the Slack alert screenshot, and the full audit log for the T20-T21 run. 2. Process owner reviews all outputs against the agreed acceptance criteria. 3. Process owner records approval or raises outstanding issues.
Process owner confirms: classification is correct, metadata fields are accurate, the archive folder is correct, the Slack alert contains the right information, and the audit log is complete. Process owner records formal approval. FullSpec logs the approval in the FullSpec confirmation record.
Process owner approval recorded in the FullSpec confirmation record with the reviewer's name, role, and the date of review. All outputs reviewed by the process owner meet the acceptance criteria defined in this plan. The test register row and test file are then voided and removed from production by the FullSpec team before go-live.
After T23 is complete and the process owner approval is recorded, the FullSpec team will remove all test data from the production environment: the MATTER-TEST-001 register row, the test file from the SharePoint archive folder, and the Slack alert thread. Confirm this cleanup is complete before activating the live monitored folder sources. Any questions about this process should be directed to support@gofullspec.com.
Test and QA PlanPage 4 of 4

More documents for this process

Every document generated for Document Retention & Archiving.

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