With the trend overall shifting towards ‘quality engineering’, rather than just software testing.
What are your biggest concerns? Or perhaps risks?
This could be both from what the expectation is from us as quality engineering professionals.
Or equally, it could be risks to our products or companies.
I think my biggest concern is companies expecting too much from any given quality engineer.
I’m basing that off of the current feeling I have that those with the tester (or QA) title seem to already wear a number of hats, and expect to be experts in all sorts of testing.
I can see that the title becoming more inclusive leading to more expectations…though maybe I’m wrong, and that the title is just going to expand to fit what we were already doing.
(note that I don’t think this is universal, but it is something I see).
(Also note that I may be rambling a bit. I don’t have a lot of time today to do more than an off the cuff answer)
Culture shift- test at the end to quality as everyone’s responsibility. Product,development, operations, QA all need to align on shared ownership of quality -not always happening
Adopting too many tools, unclear processes, automation without strategy. Measuring quality effectively: struggle to define meaningful KPIs for QE, beyond number of bugs
Quality engineering - increasingly requires automation skills, understanding of DevOps practices, performance/security/non functional testing, tooling, test data management, etc. Teams suffer from skill gaps when shifting to QE: lack of scripting/automation expertise, lack of familiarity with modern test frameworks. If the QE function lacks the right skill set, then the testing may miss things
Systems today are more complex: microservices, APIs, multiple device/versions/OS targets, cloud, ML etc. Environments and dependencies (third party services, external integrations) often make testing very tricky. When systems get more complex, it becomes harder to ensure testing all the interactions.
Companies with strong hierarchies and authority boundaries may struggle to adapt to a QA person providing guidance on quality measures for other teams.
The biggest risk for me is that the rest of my organisation doesn’t understand it outside of my QA team. In that environment, my team then are uncomfortable trying to question quality in areas they perceive to be outside of their responsibility.
So it isn’t just a rebranding exercise and a something you can do in a day. It’s going to take getting into the senior leadership faces and say “hey this is a problem that only quality engineering will address” and convincing them. It will also take repeated demonstrations at each opportunity of the power of Quality Engineering practices to prove to those inside and outside your team that created a better outcome and/or avoided a massive problem down the line.
These days many companies seem to have abandoned thorough testing. Their mantra is “fail fast, fix fast,” which, in my view, turns customers into unwilling beta‑testers.
The implication is clear: testers either have to move toward heavy automation or start taking on development‑type responsibilities.
My biggest concern is around over focusing on the automated tests & tools. I think this comes from conflating automated testing and quality engineering.
I think there’s risks of losing that human-centric impact that you can get from really using and critiquing the software. If teams are over-reliant on automated tests, are they questioning whether they are solving the customer’s problem? I feel it risks missing out on some of those edge cases that are hard to think of up front and can be discovered when you see those little hints like a curious log message or just seeing how things are working together.
Even without my concerns around over-focusing on automation/tools, as we pick up more involvement throughout the SDLC, is there are risk of leaving a gap that others in a business are less likely to pick up?
Finally from my experience the biggest risk of transitioning to QE is skillset. I’ve been there when a company said “we’ll do quality engineering and get rid of our testers”. However the devs lacked the skillset, desire and more importantly, knowledge of what a software tester did so it left HUGE voids. The focus of the org to enable QE was purely on tools without any consideration of process, mindset and methodology.
I’m mainly worried that in the hurry to embrace “Quality Engineering,” the teams will focus more on the tools and pipelines rather than on the true user value and exhaustive testing. This will meanwhile result in the quality mentality being overlooked.
@rosie With everyone rushing towards ‘Quality Engineering’ teams can sometimes focus too much on tools and automation instead of real user value. We might spend all our time writing scripts and configuring tools, but lose touch with what actually matters—understanding what users need, identifying where real risks lie, and doing the hands-on exploratory testing that uncovers issues automation can’t catch.The result can be products that pass all tests but still don’t satisfy users.
That is such a common pattern of behaviour in my experience. I find that on top of that if the tool doesn’t solve the problem or is painful to use, people then think that the methodology (e.g. QEing) was the problem.