The Role of a Modern Quality Engineer: Beyond Testing Software | Amber Insights #010
Updated: 14 hours ago
By Amber Idumwonyi
Ask someone outside the software testing profession what a tester does and you may hear a familiar answer:
"They test the software and find bugs."
Technically, that is not wrong.
But it describes only a fraction of what modern Quality Engineering has become.
Today's Quality Engineer can contribute to requirements, challenge assumptions, identify risks, influence technical design, design tests, investigate failures, work with APIs and integrations, contribute to automation, analyse quality data, support accessibility, collaborate with Developers, and provide evidence that informs release decisions.
And increasingly, Quality Engineers are working alongside technologies such as cloud platforms, CI/CD pipelines and Artificial Intelligence.
The profession has evolved.
Yet I still think one of the biggest misunderstandings surrounding Quality Engineering is that the role begins when somebody hands us software to test.
It doesn't.
A modern Quality Engineer does not simply test what has been built. We help teams understand, build and maintain quality throughout delivery.
That distinction changes everything.
From Software Tester to Quality Engineer
Earlier in this series, I explored the evolution from Quality Assurance to Quality Engineering.
That evolution was not simply a change in job title.
The expectations of the profession have expanded.
Traditional testing was often positioned towards the end of development.
Requirements were written.
Software was designed.
Developers built it.
Then it reached the testing team.
The tester's responsibility was largely to determine whether the finished implementation behaved as expected.
Modern delivery requires quality involvement much earlier and much more broadly.
A Quality Engineer might challenge an ambiguous requirement before development starts.
We might identify an integration risk during technical discussions.
We might help determine which checks belong at component, API, integration or user-interface level.
We might investigate why an automated test is failing in a pipeline.
We might examine whether functionality is accessible.
We might analyse production behaviour after release.
The role is no longer confined to executing tests.
It increasingly involves engineering confidence into the delivery process.
We Ask Questions Other People May Not Ask
One of the most valuable skills a Quality Engineer develops is the ability to ask questions.
Not questions for the sake of slowing down a conversation.
Questions that expose assumptions.
Imagine a requirement says:
"A customer should receive confirmation after successfully submitting an application."
A Quality Engineer may ask:
What constitutes a successful submission?
What happens if the application is saved but the confirmation service fails?
Can the customer submit twice?
What happens if the session expires during submission?
What should happen if one downstream system succeeds and another fails?
What information should appear in the confirmation?
What should be logged?
What should the user experience if something goes wrong?
None of those questions require us to execute software.
Yet answering them can prevent significant problems later.
That is one reason I see curiosity as one of the most important qualities in a good Quality Engineer.
We constantly ask:
What if?
What happens when?
What are we assuming?
What haven't we considered?
We Think in Terms of Risk
Modern Quality Engineers cannot test everything equally.
Software systems are too complex, delivery timelines are limited, and the number of possible combinations can become enormous.
So we need judgement.
What functionality is business-critical?
Where would failure have the greatest impact?
Which areas have changed?
Where are the technical complexities?
Which integrations create dependencies?
What functionality handles sensitive information?
Where have problems occurred previously?
Which user journeys absolutely must work?
This is where risk-based thinking becomes central to the role.
A Quality Engineer should be able to look beyond a list of requirements and understand where the greatest uncertainty and potential impact exist.
That understanding influences where we invest testing effort.
The objective is not simply maximum testing.
It is appropriate testing based on risk and evidence.
We Translate Between Business and Technology
Quality Engineers often sit in an interesting position within delivery teams.
We need to understand what the business expects.
We also need to understand enough about the technical implementation to investigate whether those expectations are being met.
That makes communication an important part of the role.
A stakeholder may tell us:
"Customers cannot complete their application."
A Developer may tell us:
"The downstream API is returning a 500 response after the request times out."
Those statements describe the same problem from completely different perspectives.
A strong Quality Engineer can work across both.
We understand the technical failure.
But we also understand the business consequence:
Customers cannot complete an important journey.
Being able to connect those perspectives helps teams prioritise problems appropriately and communicate quality information clearly.
We Design Tests, Not Just Test Cases
There is an important difference between writing test cases and designing tests.
A test case documents something we intend to verify.
Test design requires us to determine which conditions will provide meaningful information about the system.
Consider a field accepting values between 1 and 100.
We could create dozens of random tests.
Or we could deliberately examine the boundaries:
That is not simply execution.
It is test design.
Modern Quality Engineers use techniques, experience, risk information and domain knowledge to determine where defects are likely to exist and which scenarios will provide the strongest evidence.
This becomes increasingly important as systems grow more complex.
The value of a Quality Engineer should therefore never be measured simply by the number of test cases they produce or execute.
The better question is:
How much meaningful information did the testing provide?
We Need Technical Understanding
Modern Quality Engineering is becoming increasingly technical.
That does not mean every Quality Engineer must become a Software Developer.
But understanding how modern systems work makes us significantly more effective.
APIs.
Databases.
Distributed services.
Cloud infrastructure.
Authentication.
Messaging.
Logs.
CI/CD pipelines.
Version control.
Test automation frameworks.
These technologies increasingly form part of the environments we test.
Imagine an end-to-end test fails.
A purely user-interface-focused investigation might conclude:
"The Submit button doesn't work."
A Quality Engineer with broader technical understanding may investigate further.
Did the browser send the request?
What response did the API return?
Did authentication succeed?
Did the downstream service respond?
Was data written correctly?
Is there useful information in the logs?
Where exactly did the journey fail?
That ability to investigate across layers changes testing from observation into engineering analysis.
Automation Is Part of the Toolkit, Not the Identity
Automation has become an important part of modern Quality Engineering.
And rightly so.
Automated checks can provide rapid, repeatable feedback and support continuous delivery.
But I do not believe automation defines whether somebody is a modern Quality Engineer.
Knowing how to write automation without understanding risk, test design, system behaviour or business context can simply help us execute weak tests faster.
Likewise, excellent exploratory and analytical testing can identify problems automation may never discover.
The strongest Quality Engineers understand where automation adds value and where human investigation remains essential.
Automation is therefore part of our toolkit.
It is not the entire profession.
We Influence Testability
One of the less visible responsibilities of a modern Quality Engineer is helping teams build software that can actually be tested effectively.
Can dependencies be controlled?
Can appropriate test data be created?
Can failures be simulated?
Can system behaviour be observed?
Can components be tested independently?
Are useful logs available?
Can automated checks run reliably?
These questions concern testability.
If teams wait until functionality has been completed before thinking about them, testing can become unnecessarily difficult.
Quality Engineers can therefore contribute during technical design and development by helping teams consider how the solution will eventually be validated.
That is a significant shift from simply receiving software after implementation.
We Champion Accessibility and Inclusive Quality
Quality also extends beyond whether functionality technically works.
A feature can meet every functional requirement and still exclude people from using it effectively.
Can somebody navigate using a keyboard?
Can assistive technologies interpret the page correctly?
Is focus visible?
Are controls labelled meaningfully?
Does the interface communicate information in an accessible way?
Accessibility should not be treated as a final compliance exercise.
For Quality Engineers, it should form part of understanding whether the product works for the people it is intended to serve.
This is another example of how modern quality extends beyond finding conventional functional defects.
We Collaborate Rather Than Police
There was a time when testing teams could become positioned as the final gatekeepers of software quality.
Development built.
Testing approved or rejected.
That relationship can easily become adversarial.
Modern Quality Engineering works better through collaboration.
We work with Business Analysts to improve requirements.
We work with Developers to understand implementation and testability.
We work with Product Owners to understand business priorities.
We work with Architects to understand technical risks.
We work with DevOps and platform teams to understand environments and delivery pipelines.
We work with users and business representatives to understand whether solutions actually meet their needs.
Quality Engineers should challenge where challenge is needed.
But the objective is not to catch other people making mistakes.
The objective is to help the team make better decisions about quality.
We Provide Evidence, Not Permission
This distinction is particularly important for Quality Engineers moving into leadership roles.
You may hear:
"Can QA sign this off?"
But release decisions often involve considerations beyond testing.
Business priorities.
Operational readiness.
Security.
Known defects.
Technical risk.
Regulatory considerations.
Delivery deadlines.
Testing provides one of the most important inputs into that decision, but it should be evidence-based.
Instead of simply saying:
"QA has passed it."
A Quality Engineer should be able to communicate:
What was tested.
What passed.
What failed.
What was not tested.
What known issues remain.
What limitations affected testing.
What significant risks remain.
And what level of confidence the evidence supports.
Decision-makers can then make an informed release decision.
Our responsibility is not to manufacture certainty where certainty does not exist.
Our responsibility is to make the quality position visible.
We Learn from Production
As I discussed in Issue 008 on Shift Right Testing, quality learning should not end at deployment.
Production can tell us things that test environments cannot.
How are users actually behaving?
Where are failures occurring?
Are certain journeys being abandoned?
Are particular services producing errors?
Did behaviour change after a release?
What incidents are occurring repeatedly?
Quality Engineers can use this information to improve future testing.
A production incident may reveal a missing regression scenario.
User behaviour may expose an assumption we never considered.
Operational data may reveal an area requiring greater coverage.
Production therefore becomes another source of evidence.
The modern Quality Engineer does not simply ask:
"Did it pass testing?"
We also ask:
"What did we learn after it was released?"
AI Is Changing the Role Again
Artificial Intelligence is already changing how software is designed, developed and tested.
Quality Engineers can use AI to support activities such as generating test ideas, analysing requirements, creating test data, accelerating automation development, investigating failures and summarising complex information.
That creates enormous opportunity.
But it also makes human judgement more important.
An AI-generated test can look convincing and still be wrong.
An AI assistant can generate twenty scenarios while missing the one business-critical risk that matters most.
AI-generated code can execute successfully while containing assumptions nobody has challenged.
The modern Quality Engineer therefore needs another capability:
Knowing when to trust, challenge and verify AI-generated outputs.
Our future value will not come from competing with AI at producing large quantities of information.
It will increasingly come from applying context, critical thinking, risk awareness, domain understanding and professional judgement to that information.
Later in this series, we will explore AI in Quality Engineering in much greater depth.
The Skills of a Modern Quality Engineer
When all of this is brought together, the role becomes remarkably broad.
A modern Quality Engineer combines:
Testing expertise — understanding test design, techniques, coverage and investigation.
Technical understanding — being able to work across APIs, integrations, data, automation and modern architectures.
Risk thinking — identifying where quality problems could have the greatest impact.
Business understanding — recognising why functionality matters to users and organisations.
Communication — translating complex quality information for different audiences.
Curiosity — continually questioning assumptions and investigating unexpected behaviour.
Collaboration — influencing quality across multidisciplinary teams.
Judgement — knowing what needs deeper investigation and what level of evidence is sufficient.
Adaptability — continuing to learn as technologies and delivery practices evolve.
No Quality Engineer begins their career mastering all of these.
And even experienced Quality Engineers continue developing them.
That is part of what makes this profession so interesting.
What the Modern Quality Engineer Is Not
Perhaps it is equally important to clarify what the role should not become.
We are not the people who simply execute test scripts.
We are not the department responsible for catching everybody else's mistakes.
We are not automatically the final authority on whether software can be released.
We are not automation engineers who happen to know some testing.
And we are not becoming irrelevant because Developers test their code or AI can generate test cases.
The profession is becoming broader rather than narrower.
As software systems become more complex, organisations need people who can evaluate those systems critically and help teams understand whether they are genuinely ready to serve their users.
That is where Quality Engineering continues to provide value.
From Finding Defects to Engineering Confidence
Across the first ten issues of Amber Insights, we have explored Test Strategy, testing mindset, software quality, the evolution of Quality Engineering, risk-based testing, quality culture, Shift Left, Shift Right and the modern testing lifecycle.
There is a common thread connecting all of them.
Confidence.
Can we confidently explain what the software should do?
Can we confidently identify the significant risks?
Can we confidently demonstrate that important functionality works?
Can we confidently explain what we have not tested?
Can we confidently communicate the limitations of our evidence?
Can we confidently learn when reality behaves differently from our expectations?
The goal is not absolute certainty.
Complex software will always contain uncertainty.
The goal of Quality Engineering is to make that uncertainty visible, investigate it intelligently, reduce it where possible, and give teams reliable evidence on which to make decisions.
That, to me, is the role of the modern Quality Engineer.
Final Thoughts
Quality Engineering has moved far beyond testing completed software.
Today's Quality Engineer can contribute from the first requirements conversation through design, development, testing, deployment and production learning.
We challenge assumptions.
We investigate risk.
We design meaningful tests.
We use technology intelligently.
We collaborate across disciplines.
We advocate for accessibility and users.
We provide evidence.
We learn from failures.
And increasingly, we help teams navigate what AI means for software quality.
Tools will continue to change.
Automation frameworks will change.
Delivery models will evolve.
AI capabilities will become more sophisticated.
But one thing will remain fundamental:
Someone still needs to ask the difficult questions about whether the software we are building is genuinely good enough for the people who depend on it.
That is why I believe the future of Quality Engineering is not simply about becoming better at testing software.
It is about becoming better at engineering confidence in everything we deliver.
About the Author
Amber Idumwonyi is a Senior Quality Engineering professional with extensive experience delivering quality engineering solutions across UK Government, defence, healthcare, and enterprise technology programmes. She has led Quality Engineering initiatives, developed Test Strategies, contributed to modern testing and automation practices, spoken at industry conferences, and founded LEMP, an organisation focused on practical technology education, mentoring, industry experience, and career development.
Amber is passionate about Quality Engineering, AI-assisted testing, technical leadership, and developing the next generation of technology professionals.
Read More:
Amber Insights | Issue 006 – Building a Quality Culture Across Delivery Teams
Amber Insights | Issue 007 – Shift Left Testing Explained: What It Really Means in Practice
Amber Insights | Issue 008 – Shift Right Testing Explained: Learning from Software in the Real World
Amber Insights | Issue 009 – The Modern Software Testing Lifecycle: From Requirements to Continuous Quality
Explore LEMP's Software Testing programme and learn how you can get started.
Comments