Should Quality engineers and QA engineers be primarily focused on testing activities?

Discussions
,
1

I am seeing far too many posts at the moment on QE being “more” than testing, not being about finding bugs which testing is and “not just” validating at the end of lifecycle and alongside a random statement like this they often give a very poor definition of testing alongside a slightly better one but call the latter QE.

Some others talk about prevention over detection but that is a red herring unless an assembly line model is being followed as development relies on detection every day in order to learn and evolve the product, good QE here would recognise the unknowns and look at the system of dealing with them through detection rather than diminishing an activity. This I therefore do not see as a real difference.

For those in these roles do you feel it is closer to good quality engineering principles being applied to your core testing activities or that you are a broader quality engineer that also takes on testing activities?

A good indicator may be the consideration of what engineering practices do you help shape that alter how software is designed, reviewed, built, released or operated, independently of the testing you perform?

For example, do you influence how effective code reviews are? Are you involved in defining merge and branch controls? There are many more activities that QE can contribute to, that does not mean do those activities but may involve building the system that supports those activities to be done well, is this deemed part of the role you have.

I tend to still regard myself as a tester which includes anything product risk related with discovery and investigation of those risks starting on day one and verification activities like automated coverage. I also apply solid engineering principles to these activities as do the developers I work with to their respective areas. I do not though do those other things like influencing developer owned practices, I can see value in that but is not needed where I am, nor do I think I would enjoy it.

QE does not make sense to be viewed as more than testing but it can empower better testing, it is different from testing as it’s about the software and the system by which the software is developed but what does that look like in reality.

There was another argument that testing itself had picked up such a poor reputation for not applying quality engineering principles that the rebranding was needed, so business as usual for good testers but change in the hope the poor practices get diminished.

If you have that title where do your responsibilities lie? I am looking for understanding here, whilst I do judge a lot of the random “better or more than” posts associated with SQAE I am not judging the role itself but I want more awareness of the reality associated with it, what to expect if I transitioned to a QE role for example.

2

Absolutely yes! Testing is, for a tester brain, what’s fun. Finding those bugs. Be the devil. Verification, automation, test planning and that kinda stuff brings milk to the table, and some joy to people with coding and administration brains. I have been a test leader and manager maybe 15 ys, that brought more milk to the table than being the troubleshooter. Now, kids out into own careers, I’m back to be the organzation devil and I love it.

Being born the nick year, I can say to you younger guys, milk on the table is important, especially when kids comes marching in, but don’t forget what makes the office hours go fast. For me, finding bugs in a system I know best of all.

3

This sounds like testing to me an not QE, if I thought it the new role was about finding bugs and just a rebrand of what good testing looks like and none of the fun lost or diminished I’d be fairly cool with that, my feel is that it is different or at least intended to be more about the system of work including not testing activities that also impact quality rather than the product focus a tester has.

4

I think most “QE” roles are just testing with a fancier title, not real say over code review or release gating, and that’s fine as long as we’re honest about it; the real test is whether you influence those levers, if not, you’re doing good testing with an engineering mindset, not broader quality engineering.

5

I don’t think Quality Engineers should be focused only on testing activities but I also don’t think the solution is to redefine testing as something less so QE can be presented as more.

To me, testing is already much broader than executing test cases or finding bugs. It starts when a requirement is discussed and continues through understanding risks, asking questions, validating assumptions, exploring the system, designing automation, and learning from production. Those are testing activities.

Where Quality Engineering differs, if it differs at all, is in where the engineering effort is directed.

For example, if I’m improving our automation framework, making test environments more reliable, introducing better quality gates, improving observability, or reducing feedback time in CI, I’m engineering the quality system, not just testing the product. Those changes benefit every future release, even before a single test runs.

But I don’t see that as QE is more than testing. I see it as an additional layer of responsibility that some organizations expect from the role. A great tester can exist without owning merge policies or release pipelines, and a great Quality Engineer may spend significant time improving those systems.

So rather than asking which role is more? I would ask:

  • Is my primary responsibility understanding and investigating product risk?

  • Or is it engineering the system that enables quality across the development lifecycle?

Many organizations blur those responsibilities under the same title, which is why conversations about QE vs QA often end up talking past each other.

6

What about the code review question? When you do QE is that in your remit or does the QE focus on the test side of things automation, automation in CI, building in testability, that was the question is the engineering testing focused or broader like influencing the code review process that has a significant impact on quality.

7

I think QA can offer much more than that, like collaborate closely with stakeholders, dev team , BA , product owner during the implementation of the app rather than waiting until it is handed over to testing/QA and at the end of testing activities, as QA we also need to provide stakeholders with clear view of release readiness

8

release readiness is where the role gets broader for me. testing finds risk; quality engineering makes that risk legible to the people deciding whether to ship.

for a browser change, i’d want the release call tied to the failed path, exact transition, expected versus actual result, and enough browser context to inspect it without a fresh repro. that is still testing work, but the receiver is the whole release decision, not only the tester.