3. From Tester to Quality Engineer: A Real Shift in Role and Team Collaboration

The first reaction: What does this mean for me as a tester?

When teams start talking about Quality Engineering, attention often turns to testers. Not necessarily because anyone wants to question their role, but because testing has long been the main symbol of quality. It is therefore natural for testers to start asking questions such as: Will my role still be needed? Does this mean testing will dissolve into other activities?

These concerns are not irrational. In the past, testing has gone through several changes that often shifted the role more toward technical activities rather than truly strengthening it. Automation, pressure for speed, and shortened testing phases frequently led to testers ending up in the position of someone who “just runs tests.” Quality Engineering emerged partly as a response to this situation. It is not a new standalone role, but rather a change in the approach to quality that affects the entire team.

Why testing at the end stopped working

To understand the change in the tester’s role within QE, we need to openly acknowledge one thing: testing as the final phase of development is simply no longer sufficient. Not because it is of lower quality, but because it comes too late. Testers receive a product that has already been largely designed and implemented, and they are expected to uncover all the problems before the product reaches users.

In practice, this puts testers in an extremely difficult position. They discover defects whose fixes are often costly or technically complex, and the team is then forced to choose between quality and deadlines. Quality Engineering does not solve this situation by limiting testing, but by moving it closer to where problems originate, rather than dealing only with their consequences.

Testing mindset as prevention, not control

In a Quality Engineering environment, the testing mindset starts to be applied much earlier. Testers participate in discussions about requirements, take part in solution design, and help the team ask questions that might otherwise never be raised. This does not mean testers replace analysts or architects. Instead, they bring a perspective focused on risks, system behavior, and potential usage scenarios into the decision-making process.

This shift has a fundamental impact. Problems that would previously appear only when testing a finished product are often resolved before the first line of code is written. Testing therefore stops being a gatekeeper at the end of the process and becomes a tool for prevention.

In other words:

Quality Engineering is not about testers doing more things than before.
It is about everyone taking responsibility for quality from the very beginning of development.

Quality Engineering is not a new role, but a change in the approach to quality

The term Quality Engineering can sometimes create the impression of a new role or job title. In reality, it primarily represents a shift in how quality is approached across the entire team.

Quality stops being the domain of a single role. Developers, analysts, product owners, and testers all contribute to decisions that influence system stability, maintainability, and the ability to respond to change.

This shift often means greater involvement in decision-making processes and greater responsibility for outcomes. At the same time, it also brings greater meaning to the work. Testers are no longer limited to the role of someone who “finds problems,” but instead become people who help create solutions that can be relied upon.

They also often act as advocates of these principles within the team: highlighting risks, encouraging discussions about quality across different stages of development, and helping other roles think about quality already during the design and implementation of solutions.

Collaboration instead of rigid boundaries between roles

Quality Engineering also changes the way people in a team collaborate. The traditional model, where work is handed off from one role to another, naturally creates barriers. Everyone focuses on “their part,” while responsibility for the whole becomes blurred. In such an environment, problems often appear only when it is too late to address them effectively.

Quality Engineering promotes a model in which roles overlap more and people collaborate across specializations. Shared discussions, pair work, or joint decision-making about risks lead to a deeper understanding of problems and better solutions.

In practice, this might mean including the quality perspective already during requirement definition, evaluating risks together during solution design, or sharing responsibility for quality throughout the entire development process. The team stops functioning like a production line where individual roles work in isolation and begins to operate as a cohesive unit.

The mindset shift: the hardest but most important step

Techniques, tools, and processes can be learned relatively quickly. Changing mindset, however, is not so simple. Quality Engineering requires a willingness to abandon the idea that quality is someone else’s responsibility. It requires open communication, trust, and the ability to reflect on one’s own mistakes.

Without this shift, Quality Engineering will remain only a term used in presentations and methodologies. With it, however, it can become the foundation for healthier teams, calmer releases, and higher-quality products.

Key Takeaways:

• Quality Engineering moves testing closer to where problems originate
• The testing mindset becomes more present across the whole team and is no longer limited to the testing phase
• Quality Engineering means shared responsibility for quality across the team
• Collaboration replaces rigid role boundaries
• Mindset ultimately determines the success of Quality Engineering

In the next (and final) part, we will look at how to start with Quality Engineering in a real project and how not to “kill” the idea right at the beginning.