Do You Really Need Dedicated QA Engineers?

Liviu Lupei

Founder & Solutions Architect, Endtest · September 9, 2026

I've been working in the QA industry for almost 15 years.

During that time, I've had conversations about testing processes with people from thousands of companies. Tiny startups. Large enterprises. Companies with dedicated QA departments. Companies where developers test everything. Companies with sophisticated automation infrastructure. Companies where someone remembers to click around the application five minutes before a release.

I've seen a lot of different approaches work.

And I've seen a lot of them fail.

So when someone asks me, "Do we really need dedicated QA engineers?", my answer is probably less satisfying than the confident takes you'll find on LinkedIn:

It depends.

That's not a way of avoiding the question. It's the actual answer.

Don't copy another company's QA strategy

A common way to make engineering decisions is to find a successful company and copy what they do.

"Google does this."

"Amazon does that."

"Company X doesn't have QA."

Therefore, we should do the same thing.

The problem is that your company is not Google.

Even the premise is often wrong. Google is frequently mentioned as an example of engineering organizations where developers own quality, yet Google has also employed dedicated Test Engineers focused on finding failure modes, improving test infrastructure and increasing product quality.

Amazon currently hires dedicated Quality Assurance Engineers. Airbnb has a Quality Engineering organization with engineers responsible for test cases, automation coverage, test infrastructure and release quality.

These companies are also enormous. Practices differ between teams, products and points in time.

There is no universal Big Tech consensus that somebody forgot to tell the rest of us about.

And even if there were, copying Google's organizational structure without copying Google's engineering talent, infrastructure and budget would be a strange experiment.

A company might have 30 highly qualified engineers working on something another business would assign to five people.

Context matters.

Agile does not mean "developers do all the testing"

This is another idea that gets distorted.

Testing in Agile should not be a separate phase that begins after development is "finished." Quality work should happen throughout the sprint, with developers, testers, product owners and other stakeholders collaborating continuously.

That's very different from saying:

Developers should build the feature and then test the feature themselves.

Those two ideas somehow became interchangeable in some organizations.

They aren't.

The whole-team approach to quality means that everyone contributes to quality. It doesn't mean every specialization suddenly stops existing.

Your designer cares about quality too. That doesn't mean your backend engineer should redesign the checkout screen between two pull requests.

Your Product Owner cares about quality. That doesn't mean they should start debugging race conditions in JavaScript.

And your developers absolutely should test their code. That doesn't mean they should be the only people testing it.

ISTQB's guidance on test independence is much more nuanced than the usual internet debate. Developers can find defects in their own code, but independent testers can identify different failures because they approach the product with different assumptions, backgrounds and cognitive biases.

That distinction matters.

The person who built it shouldn't be the only tester

Suppose I misunderstand a requirement.

I implement the feature according to my misunderstanding.

Then I test the feature according to that same misunderstanding.

There's a decent chance it passes.

This is one of the simplest arguments for independent testing.

The developer knows how the feature was built. That's useful.

The tester doesn't necessarily think about the feature the same way the developer does. That's also useful.

You want both perspectives.

It's the same reason cross-checking appears in high-reliability environments. A second person isn't valuable because the first person is incompetent. They're valuable because two people are less likely to have exactly the same blind spot.

That doesn't require a separate QA department with 40 people.

On a small team, another developer might test the feature. The Product Owner might validate important flows. A founder might do exploratory testing.

The important thing is that "the person who wrote it tested it" shouldn't be your entire quality strategy once failures actually matter.

Testing is a skill

There's a subtle assumption behind the "developers can just do the testing" argument:

Testing is something anyone can do after they're done with their real work.

I don't think that's true.

Writing reliable software is a skill.

Understanding a product deeply is a skill.

Understanding how real users behave is a skill.

Knowing how to systematically find defects is also a skill.

Good testers don't just take the requirements and verify that each sentence is technically true.

They ask annoying questions.

What happens if I do this twice?

What happens if the network disappears here?

What if I'm already logged in?

What if I'm not logged in?

What if I came here from a different page?

What happens on Safari?

What happens with a very long customer name?

Can I go backward in this flow?

What happens if the API takes six seconds instead of 200 milliseconds?

Does this technically work but feel terrible to use?

That mindset takes time to develop.

And if your software engineers already feel overwhelmed by the amount of code they're expected to produce, adding another major responsibility doesn't magically create more hours in the week.

Sometimes it just means less development gets done.

Sometimes it means less testing gets done.

Sometimes both get done badly.

And sometimes people burn out while management congratulates itself for creating a "high-ownership engineering culture."

Your industry changes the answer

A two-person startup building an experimental social app has a very different risk profile from a two-person startup building software used in a hospital.

The phrase "move fast and break things" sounds very different when the thing you're breaking is connected to healthcare, aviation, banking, financial infrastructure, automotive systems, defense, energy or utilities.

In those environments, quality problems can go far beyond an annoyed customer refreshing a page.

There can be financial consequences, regulatory consequences, contractual consequences and, in some cases, safety consequences.

But you shouldn't limit this thinking to traditionally regulated industries.

A product can become mission-critical without belonging to a mission-critical industry.

Endtest is a good example.

Our software is often deeply integrated into customers' CI/CD pipelines. If we break the wrong functionality, we aren't simply making a dashboard slightly inconvenient. We can interrupt the processes customers use to validate and release their own software.

The relevant question isn't:

Is this an internal application or a customer-facing application?

It's:

What happens when this application doesn't work?

Some internal applications are far more critical than many public websites.

Budget matters too

Now let's go in the opposite direction.

Imagine you have three developers, six customers and $4,000 in monthly recurring revenue.

Should your next hire automatically be a dedicated QA engineer?

Probably not.

Your scarce resources may generate significantly more return somewhere else: another engineer, sales, customer support, product development or simply extending your runway.

At that stage, a reasonable quality strategy might involve developers testing each other's work, founders testing important flows, good unit and integration coverage, a focused automated end-to-end suite, and careful testing before releases.

You accept some risk because eliminating that risk would cost more than the business can reasonably justify.

That's not negligence.

That's prioritization.

But the equation changes as the company grows.

If you have thousands of paying customers, healthy revenue and enough engineering work to keep ten developers busy, the cost of adding a strong QA engineer may be tiny compared with the value of preventing defects, reducing developer interruptions and improving release confidence.

Quality has a cost.

Poor quality has a cost too.

The second number is just harder to put into a spreadsheet.

The consequences can take years to appear

This is why I'm skeptical of organizational decisions justified entirely by immediate cost savings.

"Let's eliminate QA and have developers test everything."

"Let's replace customer support with chatbots."

"Let's remove this review step."

On a spreadsheet, the benefit appears immediately.

Three salaries disappeared.

Great quarter.

The downside is delayed.

Maybe defects gradually increase.

Maybe releases become more stressful.

Maybe developers spend more time reproducing customer issues.

Maybe customers stop trusting new releases.

Maybe the product develops dozens of small usability problems that aren't individually severe enough to trigger an incident but collectively make the experience worse.

Maybe customers eventually leave.

By then, the person who made the original decision may be in a different role or at a different company.

Complex systems are inconvenient that way.

The effects don't always arrive in time for the quarterly review.

Be suspicious of simple answers to complicated questions

This principle extends far beyond QA.

Ask a good doctor what you need to do to live a long and healthy life.

You'll probably hear about exercise, nutrition, sleep, genetics, stress, alcohol, smoking, preventative care, existing conditions and a dozen other factors.

There will be a lot of "it depends."

Then ask a health influencer.

You may discover that the answer was cold plunges all along.

Preferably combined with the supplement they're selling.

Software management has its own version of this.

Every few months, someone discovers a revolutionary new rule.

Everyone should write JavaScript.

Everyone should be full-stack.

Nobody needs QA.

Nobody needs Product Managers.

AI will replace developers.

AI will replace testers.

Everyone should do everything.

You can usually identify questionable advice by how few conditions are attached to it.

The more complicated the system, the more suspicious I become when someone claims to have found one universal organizational rule.

AI doesn't remove the need for testing judgment

AI makes this discussion more interesting.

It can write code.

It can generate unit tests.

It can create Playwright tests.

It can inspect a page and suggest test scenarios.

Those are useful capabilities.

But "Claude ran some Playwright tests" and "we have a reliable quality process" are not the same statement.

For a prototype with zero users, having an AI agent build a feature and run a few browser tests may be exactly the right tradeoff.

I wouldn't apply the same standard to a mature product that people depend on every day.

Real users are using your web application in Chrome, Safari, Firefox and Edge. They're on Windows and macOS. They have different screen resolutions, network conditions, browser extensions, permissions, account histories, data and geolocations.

They're also doing things you didn't expect them to do.

This is why cross-browser testing and end-to-end testing against realistic environments still matter.

A collection of AI-generated Playwright scenarios running headlessly in a Linux container can be useful.

It isn't reality.

Automation is leverage, not a substitute for thinking

I'm obviously a believer in test automation. I've spent a large part of my career working on it.

Done well, automation is enormous leverage.

A test that would require a person to repeat the same 15-minute workflow every day can run hundreds of times across different environments without that person touching it.

That's valuable.

Done badly, test automation can become a second buggy software product that your engineering team has to maintain.

You end up with flaky tests, false positives, false negatives and people rerunning failed pipelines until they turn green.

Eventually, nobody trusts the suite.

The goal isn't maximum automation.

The goal is maximum useful confidence for the resources you're spending.

And despite what some AI demos imply, not every useful quality check should be automated.

Some flows are expensive to automate relative to their value.

Some change too frequently.

And some aspects of quality are fuzzy.

Does this onboarding flow make sense?

Does this interface feel confusing?

Does something about this interaction feel wrong?

Would a non-technical customer understand what to do next?

AI is getting better at these questions.

Humans are still remarkably good at noticing the little things that make software pleasant or unpleasant to use.

Unit tests don't replace end-to-end testing

These layers solve different problems.

A unit test can prove that a function behaves exactly as expected while the product remains completely unusable.

The backend can work.

The frontend can work.

The API can work.

The authentication provider can work.

The payment integration can work.

And the complete checkout flow can still be broken.

That's why end-to-end web testing exists.

You're testing the system the way a user encounters it, not merely proving that individual pieces behave correctly in isolation.

Good engineering organizations use multiple layers of testing.

They don't spend their time arguing about which single layer should replace all the others.

AI-generated test scenarios are a starting point

Another trap in the AI era is confusing a long list with a comprehensive list.

Ask an LLM for test scenarios and it can generate 50 of them in seconds.

The output looks impressive.

Happy path.

Invalid input.

Empty input.

Long input.

Special characters.

Network errors.

Permissions.

Mobile.

Accessibility.

Great.

But the scenarios that matter most are often buried in knowledge that isn't contained in the ticket.

A particular enterprise customer has an unusual workflow.

Users regularly open three tabs.

Customers from one country use a specific payment method.

An old account type behaves differently.

A workflow depends on an email arriving before another request completes.

Users don't understand what a particular button means and repeatedly click it twice.

AI doesn't magically know those things.

Analytics and session recordings can reveal some of them.

Customer support can reveal others.

The rest comes from actually talking to users and understanding the product.

That's why I prefer using AI to expand a test strategy rather than define it.

Come up with the important scenarios yourself.

Then ask AI what you may have missed.

The order matters.

A good QA engineer is more than someone who executes tests

This is another reason the discussion gets confused.

If your definition of a QA engineer is someone who receives a finished feature, manually follows five written steps, marks it "passed" and sends it back, then yes, you may question the value of the role.

That's a very narrow version of QA.

A strong QA engineer learns how the product works and why customers use it.

They talk to Product Owners before implementation.

They challenge ambiguous acceptance criteria.

They talk to developers about testability.

They identify risky areas before code is written.

They build and maintain useful automation.

They perform exploratory testing.

They understand which browsers, devices and environments your customers actually use.

They investigate production defects and use what they learn to prevent similar failures.

They become a bridge between the business side of the product and its technical implementation.

That's a valuable person to have around.

But the word strong matters.

Hiring inexperienced, disengaged QA engineers and throwing tickets over the wall to them isn't going to magically produce a great product.

A small number of skilled and motivated QA engineers who have enough time to understand the product can be far more valuable than a large QA team measured by how many test cases it executes.

So, do you need dedicated QA engineers?

Here's the framework I would use:

1. How expensive is a defect? A typo on an experimental landing page and an incorrect financial transaction deserve different quality strategies.
2. How many real users depend on the product? More users usually means more environments, more workflows, more edge cases and a larger blast radius.
3. How stretched is the engineering team? If developers are already overloaded, assigning them an entire second discipline doesn't make the work disappear.
4. How complex is the product? Multiple integrations, browsers, devices, roles, permissions and workflows all increase the value of specialized testing.
5. How much can you afford? A pre-revenue startup shouldn't copy the staffing model of an enterprise company, but a profitable company shouldn't use startup scarcity as an excuse forever.
6. How critical is the software? Regulation matters, but so does practical dependency. Ask what happens to customers when the product fails.
7. Who provides the independent perspective? Even without a dedicated QA employee, somebody other than the author of the feature should critically evaluate important changes.
8. Who understands your users? Effective testing requires knowledge of what customers actually do, what they care about and what environments they use.

If you're building an early product with little revenue, few users and low consequences when something breaks, I probably wouldn't rush to hire dedicated QA engineers.

Use the resources elsewhere and build a sensible lightweight testing process.

If you have the budget, a growing user base, significant product complexity and customers who depend on your software, dedicated QA engineers become much easier to justify.

And if failures can cause serious financial, regulatory, operational or safety consequences, I would be extremely careful about designing your quality strategy around saving one salary.

Quality is everyone's responsibility. Testing doesn't have to be.

There's a sentence I agree with:

Quality is everyone's responsibility.

Developers should care about quality.

Product Managers should care about quality.

Designers should care about quality.

Executives should care about quality.

QA engineers should care about quality.

But "everyone is responsible for quality" does not logically lead to "therefore nobody needs to specialize in testing."

Security is everyone's responsibility too.

Most serious companies still hire security specialists.

The AI era is actually making this distinction clearer.

We're discovering very quickly that producing code wasn't the entire job of building good software.

Code is becoming cheaper to generate.

Judgment isn't.

Understanding users isn't.

Knowing which compromises are safe isn't.

Recognizing that something technically works but shouldn't ship isn't.

Knowing where to look for the failure nobody else considered isn't.

Those are human inputs.

And as our ability to produce software gets faster, I suspect they'll become more valuable, not less.

So don't hire QA engineers because some testing handbook says every team needs them.

And don't fire them because somebody posted that developers should own everything.

Look at your product.

Look at your users.

Look at the consequences of failure.

Look at your team.

Look at your budget.

Then make the decision that fits the company you actually have.