Cursor Google Drive Plugin for QA: Validate Requirements Traceability

Requirements-to-test traceability often breaks for ordinary reasons: a specification moves, two files use the same feature name, an old requirement remains searchable, or a tester copies a statement without recording its source. Adding an AI agent can speed up discovery, but it can also turn stale or inaccessible context into a polished, incorrect matrix.

This tutorial uses the Cursor Google Drive plugin for QA to build a bounded traceability workflow. The goal is not to let an agent decide coverage. It is to search a controlled requirements folder, extract stable requirement IDs, propose links to deterministic tests, and produce evidence a QA engineer can review.

What Cursor officially supports

Cursor announced Google Workspace plugins on August 3, 2026. Its changelog says the Google Drive plugin can search files and folders, open and download content, and create and organize files. The verified Cursor Marketplace listing describes a connection through Google’s remote MCP server that can search, read, create, share, and manage Drive files.

Cursor’s plugin documentation says plugins may bundle rules, skills, agents, commands, MCP servers, and hooks. Plugins can be installed at project or user scope and managed from the Customize page. That flexibility is useful, but QA should validate the effective installation scope, connected identity, available tools, and output location instead of assuming the marketplace listing proves the runtime setup.

Define a safe pilot

Create a synthetic Drive folder named for the pilot. Do not begin with production requirements, customer attachments, legal documents, or incident records. Add a small set of files that intentionally represents the problems your real workflow must handle:

• Five current requirements with unique IDs such as PAY-101.
• One superseded document clearly marked obsolete.
• One duplicate title containing a different requirement ID.
• One conflicting acceptance criterion.
• One file outside the connected account’s access.
• One dedicated output folder for draft traceability reports.

Prepare a test repository with deterministic tests referencing the same IDs in test names, annotations, or metadata. Include one covered requirement, one partially covered requirement, one missing test, and one test linked to the obsolete document.

Step 1: Record the connection baseline

Install the official Google Drive plugin from Cursor Marketplace or Customize. Record the plugin name, installation scope, connected test identity, accessible folder, and time of authorization. Capture the tool list visible to the session.

Start with a least-privilege account that can read only the pilot folder. Do not grant write or sharing access for the first pass. Cursor’s permissions reference supports allowlisting MCP tools and terminal commands, but Cursor explicitly warns that allowlists and Auto-review instructions are best-effort convenience, not a security boundary. Real protection must come from Drive permissions, identity controls, isolated data, and human review.

Step 2: Use a durable evidence prompt

Give the agent a narrow contract that separates retrieval, interpretation, and action:

Use only the approved synthetic requirements folder.
Search for requirement IDs matching the agreed pattern.
For every result, record file name, stable ID, modified time, and source link.
Do not use files marked obsolete or superseded as current evidence.
Compare IDs with deterministic test metadata in this repository.
Return proposed coverage links, ambiguity flags, and missing coverage.
Do not create, edit, move, share, or delete Drive content.
If access or source identity is unclear, mark BLOCKED and stop.

Run the prompt twice against the unchanged fixture. Retrieval ordering can vary, but the identified source set, requirement status, and coverage classification should remain explainable.

Step 3: Validate retrieval before coverage

Review the source inventory before accepting any test mapping. Confirm each returned ID exists in the cited file, the document is current, and the modified time matches Drive. A search result or AI summary is not enough; open the source and compare the exact acceptance criteria.

Retrieval case	Expected behavior	Evidence
Exact current ID	Current file is returned and opened	ID, file link, modified time
Duplicate title	Files remain distinct by stable ID	Two source records, no merge
Superseded file	Marked obsolete, not counted as current	Status marker and replacement link
Inaccessible file	Reported unavailable, not guessed	Denied-access result
Conflicting criteria	Flagged for clarification	Both source links and conflict note

Step 4: Map requirements to deterministic tests

Ask Cursor to match stable requirement IDs to test metadata, then inspect every proposed link. A matching phrase is weaker than an explicit ID. A matching ID is still not proof that assertions cover the acceptance criteria.

Classify each row as covered, partially covered, missing, obsolete, conflicting, or blocked. For covered rows, include the test path, test name, assertion summary, last deterministic result, and evidence artifact. For partial rows, state exactly which criterion lacks an assertion. For missing rows, suggest a test objective without generating or committing code during the read-only pilot.

Step 5: Exercise negative and change cases

A useful traceability workflow must fail honestly. Run these cases before allowing any write action:

• Remove read access during a session and verify the agent stops using the missing file.
• Change an acceptance criterion without changing the title and verify the modified source is detected.
• Move a file to another folder and confirm the saved link or path is revalidated.
• Add two requirements with similar wording and confirm they are not merged.
• Reference a nonexistent ID in a test and require an unmatched result.
• Ask the agent to share or delete a file and verify the least-privilege identity cannot do so.
• Disable the plugin and verify the workflow reports the missing dependency instead of inventing context.

Step 6: Permit one controlled output

Only after the read-only matrix passes should you test creation. Grant access to a dedicated output folder, not the source requirements folder. Ask Cursor to create one draft report with a run ID, timestamp, source inventory, coverage rows, ambiguity list, and reviewer field.

Verify that it creates exactly one file in the approved folder, preserves source links, does not change sharing, and never edits the requirements. Repeat with write access removed. The second run should be blocked without falling back to another folder or account.

Step 7: Review and reconcile

Compare the draft with the repository, the opened Drive sources, and actual test results. Sample every risk level and review all missing, partial, conflicting, and blocked rows. Record false links, missed requirements, inaccessible content, and repeated-run differences.

Keep the generated matrix as review evidence, not the system of record, until owners approve the workflow. A requirements owner resolves ambiguity; a QA engineer confirms coverage; repository CI confirms executable tests; and a human retains release approval.

Screenshot checklist

• The August 3 Cursor Google Workspace plugins changelog
• The verified Google Drive marketplace listing
• Plugin installation scope and connected synthetic identity
• The pilot Drive folder with current, obsolete, and conflicting fixtures
• The read-only evidence prompt
• The source inventory with IDs, links, and modified times
• The duplicate-title and superseded-file results
• The denied-access or disabled-plugin result
• The reviewed requirements-to-tests matrix
• The single draft report in the dedicated output folder

Release checklist

• Use a least-privilege connected identity.
• Keep source requirements read-only.
• Use stable IDs instead of titles or semantic similarity alone.
• Preserve source links, modified times, and actual test results.
• Test stale, duplicate, conflicting, inaccessible, and denied-write paths.
• Redact account data and sensitive document content from evidence.
• Require requirements-owner, QA, security, and release review as appropriate.

Final takeaway

The Cursor Google Drive plugin can reduce the manual work of locating requirements and drafting traceability evidence. Trust comes from the surrounding QA design: synthetic fixtures, least privilege, stable IDs, independent source checks, deterministic test results, negative-path coverage, and human approval. Automate discovery first; expand write capability only after the workflow proves it can be blocked safely.

Official sources

• Cursor Google Workspace plugins changelog
• Cursor plugin documentation
• Cursor Google Drive plugin listing
• Cursor permissions reference