The following post is a first-person account from Leapwork QA Architect Satpal Singh about how Leapwork Play changes the nature of his QA engineering work. Below, Satpal reflects on the nature, joy, necessity, and value of QA engineering based on his experience in the field. He also explains how Leapwork Play elevates the role of the QA engineer and how Play frees him up to focus more on the product than the framework.
One thing I’ve learned over my years in the QA engineering field is that QA engineers contribute far more than simply finding defects.
Many software teams use similar processes. A requirement is written, development builds the feature, and once the work is almost complete, it is passed to QA, to me.
I then write or update test cases, prepare the data, run the tests, report defects and wait for the fixes. Towards the end, I am asked whether everything has passed and whether I can approve the release.
The problem is that QA often enters the conversation too late.
By the time I start testing, the requirement has already been agreed, the design is complete, the feature has been built, and the release date has been committed.
I may then ask questions such as:
- What happens if the user does not have permission?
- What happens if another service is unavailable?
- What happens if customer data is old?
- What happens if the same action is performed twice?
These may sound like testing questions, but they are really product questions. They should be discussed before the feature is built, not after it reaches QA.
The true value of QA engineers
Over the years, I have realized that my real contribution is not the number of test cases I can create or execute. It is my ability to understand how the product works as a whole.
I remember previous incidents. I understand how customers use the product. I know which areas are more likely to break. I can often see how a small change in one place may affect something completely different.
A developer may naturally focus on the part they are building. As a QA engineer, I tend to step back and look at the complete journey. I think about the user, the data, the permissions, the browser, the integrations and what happens when something does not work as expected.
For me, that’s where QA becomes genuinely valuable, not when we’re executing tests, but when we’re helping the team understand risk before customers experience it.
However, much of our time is still spent maintaining scripts, fixing broken automation, preparing environments and waiting for features to become ready. Sometimes I know exactly what needs to be tested, but it takes longer to make the automation framework work than to understand the actual risk.
Why numbers do not tell the full QA story
We also place too much importance on numbers. Leaders often measure success based on metrics like:
- Number of tests created
- Number of tests automated
- Number of tests that have passed
These numbers are useful, but they do not tell the complete story. A team can run thousands of tests and still miss the one issue that matters most to the customer.
At release time, I want to explain what we have validated and where risk remains – not just report the number of passing tests
QA should help answer that question from the beginning of development, not only at the end.
How Play elevates my role
When I first began using Play, it was a pivotal moment in which my day-to-day work started to change.
I expected Play to make automation faster. What I didn’t expect was how much time it gave back to think about the product instead of the framework.
Instead of starting with technical questions about the test framework, I can start with the customer and ask questions such as:
- What is the customer trying to achieve?
- What could go wrong?
- Which part of the journey matters most?
- Which failure would damage trust?
- What evidence do we need before releasing the change?
Play helps me turn this thinking into validation without making the framework the center of my work.
It also allows me to become involved earlier. When a feature is still being discussed, I can help identify the main customer journeys, unclear behaviour and possible failure situations. I can raise questions while changes are still easy to make.
As development begins, I can work alongside the developer and validate the feature as it is being built. I do not have to wait for the full feature to be completed and handed over to me.
If something is missing, we can discuss it immediately. If the behaviour is unclear, we can agree on it before more code is written. If a problem appears, it can be fixed while the developer still has the full context.
This changes QA from being the last step into being part of the complete development process.
A typical day without Play
Without Play, I am involved mainly after the feature has already been built. Much of my day may be spent waiting for a feature to become ready, updating test cases, preparing data, repairing scripts and checking why automation has failed.
I test the feature, report defects, wait for another build and repeat the same tests. The pressure increases as the release date gets closer, and work discussions center more on how many tests have passed and whether I can provide sign-off.
Even after validating the test cases, i cannot confidently answer if this will work in production and if i trust this release.
A typical day with Play
With Play, my day starts earlier in the feature journey.
I take part in the initial discussion and help the team think about the customer journey, unusual situations and possible risks. I begin creating validation while development is still happening.
As the feature takes shape, I work with the developer, test the important behavior and give feedback immediately. I spend less time fixing frameworks and more time exploring the product, reviewing previous incidents and thinking about what the requirement may have missed.
I am no longer waiting at the end to approve the work. Instead, I am helping the team build the right behaviour from the beginning.
That is how Play elevates the role of QA. It does not reduce the need for QA engineers. It gives us more space to use our experience, judgment and understanding of the customer.
It allows QA to move from creating and executing test cases to understanding systems, identifying risk and building trust in the product.
With Play, I am able to answer confidently that this will work in production and i trust this release. That is the role QA was always meant to play.
Some practical examples of Leapwork Play changing QA’s role
Below, I discuss a few specific examples of the ways in which Leapwork Play directly improved my work.
A simple login page change
I remember one release where the application login page changed. In our DIY Playwright framework, the login flow was already centralized, so it wasn’t a difficult change. Even so, we still had to update the shared login helper, validate the authentication setup, regenerate the storage state, rerun regression tests and verify the CI pipeline. By the time everything was complete, we had spent around 2–4 hours on what was essentially a small UI change.
With Play, we designed the login flow as a shared reusable test case. When the login page changed, we simply recorded the new UI step once in the shared login flow. Because every scenario reused that same login flow, the update was automatically applied across all dependent tests.
The maintenance itself took about one to two minutes.
That experience reminded me that reducing maintenance isn’t just about saving engineering hours. It gives QA engineers more time to focus on understanding product risk instead of maintaining automation.
A small UI change with a much bigger impact
Another incident showed me a different kind of challenge.
We were slightly altering the name of an application. Our login validation was checking for the original application name before continuing with the login flow, and we didn’t notice the change before the scheduled regression started.
Because every test began with the same login flow, they all failed at the same point.
The regression suite continued running for more than six hours before the execution completed. The problem itself was only a text change, but the impact was much bigger. The execution environment remained occupied for hours, compute resources were consumed unnecessarily, and the team didn’t receive failure feedback until the suite had finished.
With Play, I could immediately open the failed login step, review the screenshots and execution details, and identify the root cause without reproducing the entire execution.
I could also share that exact failed step with another engineer, allowing them to investigate the issue without setting up the automation project first.
The discussion quickly moved from “Why did the automation fail?” to “Why did the application behavior change?”
Investigating failures becomes much simpler
I also noticed a significant difference when investigating failed executions with Leapwork Play versus without it.
As a QA engineer, I don’t want to spend my time figuring out how to debug a failed test. I want to spend my time understanding why the feature failed.
With Play, every failed step provides the context I need: screenshots, execution details, and the exact point where the failure occurred.
I can jump directly to that step, understand what happened, and even share that specific failed step with another engineer. They can immediately start investigating without reproducing the entire execution or understanding the automation implementation.
With a typical DIY Playwright framework, the HTML report is usually just the starting point.
To investigate further, another engineer often needs the automation project, the framework, the required dependencies, and a local environment before debugging can begin.
The defect itself may be simple, but understanding the failure often takes longer than fixing the actual issue.
Instead of only reporting that tests passed, I can explain which customer journeys have been validated, what we learned about the feature, and where some risk may remain.
The latter, to me, is much more indicative of QA engineering’s role in the SDLC, as well as its utility as a whole. Try Leapwork Play yourself and see how it changes your QA work for the better.
