From Handover to Collaboration: Rethinking Test Automation in Low-Code Engineering

Who owns software quality

The obvious answer is: everyone involved in building the product. In reality, the responsibilities are already not completely separate. Our Pega developers test the software they build and write unit tests as part of development, while QA colleagues bring additional testing expertise and take responsibility for broader levels of verification. But as we move further from unit testing towards automated integration and end-to-end verification, responsibilities can become more separated. A developer implements a feature, further verification is handed over, issues come back to Development, fixes return to testing and every additional handover can create another feedback loop, dependency and potentially more waiting. So our starting point isn’t “developers should start testing.” They already do. The question is how far we can sensibly extend that existing ownership.
This becomes particularly interesting in a low-code environment. Low-code developers can build sophisticated applications without spending most of their day writing traditional programming languages such as Java. Test automation, meanwhile, often lives in a more traditional software engineering world: source code, Git, test frameworks, pipelines and APIs. What happens when we bring those worlds closer together? That is something we want to explore with a small test automation pilot for our Pega engineers and QA colleagues. What if Pega developers could contribute not only to unit-level verification, but increasingly to automated integration and end-to-end testing as well? The earlier we can verify whether something works as expected, the shorter the feedback loop becomes. And the more repeatable verification we can automate, the more we can use human testing where human judgement creates the most value. And the goal is bigger than learning another tool.

Does that mean developers become testers?

No! And this distinction matters. Our aim isn’t to turn every Pega developer into a test automation specialist. We think about it as T-shaped engineering. Engineers continue to have deep expertise in their primary discipline. For our Pega developers, that remains Pega and low-code application development. But they can complement that depth with broader engineering capabilities around it. Automated testing is already part of that engineering skill set through unit testing. The pilot explores whether we can broaden this capability towards integration and end-to-end test automation. A developer doesn’t need to become the team’s testing expert to understand how their feature is verified, contribute an automated test, debug a failing test or work effectively with the colleagues who specialize in quality engineering. The aspiration is simple: I built this. I tested it at unit level. I understand how it needs to be verified beyond that. I can contribute to that automation as well. And I can work with QA colleagues where their specialist testing expertise adds value.

And does this mean we need QA less?

This is where conversations about shifting quality left can easily go in the wrong direction. We don’t see broader testing capabilities among developers as an argument for making QA expertise obsolete. Quite the opposite. Experienced QA engineers bring deep testing expertise: different ways of thinking about failure, an ability to challenge assumptions, and a strong perspective on how users may actually interact with a system. These are capabilities we want to spread across the team, rather than keep within a single role. QA colleagues can play an important role in making that happen. As testing experts, they can mentor and pair with developers, share testing techniques and ways of thinking, and help them build these practices into their everyday engineering work. Over time, the aim is for developers to apply more of this thinking independently, while QA continues to provide deeper expertise, coaching and support where it adds the most value. The opportunity is therefore not to transfer QA work to developers, but to transfer knowledge and broaden capability so that quality is increasingly built in throughout development rather than owned by one role or checked at the end. If developers can take greater responsibility for repeatable automated verification, QA specialists can increasingly collaborate with them on test strategy, difficult scenarios, exploratory testing and the quality of the automation itself. The distinction we find useful is this: Quality expertise can be specialized. Quality ownership should be shared.

Low-code makes the challenge more interesting

There is another dimension to this experiment that we find particularly interesting. For a traditional Java developer, moving into Java-based test automation may be a relatively small technical step. For a low-code developer, the distance can be greater. A Pega engineer may understand application architecture, business processes and platform behaviour deeply while having much less day-to-day exposure to Java, Maven, Git-based development or a code-heavy automation framework. We shouldn’t underestimate that difference. So simply putting developers into a test automation course and expecting them to emerge as independent automation engineers would be unrealistic. Instead, we want to understand a more useful question: What level of test automation capability is valuable and achievable for a low-code engineer? Finding that boundary is one of the reasons to run a pilot rather than start with a broad rollout.

Training alone won’t change how a team works

This may be our most important hypothesis. A course can teach a skill. It doesn’t necessarily create a new habit. People forget skills they don’t use. And a developer who learns test automation but returns to a team where someone else continues to handle all automation is unlikely to retain much of that knowledge. So we’re treating the initiative as a learning journey rather than a training event: Prepare → Train → Onboard → Pair → Apply → Measure Preparation matters because low-code developers may first need foundations in areas such as Java and Git. Training provides the technical concepts and hands-on experience. But the critical stages happen afterwards. Participants need to work with their team’s real test automation environment. They need to understand its architecture and conventions. They need experienced colleagues to pair with. And then they need to apply what they’ve learned to actual product work. For us, completing a course isn’t the primary measure of success. Contributing independently to real test automation afterwards is.

Learning needs capacity

There is an uncomfortable truth behind almost every upskilling initiative: learning takes time. The first automated test written by someone new to test automation may take longer than if an experienced colleague simply did the work. Pairing requires two people’s time. Onboarding requires attention from experienced engineers. If an organization expects all of that while maintaining exactly the same short-term delivery capacity, the learning will usually lose when it competes with the next deadline. So capacity is part of the experiment. The interesting question isn’t whether learning costs time. Of course it does. The question is whether that investment produces a return on investment later through shorter feedback loops, broader knowledge, fewer dependencies, more automation and smoother delivery. We want to measure that rather than assume it.

Start small enough to learn

We deliberately don’t want to begin with a large rollout. A pilot gives us room to discover where our assumptions are wrong. A small cohort can learn together, work with real test suites and receive meaningful support from experienced colleagues. It also makes it easier to observe what happens after the formal learning ends. That last part matters. Success isn’t how many people attended. It isn’t how many certificates were issued. And while participant feedback is valuable, a high satisfaction score doesn’t tell us whether the organization changed. We are more interested in questions such as:

• Can developers contribute meaningful automated tests afterwards?
• How much support do they still require?
• Does collaboration between Development and QA happen earlier?
• Does automation knowledge become less concentrated?
• Do automated tests become a more natural part of delivery pipelines?

And eventually, do we see improvements in engineering outcomes such as shorter feedback time, less defects, more delivery predictability and less manual testing effort? Some of those effects may appear. Others may not. That’s why it’s an experiment.

Don’t overlook the expertise you already have

There is also a temptation with any new initiative to immediately look outside the organization for expertise. External specialists can accelerate learning, and we see value in that. But organizations often already contain much more knowledge than they realize. One team may have developed a useful API-testing approach. Another may have solved a difficult end-to-end automation problem. An experienced QA engineer may know the pitfalls of a framework that another team is just beginning to adopt. The problem isn’t always missing knowledge. Sometimes it’s connecting the knowledge that already exists. So an important part of our experiment is bringing internal practitioners together: developers, QA engineers and test automation specialists who can share approaches, mentor participants and help us distinguish between generic best practices and what actually works in our environment. External training and internal expertise shouldn’t compete. They should reinforce each other.

Perhaps the most valuable outcome is the conversation

Something interesting happened when we first discussed this idea with engineers. The questions weren’t mainly about the course content. They were about the implications.

• Does this change what is expected from me as a developer?
• What does this mean for QA?
• Will teams really provide time to practise afterwards?
• Are we using the knowledge we already have?
• Is Java-based test automation realistic for someone working primarily in low-code?

Those aren’t obstacles to an engineering transformation. They are valuable design input. They force us to be clearer about what we’re trying to achieve and, equally importantly, what we’re not trying to achieve. They also remind us that technical change and organizational change can’t really be separated. Teaching someone a new framework is relatively straightforward. Changing how people collaborate, how teams allocate capacity and where responsibilities sit is much harder. That’s another reason we’re starting with an experiment rather than a conclusion.

Where we hope this takes us

We don’t know yet what the ideal overlap between Pega development and test automation looks like. Perhaps developers can take significantly more responsibility for automated verification than they do today. Perhaps we’ll discover areas where specialized QA expertise remains essential. Most likely, the answer won’t be one extreme or the other. What we do believe is that quality improves when it is built into the development process from the beginning, rather than inspected at the end. And we believe there is value in developers broadening the testing practices they already use beyond unit testing and further into automated integration and end-to-end testing while QA expertise is embedded throughout the engineering process.
So our pilot isn’t really about teaching Pega developers test automation. It’s about testing a broader idea: What becomes possible when low-code developers and QA engineers share more of the skills, context and responsibility needed to build quality into software from the beginning? That’s what we want to find out.
This article wouldn’t exist without the open discussion in our Pega Chapter. Thank you to our developers for bringing forward the questions, concerns and ideas that challenged us to think more deeply about what shared quality ownership could actually mean in practice. Special thanks to our Chapter Lead, Raphaela Wrede, for shaping this initiative and creating the space for an open conversation, and to my fellow Engineering Managers, Marga, Yaniv and Holli, for contributing their perspectives and challenging our assumptions. Like the pilot itself, the thinking behind this article is a collaborative effort and still a work in progress

Written by Elif Schaefer, Engineering Manager (Pega)