AI-assisted QA workflow - orchestrating MCPs for testing

You know how testing can feel like a never-ending repetitive actions of writing the same scripts, updating tests after every feature tweak, and moving tickets back and forth on the board.

In my opinion, that’s where Model Context Protocols (MCPs) come in. I like to picture it as a connector, a standard contract between AI assistant and other tools, which allows you to pull docs, manage tickets, perform actions in a browser, connect to a database and manage your PRs.

One thing must stay clear here: MCPs is not a magic wand, a free pass to skip fundamentals. It's another tool. Solid project documentation, clear requirements, programming knowledge and human review are still the backbone of good QA. AI can improve your workflow, but if your inputs are weak, the outputs will be too.

This post:

• Shows some MCPs that help with QA

• Walk through an orchestrated workflow from docs → tickets → tests → automation → bug reports

• Share working .chatmode.md examples you can copy-paste

• Drop some pro tips for prompting and keeping AI helpful (not hallucinatory)

  
  

Who actually gets the most out of this?

• Small dev teams without QA help → offload simple base test coverage to AI agents.

• QA engineers & SDETs → automate the repetitive tasks (like tickets status updates) and free yourself to focus on the edge cases.

• Teams with fresh documentation → The better your docs/tickets, the smarter your AI output. (If your Confluence is a ghost town, results will suck.)

If your project is documented well, AI-assisted workflows are for you.

A Quick MCP Primer

At its core, MCP is just an open protocol for AI apps to talk to tools and data. Picture your AI assistant as the “host” and Linear, GitHub, or Playwright as “servers” it can call into.

Instead of hard-coding integrations, the AI discovers available tools at runtime, and you control what it can and can’t do.

Example MCPs That Make QA Shine

• GitHub Copilot (Coding Agent) - it can see your repo’s PRs, issues, and even run Playwright tests. Bonus: Copilot Spaces lets you pin docs, code, and instructions into a single “context bubble.”

• Linear MCP - This one connects your project management tool straight into your AI. You can ask it to create a bug ticket for you, update its status or add a Confluence document.

• Playwright MCP - it gives your AI agent the power to browse your app, click buttons, fill forms, take screenshots.

Orchestrated QA Workflow

Here’s what a full MCP-driven pipeline looks like when you stitch it together:

1. Context Gathering: AI pulls in docs + your code base. Now it knows what's your project about.

2. Test Planning: Pulls Linear tickets. Summarizes acceptance criteria into a list of test scenarios.

3. Exploratory Testing: Uses Playwright MCP to poke around the UI, try weird inputs, and surface edge cases.

4. Test Case Design: Converts docs + exploratory notes into structured test cases (steps + expected results).

5. Automated Test Execution: Agent writes Playwright TypeScript tests and runs them.

6. Bug Reporting: Failures? The AI logs a Linear ticket automatically, attaches a screenshot, and links to the failing test.

7. Refinement: The loop runs again with each feature update, growing your automation suite.

That’s QA with way less grunt work.

Chatmodes for Testing Agents

Let's create 2 agents - a manual tester and a test automation engineer and make them work for us.

Manual tester agent:

Think of this mode as: “Give me a super diligent QA buddy who can explore the website like a manual tester, organize what to test, try odd inputs, and draft bug reports.”

What it does (in simple terms):

• Opens the target website (https://www.scale-qa.com) and takes a baseline look.

• Reads the project’s code/docs to understand how things are supposed to work.

• Looks up feature tickets (in Linear) and turns their acceptance criteria into test ideas.

• Does exploratory poking: tries long text, weird characters, invalid formats, rapid clicking, etc.

• Writes clear test cases (step-by-step “do this, expect that”).

• Prepares or files bug tickets with: steps to reproduce, what went wrong, expected behavior, screenshots.

• If it can’t create a ticket automatically (no permission), it gives you a ready-to-paste bug report.

What you give it:

• (Optionally) a feature or area to focus on.

• (Optionally) any links or known issues.

What you get back:

• A short summary of what it found.

• Test scenarios and structured test cases.

• A list of bugs (with evidence) or “no issues found”.

• Suggested next steps (e.g., “these 3 should be automated”).

When to use it:

• Early-stage feature review.

• You’re not sure what to test yet.

• You want professionally formatted test cases or bug reports without writing them yourself.

You DON’T need to know:

• How Playwright works.

• How Linear’s API works.

• Any AI tooling internals.

Test automation agent:

Think of this mode as: “Now that we know what to test, please write solid, maintainable Playwright automated tests in TypeScript—and only after checking how the app really works.”

What it does:

• Scans the repo for existing test setup (config files, helpers).

• Opens the site and inspects the real page structure to pick good, stable selectors (like labels and roles, not fragile CSS).

• Designs or updates “page object” helper functions (reusable actions like login, add item, etc.).

• Writes Playwright test files that follow best practices (clear steps, no flaky waits, accessible selectors).

• Runs the tests locally (in this environment) and tries to fix flakiness.

• (If allowed) creates a branch + commit + pull request with a clean summary.

• If something’s missing (e.g., no good selector), it marks TODOs instead of guessing.

What you give it:

• One or more structured test cases (from the Manual Tester mode or your own). Example: Title, Steps, Expected Result.

What you get back:

• The test code (TypeScript).

• A mapping: “Test Case X → File Y”.

• Locator checklist (proof it inspected the UI).

• A ready-to-open PR (or a patch and exact git commands if it can’t push).

When to use it:

• After manual test cases are agreed upon.

• To grow or refactor your automated test suite.

• To standardize how tests are written.

You DON’T need to:

• Write selectors yourself.

• Understand advanced Playwright patterns.

• Babysit the process step-by-step (it’s designed to run end-to-end unless blocked).

How they relate (simple analogy)

If you need...	Use This Mode	Analogy
“Figure out what to test and whether it’s broken.”	Manual Tester	A meticulous QA colleague
“Turn approved scenarios into repeatable automated scripts.”	Playwright Automation	A senior test automation engineer
“Bug report with reproduction + screenshots.”	Manual Tester	Filing a ticket with evidence
“Page object + test code that fits existing repo conventions.”	Playwright Automation	Adding polished code to the test suite

They’re complementary: Manual Tester discovers and structures; Playwright Automation codifies and enforces.

Both modes will explicitly say what they’re missing instead of guessing (e.g., “Need a stable selector for the Submit button—please add data-test='submit'”).

Pro Tips

• Be specific with prompts - AI loves structure. Always say what role it’s playing, what format you want back, and give an example.

• Choose a proper model - if the outputs you get seem too generic, high-level or halucinate too much, check if you're using a proper model for what you're trying to achieve. Use this guide to choose the right one.

• Stay grounded - the better your project management tool hygiene, the smarter your AI output. Out-of-date docs = nonsense test cases.

• Secure wisely - only enable MCP servers you actually need. Don’t give the AI write access everywhere unless you’re sure.

• Iterate - let AI handle the boilerplate, but always review. Human-in-the-loop makes the difference between “neat demo” and “production-ready QA.”

• Use AI-assisted QA workflows to force proper project documentation - implementing this approach to QA implies the need of having proper, up-to-date documentation. This forces everyone to document their decisions and work. This can solve many project management projects, improve transparency, build a knowledge base that could improve new team members onboarding etc.

The Road Ahead

Right now, MCPs let one AI agent talk to your tools. The next wave is Agent-to-Agent (A2A) — think your “test planner agent” chatting with your “automation agent” and your “bug reporter agent.” They coordinate, split tasks, and keep each other honest. That means in the not-so-distant future, your QA flow could be: new ticket lands → planner agent outlines cases → automation agent codes tests → bug agent files issues. All happening in sync, all standards-based.

QA is always going to need human judgment, but MCPs let you offload the boring parts. With orchestration, you can go from docs and tickets all the way to automated tests and bug reports in one flow. Less grunt work, changing apps and context, faster feedback, smarter coverage. That’s the promise of MCP-assisted QA.