QA Is More Than Testing: What 20+ Years in Software Taught Me About Quality
After more than 20 years working in software and quality assurance, I’ve had the opportunity to see QA evolve considerably.
I started my career as a software engineer before moving into quality assurance, and over the years I’ve worked across healthcare, regulated medical devices, e-discovery, fleet management, web applications, mobile applications, APIs, and test automation. I’ve gone from writing and executing manual test cases to building automation frameworks, developing API and integration tests, working with CI/CD pipelines, establishing QA standards, mentoring other testers, and leading QA efforts across multiple teams.
I’ve seen technologies change. I’ve seen testing methodologies change. I’ve gone from record-and-playback tools to building automation frameworks with modern programming languages and tools such as Playwright and TypeScript. I’ve watched QA become increasingly intertwined with software engineering.
But after more than two decades, I’ve learned that one thing remains just as important as the tools we use:
How an organization views and works with QA.
I’ve worked in environments where QA is treated as a partner in delivering quality software. I’ve also experienced what happens when QA is viewed primarily as the team at the end of the development process — the team expected to test what has been built, find the problems, and somehow make the release date work.
That difference matters.
This isn’t an article about blaming developers, product managers, or leadership. It’s also not an argument that QA should be given unlimited time or resources. QA should be accountable. We should continuously improve, learn new technologies, automate where it makes sense, and find ways to become more efficient.
But accountability has to work both ways.
If an organization expects QA to provide confidence in the quality of a product, QA needs to be involved in the conversations that influence that quality. They need to be part of planning. They need to have a voice in estimates and timelines. Their expertise should be considered when deciding how something will be tested, what tools will be used, and what risks need to be considered.
Most importantly, the organization needs to understand what QA actually does.
Because quality assurance is much more than finding bugs.
QA Isn’t the Last Step in the Development Process
In the past, the SDLC often treated QA as the final step in the development cycle:
Traditional
👨💻 Developer → 🧪 QA → 🚀 Release
Over the years, organizations have recognized the value of involving QA much earlier in the process. Testing isn’t simply clicking through an application and reporting bugs. QA brings a specialized perspective that shouldn’t be treated as simply another pair of hands.
Modern
👨💻 Development ↔ 🧪 QA ↔ 📋 Product ↔ 🎨 Design
┌───────────────┐
│ Requirements │
└───────┬───────┘
↓
🔍 QA asks questions
↓
┌─────────────────────────┐
│ Development & Testing │
└────────────┬────────────┘
↓
🧪 QA validates
↓
🚀 Release
↓
📊 Feedback / Risk
│
└──────→ 🔄QA can ask important questions while requirements are still being defined. They can represent the user’s perspective and identify confusing behavior, unnecessary complexity, or areas where the application may not be as intuitive as intended. They can raise potential performance, usability, and accessibility concerns before development is complete. They can also create and document test cases earlier in the process, giving developers visibility into the scenarios and behaviors that will ultimately need to be validated.
This early involvement can have a significant impact on the development process. Finding a problem while requirements are being discussed is very different from finding that same problem after development is complete and the feature has reached QA.
The value QA brings isn’t just in finding defects. It’s in the perspective QA brings throughout the entire development lifecycle.
When organizations involve QA early and allow them to contribute their knowledge and experience, they get the full value of their QA investment — not simply a team that tests software at the end of the process.
A developer may look at a requirement and think, “How do I build this?”
A QA engineer may look at that same requirement and think, “What happens if the user does this? What if they do it twice? What if they don’t have permission? What happens with unexpected data? What happens when the API fails? What happens on a different device? What happens when the user takes a path nobody originally considered? Does this behavior actually solve the problem the user is trying to solve?”
Neither perspective is more important than the other. They’re different perspectives, and good software benefits from having both.
QA Capacity Has Consequences
⚖️ Capacity has consequences.
When you have a small number of QA engineers supporting a much larger development organization, it’s important to remember that QA isn’t simply testing features.
Depending on the organization, a QA engineer may be responsible for some or all of the following:
Planning & analysis
- understanding requirements
- identifying edge cases
- writing test plans
- creating test cases
- creating test data
Testing
- UI testing
- API testing
- regression testing
- exploratory testing
- reproducing defects
Automation
- writing automation
- maintaining automation
- reviewing automation
- investigating automation failures
Team & process
- answering developer questions
- supporting releases
- improving QA processes
- maintaining testing infrastructure
- mentoring and knowledge sharing
And that list doesn’t necessarily represent separate tasks that happen one at a time. Many of them are happening simultaneously, often across multiple features, releases, and teams.
If a large group of developers is producing work that ultimately needs to be validated by a much smaller QA team, the amount of work entering the QA process can grow much faster than the team’s ability to process it.
That doesn’t necessarily mean QA is inefficient.
It may simply mean that the organization has created more demand than the available capacity can reasonably support.
Capacity Isn’t Just About Test Execution
One of the easiest things to underestimate about QA is the amount of work that happens before a test is actually executed.
A QA engineer may need to understand a feature, review the requirements, identify scenarios that aren’t explicitly documented, determine how the feature interacts with existing functionality, prepare test data, understand dependencies, create or update automation, and determine what regression testing is necessary.
Then the feature may finally reach QA.
At that point, the expectation can sometimes become:
“Why isn’t this tested yet?”
But the clock shouldn’t start with the assumption that QA’s work begins when a ticket is moved into a QA column.
The work often starts much earlier.
And the complexity of that work can increase dramatically when QA discovers defects. Finding a bug isn’t necessarily the end of the testing process. It can mean reproducing the issue, documenting it, discussing it with developers, retesting the fix, determining whether the fix introduced additional risk, and potentially expanding the test coverage to prevent the problem from returning.
Production defects should be reviewed with QA involved as well. QA may not make the final decision about whether an issue will be fixed, but they can provide valuable insight into what retesting may require, which areas could be affected by a fix, and what regression coverage may need to be considered. Just as importantly, including QA gives the team an opportunity to understand what may have been missed during testing and how test cases, automation, or the overall testing approach could be improved to catch similar issues in the future — even if that particular defect is not fixed immediately.
When QA Falls Behind, Look at the System
This is why organizations need to be careful about how they interpret QA delays.
When QA falls behind, the immediate question can easily become:
“Why is QA so slow?”
But that’s only one possible explanation.
A better set of questions might be:
What work is QA being asked to do?
How much work is entering the QA process?
How much capacity does QA have?
How complex are the features being tested?
How much time is available for meaningful testing?
How often are requirements changing?
How many defects are being discovered and requiring additional cycles of work?
What other responsibilities are competing for QA’s time?
Those questions don’t automatically lead to the conclusion that more QA engineers are needed. Sometimes the answer may be better processes, better automation, earlier QA involvement, improved tooling, changes to scope, additional developer participation, or simply better planning.
The important part is understanding the cause before judging the outcome.
The Deadline Doesn’t Change the Amount of Work
A deadline can determine when something needs to be completed. It doesn’t necessarily determine how much work is required to validate it.
If a complex feature reaches QA two days before release, giving QA a two-day deadline doesn’t magically create five days of testing capacity.
It creates a decision.
Something has to change.
If the amount of work stays the same but the available time decreases, something else has to change.
Perhaps the scope changes. Perhaps additional resources are provided. Perhaps the amount of testing changes. Perhaps the release date changes. Or perhaps the organization consciously accepts additional risk.
What shouldn’t happen is pretending that the additional work doesn’t exist.
Testing time isn’t determined solely by how quickly someone can execute test cases. It is affected by the complexity of the feature, the number of scenarios, defects discovered, environments, test data, dependencies, regression requirements, automation coverage, and unexpected behavior.
The organization needs to decide what level of confidence it is willing to accept.
A release could potentially happen with:
- full regression
- targeted regression
- exploratory testing
- automated coverage only
- reduced scope
- known unresolved defects
- increased production monitoring
These approaches don’t provide the same level of confidence, and the tradeoffs should be understood rather than hidden.
When QA falls behind, the goal shouldn’t be to find someone to blame. The goal should be to understand the capacity, the workload, the risks, and the tradeoffs — and then make an informed decision.
QA shouldn’t be viewed as a bottleneck simply because they are the point in the process where the accumulated work becomes visible.
Sometimes QA isn’t the bottleneck.
Sometimes QA is simply where the capacity problem becomes visible.
Get Ronell Lukasik’s stories in your inbox
Join Medium for free to get updates from this writer.
The question isn’t always:
“Can QA finish?”
A more useful question is:
“What level of confidence do we need, and what are we willing to trade to achieve it?”
If the date cannot move, something else may need to change: scope, testing depth, resources, risk tolerance, or some combination of them.
QA shouldn’t be expected to magically eliminate the constraints.
QA Should Be Part of the Estimate
QA doesn’t necessarily need to dictate the release date. But if QA is responsible for validating a release, QA should have a voice in determining what is required to validate it.
QA can provide information the team and leadership need to make an informed decision.
Things that can be considered:
- complexity
- scope
- regression
- automation
- test data
- dependencies
- known risks
- expected testing time
You Can’t Teach Someone to Think Like QA Overnight
I strongly believe developers can — and often should — contribute to automated testing.
Developers bring valuable technical knowledge to the process, and having them contribute to automation can increase test coverage and create greater shared ownership of quality.
But being able to read and write code isn’t the same thing as knowing what should be tested, how deeply it should be tested, which scenarios are easy to overlook, how test data should be structured, how to distinguish implementation details from user behavior, or how to build tests that remain maintainable over time.
Testing is its own discipline.
A developer may have deep knowledge of how a feature was implemented. A QA engineer may bring a different set of experiences and habits focused on how that feature could be used, misused, misunderstood, or pushed outside the expected path. Both perspectives are valuable.
I’ve experienced situations where engineers were asked to contribute to automated testing with the assumption that their ability to write code would be enough to get them started. In practice, I found myself spending significantly more time reviewing automated tests than expected — not because the engineers couldn’t write code, but because we hadn’t established a shared understanding of what good tests looked like.
The lesson for me was simple:
Sometimes the fastest way to improve someone’s output isn’t to review more aggressively. It’s to teach the expectations before they start.
If developers are going to contribute to QA automation, don’t simply hand them a framework and assume that knowing the programming language is enough. Take the time to explain the testing strategy, the team’s standards, what good test coverage looks like, how scenarios should be identified, how tests should be structured, and why those practices matter.
This isn’t about keeping testing knowledge exclusively within QA. Quite the opposite. The more knowledge that can be shared between QA and development, the stronger the entire team becomes.
But knowledge transfer takes time.
You can’t expect someone to immediately produce tests that follow an established QA strategy simply because they know how to write code. Just as a developer shouldn’t be expected to understand an unfamiliar codebase without learning its architecture and conventions, someone new to a team’s testing practices needs an opportunity to learn its approach.
This is one reason I believe testing standards matter. If developers are going to contribute to automation, they need to understand not only how to write a test, but what the test is supposed to communicate. This experience also reinforced something I’ve written about in another article, Playwright Tests — Readable, Maintainable, A Technical Source of Truth.
One of the ideas behind that article is that automated tests should communicate expected behavior clearly — not just execute code. When tests are treated as a technical source of truth, the structure, readability, and intent of those tests become just as important as whether they technically pass.
That’s something that needs to be taught and shared across the team, not simply assumed.
QA Shouldn’t Just Be Asked to Use the Tools — They Should Have a Voice in Choosing Them
🛠️ Tool selection is also a quality decision.
When evaluating a testing tool, QA should consider a number of factors:
- What problem are we trying to solve?
- What are we currently doing well?
- What isn’t working?
- What are the tradeoffs?
- What does the new tool provide?
- What does it make harder?
- How will it affect test execution time?
- How will it affect reliability?
- How will it affect maintenance?
- Who will maintain the tests?
- What training is required?
- How will existing tests transition?
- What happens to our current mocking/stubbing strategy?
- How will we validate that the new approach is actually better?
If someone is responsible for leading QA on a project, involving that person in the testing strategy isn’t simply being polite. It’s using the expertise the organization hired them to provide.
AI Will Change How We Test
The growing use of AI is going to change how software is built and tested.
🤖 AI
↓
More code
More tests
More data
↓
🧠 Human judgment
↓
Better questions
Development teams can use AI to accelerate code generation, prototyping, feature development, and documentation. QA engineers can benefit from these same tools by using AI to help generate test cases, create automation, investigate failures, analyze data, and accelerate many other parts of the testing process.
But increased productivity does not mean the need for QA thinking disappears.
As the amount of software being produced increases, the ability to ask the right testing questions may become even more important.
Someone still needs to ask:
- What scenarios are we missing?
- Does this behavior actually make sense for the user?
- What happens when the expected data isn’t provided?
- What happens when something fails?
- Are there unexpected ways a user could interact with this feature?
- Does this change break something that already worked?
- Are we testing the behavior or simply testing the implementation?
- Are the automated tests actually providing meaningful coverage?
- What risks are we accepting by not testing something?
AI can help us work faster, but faster test creation isn’t necessarily the same thing as better testing.
Generating hundreds of automated tests doesn’t automatically mean we have hundreds of meaningful tests. AI can help create tests, but someone still needs to understand whether those tests represent the right scenarios, whether they provide meaningful coverage, whether they are maintainable, and whether they validate behavior rather than simply exercising implementation details.
The human judgment, product knowledge, domain knowledge, curiosity, and willingness to challenge assumptions that good QA brings to the process still matter.
AI may change how we test.
It doesn’t eliminate the need to think about what should be tested.
Don’t Measure QA Only by the Bugs They Find
“We see what QA finds, but not everything QA helps prevent.”
Imagine a QA engineer tests a feature and finds zero bugs.
From the outside:
“QA didn’t find anything.”
But that statement doesn’t tell us very much by itself.
Maybe the feature was well designed and implemented.
Maybe requirements were clear.
Maybe developers had already caught issues through their own testing.
Maybe QA identified risks earlier in the process, and those issues were addressed before the feature reached formal testing.
And there is another part of QA’s contribution that can be even harder to see:
QA may have influenced requirements, identified edge cases, questioned assumptions, improved automation, prevented regressions, improved testability, or helped developers understand expected behavior.
Much of QA’s value is invisible when it works well.
The absence of a bug report doesn’t necessarily mean the absence of QA value.
Accountability Works Both Ways
↔️ Accountability works best when it is accompanied by understanding.
QA should absolutely be accountable. We should be challenged. We should improve our processes. We should look for ways to automate repetitive work. We should learn new tools. We should continuously improve.
But accountability should go both ways. Organizations should also be accountable for giving QA the information, resources, time, involvement, and support required to meet the expectations placed upon them.
QA has a specialized discipline, perspective, and body of knowledge, and organizations get more value from QA when they actually use that expertise. I’ve learned that the most effective QA organizations aren’t necessarily the ones with the most sophisticated tools, the largest automation suites, or the most elaborate processes.
They’re the organizations where QA is treated as a partner.
Where QA is involved early.
Where estimates include QA.
Where testing is recognized as engineering work.
Where developers and QA learn from each other.
Where tools are selected collaboratively.
Where leadership understands that quality isn’t something QA adds at the end of development.
Quality is something the entire organization builds together.
QA simply happens to be one of the teams whose job is to spend a significant amount of time asking, “What could go wrong?”
And when an organization gives that question the time, expertise, and respect it deserves, everyone benefits.
