Scopepath QA

Scopepath QA helps QA engineers turn a PR or Jira ticket into a focused QA review, test plan, and test cases inside VS Code.

Website: scopepath-qa.lovable.app

Support: GitHub Sponsors

What You Get

Scopepath QA is for daily QA work, not only documentation.

It helps you:

• understand what changed
• connect PR changes to Jira context
• read Jira comments, epics, linked issues, and Confluence references
• detect risk and missing coverage
• reuse context from similar past tickets
• choose the right test plan type
• create test cases from that plan

The result should be usable as a review artifact, QA handoff, or test design draft.

First Run

After installing the extension, run:

Scopepath QA: Check Requirements

The extension verifies:

• Atlassian MCP for Jira and Confluence
• GitHub MCP for preferred PR analysis
• authenticated gh fallback when GitHub MCP is not available
• VS Code code command for automatic chat launch

If something is missing, Scopepath QA guides the next step:

• open MCP settings
• open GitHub CLI download
• open a terminal for gh auth login
• explain missing VS Code code shell command

Use this when PR analysis fails:

Scopepath QA: Check GitHub Provider

It shows:

• GitHub MCP detected
• GitHub MCP server keys
• gh installed
• gh authenticated
• selected provider
• fallback status

Main Commands

• Scopepath QA: Check Requirements
• Scopepath QA: Check GitHub Provider
• Scopepath QA: Configure Project Context
• Scopepath QA: Analyze Pull Request
• Scopepath QA: Analyze Jira Ticket
• Scopepath QA: Create Test Plan
• Scopepath QA: Create Test Cases
• Scopepath QA: Open Last Analysis

Configure Project Context

Run:

Scopepath QA: Configure Project Context

Use it once per project to save:

• app repository
• automation repository
• Jira project key
• Jira site
• automation framework
• local memory paths

This creates .masq/project.yml.

It does not store credentials.

Scenario 1: Development PR With Jira

Use when a developer sends a PR linked to a Jira ticket.

Run:

Scopepath QA: Analyze Pull Request

Inputs:

• PR URL: https://github.com/acme/app/pull/123
• PR type: Development
• Jira ticket: PAY-4512

Scopepath QA should:

• read the PR diff against base branch
• collect changed files and comments
• read Jira description, comments, epic, links, and Confluence
• compare against local memory and similar historical tickets
• summarize risk and existing coverage
• recommend one plan type

Example result:

Change Overview
PR #123 changes repayment agreement behavior for voucher carry-over.

Business Context
PAY-4512 clarifies that agreements must persist across voucher state changes.

Current Coverage Observed
Existing automation covers happy-path agreement creation only.

Risk Assessment
Regression risk is high around carry-over, expired vouchers, and agreement status transitions.

Recommended Next Step
Regression

Next Action
Choose the plan type to generate now:
Smoke / Regression / Exploratory / Automation / Performance

If you answer Regression, Scopepath QA continues in the same chat and creates the regression test plan.

Then it asks:

Do you want to create test cases from this plan?

If you answer Yes, it creates test cases from the analysis, PR, Jira context, and generated plan.

Useful final outputs:

• QA review summary
• risk assessment
• generated test plan
• generated test cases when confirmed

Scenario 2: Development PR Without Jira

Use when a developer sends a PR but no ticket is linked.

Run:

Scopepath QA: Analyze Pull Request

Inputs:

• PR URL: https://github.com/acme/app/pull/124
• PR type: Development
• Jira ticket: empty

Current behavior:

• Scopepath QA requires Jira for development PRs
• it stops before analysis
• it does not invent business context
• it does not create an empty artifact

Expected message:

A Jira ticket is required for development PR analysis

Why:

• development changes need business intent
• Jira comments and acceptance criteria define expected behavior
• without Jira, the review would be incomplete

Useful final output:

• clear blocker
• no hallucinated test plan

Scenario 3: QA Automation PR Without Jira

Use when a QA sends a PR that changes automated tests.

Run:

Scopepath QA: Analyze Pull Request

Inputs:

• PR URL: https://github.com/acme/automation/pull/88
• PR type: QA Automation
• Jira ticket: empty

Scopepath QA should:

• review changed automation files
• identify what coverage was added or changed
• inspect framework patterns from project context
• detect flaky patterns or weak assertions
• identify overlap with existing coverage
• avoid new test code generation

Example result:

Automation Review
PR #88 adds Playwright coverage for repayment agreement creation.

Coverage Observed
The PR covers the main happy path but does not validate expired voucher behavior.

Quality Risks
Assertions depend on visible text only. Test data setup may be brittle.

Gaps
No Jira ticket was provided, so requirement alignment cannot be fully confirmed.

Recommended Next Step
Exploratory or Regression

Useful final output:

• automation PR review notes
• coverage gaps
• reviewer feedback

Scenario 4: QA Automation PR With Jira

Use when a QA automation PR should be checked against the original requirement.

Run:

Scopepath QA: Analyze Pull Request

Inputs:

• PR URL: https://github.com/acme/automation/pull/89
• PR type: QA Automation
• Jira ticket: PAY-4512

Scopepath QA should:

• read the automation PR
• read Jira and linked context
• compare automation coverage against acceptance criteria
• detect duplicated scenarios
• identify missing manual or automation validation
• recommend the next useful plan type

Example result:

Automation Alignment Review
PAY-4512 requires repayment agreement validation across voucher states.

Coverage Added
PR #89 adds Playwright tests for agreement creation and update.

Alignment
Coverage partially matches Jira acceptance criteria.

Missing Coverage
No scenario covers expired vouchers, carry-over failures, or permission edge cases.

Recommended Next Step
Regression

Useful final output:

• requirement-to-automation review
• missing coverage list
• review-ready feedback

Scenario 5: Jira Ticket Only

Use when there is no PR yet, but QA needs to design validation.

Run:

Scopepath QA: Analyze Jira Ticket

Input:

• Jira ticket: PAY-4512

Scopepath QA should:

• read ticket summary and description
• read comments and decisions
• inspect epic and linked issues
• collect linked Confluence context
• search similar historical tickets
• compare against local memory
• recommend one plan type

Example result:

Story Summary
PAY-4512 defines repayment agreement handling for voucher carry-over.

Business Rules
Agreement state must persist when voucher state changes.

Similar Past Work
PAY-3880 covered agreement creation but not carry-over behavior.

Reusable Coverage
Existing regression cases can be reused for agreement creation.

New Coverage Needed
Add scenarios for carry-over, expired vouchers, and permission handling.

Recommended Next Step
Regression

Useful final output:

• story analysis
• reusable coverage notes
• plan recommendation

Plan Types

After analysis, Scopepath QA asks which plan type to generate:

• Smoke: critical-path checks
• Regression: impacted modules and reusable historical coverage
• Exploratory: charters, heuristics, and risk probes
• Automation: automation candidate scenarios only
• Performance: workload, NFR, and endpoint/workflow scenarios

In the normal flow, you answer in the same chat and Scopepath QA generates the selected plan.

Scopepath QA: Create Test Plan remains available when you want to generate a plan later from an existing analysis artifact.

Test Cases

After creating the plan, Scopepath QA asks whether to create test cases.

In the normal flow, answering Yes generates test cases in the same chat.

Scopepath QA: Create Test Cases remains available when you want to generate cases later from an existing plan artifact.

Expected outputs:

• Smoke: concise validation cases
• Regression: structured reusable cases
• Exploratory: charters and observation prompts
• Automation: automation candidate cases only
• Performance: scenario cards with workload and success criteria

Scopepath QA does not generate repo test code by default.

Saved Outputs

Scopepath QA uses .masq/ inside the workspace.

Common files:

• .masq/project.yml
• .masq/context/context-*.md
• .masq/testplans/test-plan-*.md
• .masq/testcases/*
• .masq/memory/index.json

Use:

Scopepath QA: Open Last Analysis

to reopen the latest analysis artifact.

Failure Rules

Scopepath QA should stop early when required providers are missing.

It should not create:

• empty context artifacts
• test plans before analysis
• test cases before a plan
• repo test files
• implementation code

Provider failures should be shown clearly:

• GitHub MCP unavailable
• gh missing or unauthenticated
• Atlassian MCP unavailable
• VS Code code CLI unavailable