Home Blog Digital Product How to use MCP and AI to speed up testing in your digital product?

How to use MCP and AI to speed up testing in your digital product?

In this episode of Agile Product Builders Tech Edition, Piotr, co-CEO of Boldare, explores the evolving landscape of quality assurance (QA) in the age of AI with Milena Cylińska, a seasoned QA engineer with over a decade of experience. The discussion centers on Model Context Protocol (MCP), an innovative API connecting large language models (LLMs) with various tools to streamline QA workflows. Milena demonstrates how AI-powered agents can assist in manual and automated testing, helping QA engineers focus on strategic tasks while maintaining high-quality software development.

Table of contents

Piotr: Hi, I’m Piotr, co-CEO of Boldare. You’re watching Agile Product Builders Tech Edition, a 25-minute series for today’s product builders. This time, we might stretch the time box a bit because MCP is best understood when you see it in action. Our Swiss guests are going to show us that, so I hope you’ll forgive the slight delay.

In this episode, we’re diving into the world of quality assurance in the age of AI. In particular, we explore how Model Context Protocol (MCP), a new API for LLMs, is reshaping the way QA engineers test and ensure product quality.

Our guest today is Milena Cylińska, a QA engineer with over 10 years of experience, and someone I’ve had the pleasure of collaborating with on several projects. What makes Milena stand out is her mission-driven approach. She’s not here to build massive testing departments or create bottlenecks. Instead, she embeds quality into every step of the software development lifecycle, and above all, she’s a true builder.

So, Milena, it’s great to have you here. Welcome to the show.

Milena: Thank you for the invite.

Piotr: Let’s start simple. Could you briefly introduce yourself and tell us how you became interested in experimenting with AI tools?

Milena: Sure. I think you gave a pretty good introduction, so thanks for that. I’m basically a QA engineer, and I’ve been helping companies with their QA processes, test automation, and all the magic that happens around assuring quality.

What brought me to AI… the short story is that I realized Playwright MCP existed, and ChatGPT before that. The longer story is that my journey started in 2018, when I went to a QA conference about AI with my friends. I must admit I wasn’t very excited at the time. Listening to all those speeches, I didn’t see it coming that we could actually use AI on a daily basis as we do nowadays. Back to the main topic—my real hands-on use of AI in daily tasks began when Playwright MCP was released.

What Model Context Protocol is and why it matters

Piotr: Okay, so the Playwright MCP was this “aha” moment. That’s really nice. For those who aren’t familiar with Model Context Protocol, could you describe it in simple terms? How would you explain it to other QA engineers or engineering managers?

Milena:

People like to call it the “USB-C” or “OpenAI standard” that connects LLMs with different tools. By different tools, I mean it could be a database, a browser, or even just another app. This connection allows LLM models to actually perform tasks for us.

For example, if you picture ChatGPT, you can ask questions and get answers, but ChatGPT itself won’t, say, go and book a flight for you because it’s missing this connection. That’s exactly what MCP does—it’s basically the connector between AI and other tools.

How AI agents support testing and automation

Piotr: Okay, so the Playwright MCP was this “aha” moment. That’s really nice. For those who aren’t familiar with Model Context Protocol, could you describe it in simple terms? How would you explain it to other QA engineers or engineering managers?

Milena: People like to call it the “USB-C” or “OpenAI standard” that connects LLMs to different tools. By different tools, I mean it could be a database, a browser, or even just another app. This connection allows LLM models to actually perform tasks for us.

For example, if you picture ChatGPT, you can ask questions and get answers, but ChatGPT itself won’t, say, go and book a flight for you because it’s missing this connection. That’s exactly what MCP does—it’s the connector between AI and other tools.

Piotr: So, can you tell us how this works in your daily QA workflow?

Milena: Sure. I actually have a demo for you—let me share my screen. We’re going to see how MCPs work and how we can embed them in QA processes. This is a very simple example because we’ll be testing my own website.

I won’t show you how to install everything, but it’s quite simple. In VS Code, under Extensions, there’s a section for MCP servers. I’ve installed three that we’ll be using, but you can also browse many others. Highly recommended—it’s easy to set up. This was one of the things that drew me into experimenting with AI: how simple it is to get an MCP running.

For this demo, we’ll be using three MCPs: Playwright MCP, GitHub MCP, and Linear MCP, to automate a basic QA flow. Normally, we start by searching for a Jira ticket (or any project management ticket), write test cases for it, explore the app manually, automate the test cases later, and finally commit changes and create a PR.

Piotr: So basically, from the IDE you’re showing, you can access GitHub, Linear, and Playwright through LLMs—all in one enhanced environment?

Milena: Exactly. For this, I “hired” two agents. One is a manual tester, who creates test cases, does exploratory testing, and files bug tickets if necessary. The other is a Playwright tester, our test automation agent.

We define the agents in a simple MD file, specifying their roles, tasks, and the tools they can use. For example, the manual tester uses the three MCPs and can also search or edit the repository. I also include guidance to prevent hallucinations and ensure the output meets expectations, including security constraints like never revealing API keys.

The workflow is strict: first, the agent gathers context by reviewing the codebase, then uses Playwright to navigate the app. Next comes test planning with Linear to gather acceptance criteria and convert them into test scenarios. Then exploratory testing is performed, including edge cases, followed by test case design. Finally, any bugs found are checked against existing tickets to avoid duplicates.

The second workflow is for test automation. The agent converts manual test cases into Playwright scripts, following best practices and the page object pattern. The agent also stabilizes the tests by running them, detecting flakiness or incorrect locators, and fixing issues autonomously. After all tests run, the agent commits the changes and creates a PR.

Piotr: So basically, you could go to the Swiss Alps, enjoy the sun, and the agents would do the work for you.

Milena: Yes, kind of—but let’s see how it works. I prepared a quick prompt, and on the right side, you can choose which agent to run. We start with the manual tester, who gathers context, writes test cases, and does exploratory testing. I set the workflow to run only for the home page.

When the agent runs, it asks for permission to use the MCPs. You can allow each action individually, for the session, or always. I clicked “allow,” and it opened my website and took a screenshot, as I instructed. Then it searched Linear for the ticket with “home” in the name, retrieved context, and converted the acceptance criteria into test scenarios, flagging any missing context.

Next, the exploratory testing should run automatically, navigating the app and testing inputs, like mandatory fields. It also takes screenshots, which are saved in the Playwright MCP folder. The findings from exploratory testing are collected, and the workflow moves to test case design.

Boosting Efficiency

Piotr: It’s still running while it works, right? You know, it still amazes me that you can reach different contexts and have everything work together. Can you tell us how much time this approach saves?

Milena: It really depends. You do need some pre-work, like making sure your documentation is ready so the agent gets proper context—that’s very important. From my perspective, because I work on many projects with many companies, there’s often a similar onboarding process for each project.

Tasks like this—getting context, creating documentation, writing test cases, and automating them—can be 60–70% faster. Sometimes I save days. QA engineers would agree that creating documentation, especially test cases, is very time-consuming and can be a bit boring.

I treat this as a base. It allows me to focus on edge cases, talking with the business to understand context, participating in user interviews, and getting closer to what users actually need. These base test cases would apply to maybe 95% of the websites I test, while I can focus on the things that are very specific to the business.

Piotr: Yeah, and you mentioned documentation. It really needs to be up to date. Nowadays, developers are using documentation too, and some are even automating it. With AI, we can share artifacts more easily and focus on things like edge cases, just as you said.

How AI shifts the QA role to higher-level decision making

Piotr: So, what do you think? Is it possible that in a few years your job might no longer involve actual testing, and you’d just be orchestrating agents through MCP or similar AI tools?

Milena: Honestly, maybe if I were only testing my own website, that could work. It’s a cool approach and saves lots of time, letting you focus on more creative tasks. But I don’t think most projects today have the capacity to fully apply this approach. Often, as you mentioned, documentation is missing.

With AI-assisted flows, we need to shift our work left in the software development lifecycle. We have to focus more on documentation, refine requirements, and keep tickets organized. Testing is only part of the QA role—it gives some breathing room, but I still think manual checks are important. After all, we’re creating software for people, and you want to maintain that human touch. Development might be easier for AI to take over, but with testing, I’m still hesitant.

Piotr: Okay, so ownership remains with you, and you can’t fully let it go. Also, as you mentioned, most of the work requires context and documentation before automation. When that’s in place, do you feel your QA role becomes more strategic, or is it just faster work with the tool?

Milena: I’d say it’s both.

It’s definitely faster, but it’s also more strategic. I focus on reviewing what AI produces, and I spend more time on the business side—requirements and documentation.

Even when I create chat modes for the agents, you still need skills beyond test automation: test management, best practices, and coding knowledge—but from a supervisory perspective, overseeing the process. So yes, it’s definitely strategic. And of course, it’s much faster to review AI outputs than to create everything from scratch.

Getting Started with MCP

Piotr: Okay, last question—if someone has never tried MCP with Playwright or other tools, what’s your advice? How should they start?

Milena: I think the way I started worked well, so I’d recommend it. Definitely try VS Code and experiment with Playwright MCP. It’s a really interesting experience. Playwright MCP also has tons of YouTube videos and other learning materials you can reuse, so that would be my go-to starting point.

SUMMARY & KEY takeaways:

The conversation with Milena highlighted how AI, through Model Context Protocol (MCP), is reshaping the daily life of QA engineers. By connecting AI models to tools like Playwright, GitHub, and Linear, MCP allows teams to automate repetitive testing tasks, reduce errors, and focus on more strategic, high-value work. The demo showed not just speed gains, but also how AI agents can assist in planning, exploratory testing, and even creating automated scripts, all while requiring careful setup and human oversight.

Key Takeaways:

  • MCP Enables Integration: Connects AI models with multiple QA tools for seamless workflow.
  • Automation of Routine Tasks: Agents handle exploratory testing, test case creation, and script automation.
  • Time Savings: Processes can be completed 60–70% faster, freeing engineers for strategic activities.
  • Strategic Oversight Remains Key: Human judgment is crucial for edge cases, documentation, and final QA decisions.
  • Accessible Learning Path: Hands-on experimentation in VS Code and Playwright MCP is the best way to get started.

Overall, Milena’s insights reveal that AI is not replacing QA engineers but amplifying their impact. By handling repetitive tasks, it allows engineers to focus on creative problem-solving, business context, and user-centered testing, keeping quality assurance both efficient and human-driven.

Piotr: Great, thank you. Milena, thank you for showing us how MCP works for QA engineers. It’s really fascinating. I wish we had more time to see even more, but this glimpse alone is impressive. It’s amazing to see how many aspects today’s tools can reach and how they help us work faster and focus on what truly matters.

Thank you for sharing your insights with us. If anyone in the audience is curious about MCP, let us know—we can help, and Milena can point you to additional resources if needed.

Thank you very much! This was Agile Product Builders Tech Edition. I’m Piotr, and this was Milena. See you next time. Bye!

;