The hidden cost of DIY plugin testing: Why we stopped using raw Selenium and Playwright and switched to MimicQA

The hidden cost of DIY plugin testing: Why we stopped using raw Selenium and Playwright and switched to MimicQA

By Dmitry Vasilev
Apr 04, 2026

Building a successful e-commerce extension is hard. Keeping it stable as you add updates is even harder.

When we first built our WooCommerce Barcode Scanner plugin, we knew that testing it by hand would not be enough long-term. We needed automation to catch bugs before they reached thousands of live online stores. Like most engineering teams, our first idea was to use standard code tools like Selenium and Playwright.

It seemed like the logical choice. Instead, it almost broke our development cycle.

Our developers were wasting 40% of their coding time just fixing broken test setups instead of building new features. In retrospect, moving away from code-driven automation to our specialized service at UkrSolution - powered by our human-simulating browser framework, MimicQA - was the best business decision we ever made.

Here is exactly what went wrong with our old testing tools, and the lessons we learned moving to a human-simulated testing system.

1. Developers should not design user journeys

At first, our main plugin developer was responsible for writing the automation tests. He knew the code perfectly, which seemed like a good thing.

However, we quickly found a major problem: developers do not truly understand how a busy warehouse worker or a stressed cashier uses software.

The test flows our developer wrote were too perfect. They did not match real-world chaos.

The Solution: We developed and switched to the MimicQA Chrome Extension. This tool allows our team to create automated tests without writing code. Suddenly, our manual QA specialist and support manager could build the automated tests. Because they spend all day “watching” user frustration, they created test scenarios that perfectly matched real-world users.

2. The 40% developer productivity trap

As we added more features to our plugin, our Selenium tests became longer and more complex. We did not expect the massive amount of work needed to maintain them.

Every small change to a button, layout, or setting broke the test scripts. Our lead developer went from writing new features to spending 40% of his work week repairing broken tests. The old testing method was slowing down our development process significantly.

The Solution: Moving our testing to the MimicQA platform completely removed this workload. Today, if a user interface element changes, it can be adjusted easily by anyone in the team (e.g. by manual QA or support manager). Our engineering team can now focus 100% on building new features and working on new plugin ideas.

3. The fast execution "black box"

Running raw Selenium tests was very complicated. At the beginning, only technical developers could start them. Later, our developer created a launch button for us so our QA manager could run it too.

But the results were a mystery. Because these code frameworks care only about speed, they run lightning-fast behind the scenes.

When a test failed, watching the video reply was useless. It looked like a fast blur of flickering screens. In 50% of test failures, our manual QA team could not understand what went wrong without help. We had to ask a senior developer to stop his work and look at complex server logs and error codes to find the issue.

The Solution: We built MimicQA to stream a human-speed, live video feed natively inside your browser extension while the test runs on our cloud servers. Because the extension highlights the exact written step directly on top of the live video stream, you can see and read exactly what the system is testing at that exact millisecond. Debugging is fully visual. Anyone on the team can watch the playback and instantly see exactly where a user path broke without looking at a single line of server code.

4. Fixing the nightmare of "false positive" failures

Tools like Playwright and Selenium are obsessed with fast execution speed, not user behavior accuracy. They click elements instantly before a web page has even finished loading on the screen.

Because of this robotic speed, we had many false positives. This means tests failed even when our plugin had no bugs, simply because the testing script clicked a button a millisecond too early.

The Solution: We built the core MimicQA engine around true human-simulation. The framework moves mouse cursors across natural, curved lines and adds realistic pauses before and after clicks, keystrokes, and form submissions. By choosing human accuracy over mechanical speed, 99% of our false-positive bugs completely disappeared.

5. Confusing text documentation and hidden scripts

"What exactly does this automated test cover right now?"

For a long time, if I asked my developer that question, his answer was always: "Let me open the source code and read it for you." Every single time I asked, he spent 15 minutes explaining lines of code to me.

We tried to create a separate document where I described the test scenarios in writing. But I could not describe 100% of every action. There were always missing parts between my text document and the actual test code.

The Solution: The MimicQA dashboard removes this confusion. Our platform combines your written documentation (the test plan) and the live test execution into one single place. Because they are joined together, there are no gaps or mismatches between what you plan and what the code actually tests.

Even better, while the test is running, the Google Chrome extension highlights the exact step currently being tested directly on the video stream. This means you can look at the screen and read exactly what is happening in real-time. It displays current test action like a clear table of contents in a book:

At a glance, anyone-from a business owner to a client support manager - can read the step-by-step navigation list. You can see exactly what is being tested, on which page, and under what conditions.

The Verdict: Automated QA should not cost your sanity

Automated testing is supposed to give your development team freedom, not trap them in endless maintenance loops. Trying to build and maintain a raw code testing framework yourself can ruin your product schedule.

By using MimicQA through our managed service, we achieved the ultimate reward: Any team member can click "Run" from a simple browser extension, watch the test in real-time, and ship safe plugin code with total confidence.

Write your question or comment:

guest