DevOps Foundations # 1- DevOps for QA Engineers: What Actually Changes for Testing?

When code can reach users in hours, the “testing phase” has nowhere to live. Here is what takes its place.

A team finishes a story on Tuesday morning. The code is merged by noon. The pipeline builds it, deploys it to a test environment and then... waits.

It waits for QA. A tester picks it up on Wednesday, runs the regression checklist by hand and signs off on Thursday. It reaches production on Friday.

The team calls this DevOps. They have a pipeline, they have Jenkins and they deploy every week. But the story spent four days waiting for one manual step, and it will do the same next week.

They adopted the tools. They didn’t change how quality works.

What DevOps is, without the buzzwords

DevOps is a way of working where the people who build software and the people who run it share responsibility for getting it to users quickly and safely.

It started as a fix for an old problem. Developers wrote code and threw it over the wall to an operations team, who had to deploy and run it. Developers wanted to ship fast. Operations wanted stability. Each side blamed the other when things broke.

DevOps removes the wall. In practice, that usually means:

• Shared ownership. The team that builds it also cares how it runs in production.

• Automation. Build, test and deploy steps run through a pipeline, not a manual checklist.

• Small, frequent releases. Many small changes are easier to test and roll back than one big release.

• Fast feedback. Monitoring and test results tell the team quickly when something is wrong.

DevOps is not a job title, a tool or a team you hire. Jenkins, Docker and Kubernetes support it, but they aren’t DevOps themselves.

DevOps vs Agile: what actually changed

Agile fixed a planning problem. Instead of a year-long plan and a big-bang delivery, teams work in short sprints, get feedback and adapt.

But many Agile teams hit a wall. They built working software every two weeks, then waited weeks for it to be deployed, because release was still manual, risky and owned by someone else.

They aren’t competitors. They solve different halves of the same problem.

For testing, the consequence is significant. In a sprint-based world, testing could sit in a “testing phase” near the end. When code can reach production in hours, that phase disappears. Testing has to happen continuously and automatically, inside the pipeline.

What actually changes for testing

This is the heart of it. Here are the shifts QA engineers feel most.

1. From a gate to a safety net

In older models, QA sat between development and release. Code arrived, QA tested it and a sign-off said whether it could go.

In DevOps, that single gate is replaced by quality checks at every stage. QA’s role moves from being the gate to designing and strengthening the safety net.

2. From a phase to a continuous activity

Quality work now happens along the whole path:

If a stage on that table is empty in your team, that’s where QA input is missing.

3. From manual regression to fast, trusted automation

When you release often, manual regression before every release stops scaling. If deployments double, so does the manual effort. Repetitive checks have to move into the pipeline.

But the pipeline only helps if its tests are fast, stable and trusted. A slow or flaky suite gets ignored, and people start re-running builds until they go green. That’s worse than having no gate at all.

4. From finding defects to managing risk

With small, frequent releases, the question changes. It’s less “have we found every bug?” and more “do we know what could go wrong, and could we recover quickly if it does?”

That brings in practices like:

• Feature flags, so risky changes can be switched off without a redeploy

• Canary or gradual releases, so a new version reaches a small group first

• Rollback plans, so recovery is routine

• Monitoring and alerting, so problems are caught within minutes

QA’s job extends to asking whether those safety measures exist and work.

5. From owning testing to sharing it

In a DevOps team, quality isn’t one person’s job. Developers write unit and component tests. QA and SDETs design strategy and automation. DevOps engineers keep environments and pipelines reliable. Everyone is accountable for quality, and QA helps the team do it well.

DevOps engineer vs QA vs SDET: who owns what?

These roles overlap, and the exact split differs between companies. A rough, commonly used version:

• QA engineer: product quality and risk. Test strategy, test design, exploratory testing, defect analysis and acceptance from the user’s point of view.

• SDET: a developer-minded tester. Builds and maintains the automation framework, test tooling, test data utilities and CI integration for tests.

• DevOps engineer: the delivery platform. CI/CD pipelines, infrastructure, environments, deployment, monitoring and release reliability.

The overlap is where things get fuzzy:

• The pipeline is built by DevOps, but the tests inside it are owned by QA and SDET.

• Environments are provisioned by DevOps, but test data and test readiness often need QA input.

• Flaky tests can come from test code, infrastructure or the application. Someone has to own the triage.

The better question isn’t “whose job is it?” but “who is accountable, and who is consulted?” Unclear ownership is where failures hide, such as a broken pipeline stage that everyone assumes someone else is fixing.

In smaller teams, one person may wear two or three of these hats. That’s fine, as long as the responsibilities are explicit.

A quick exercise: list three recurring problems, such as flaky tests, broken environments and slow builds. Write an owner next to each. Any problem without a name is a gap.

Scenario: daily deployments, manual testing before release

A team deploys daily, but a manual testing step sits before every release. Is that really continuous delivery?

First, what continuous delivery means: the software is always in a releasable state, and the path to production is automated and repeatable, so releasing is a routine business decision, not a risky event.

Questions to ask about the manual step:

• How long does it take? If it takes most of the day, that’s the real limit on speed.

• Is it checking the same regression flows every time? If so, those are automation candidates.

• What happens when it finds something? If it blocks the release, it’s acting as a gate.

• Does it scale? If deployments double, does the testing time double too?

My honest answer: it’s an early stage, not full continuous delivery. It’s frequent deployment, but the manual step is what the pipeline waits for.

Manual testing as such isn’t the problem. Exploratory testing, usability checks and new-feature investigation are valuable and don’t need to block every deploy. Manual regression is the part that doesn’t scale.

A practical path forward:

1. Automate the repetitive regression checks first, starting with the highest-risk flows.

2. Run them in the pipeline on every change.

3. Move manual testing into exploratory sessions on new or risky changes, running alongside the pipeline instead of in front of it.

4. Use feature flags and monitoring so risk is also managed after release.

To find your starting point, time the manual testing step for a week. If it’s the longest stage on the path to production, that’s your first automation target.

How to tell whether your testing fits DevOps

Some quick questions that give an honest read:

• Can a change go from commit to production without anyone doing manual regression?

• Does the pipeline fail fast, with clear reasons?

• Can the team trust a red build, or do they assume it’s flaky?

• Is there a rollback or feature-flag option for risky changes?

• Does anyone look at production monitoring as part of quality?

• Is ownership of each pipeline stage clear?

• Is exploratory testing still happening, in parallel instead of as a gate?

If most answers are “no,” the team has adopted DevOps tooling more than DevOps practice.

Skills that help a QA engineer in a DevOps team

You don’t need to become a DevOps engineer. But these give you a real advantage:

• CI/CD basics: reading a pipeline definition and knowing what runs at each stage

• Version control habits: branches, pull requests and reviewing test code

• Containers (Docker): running tests in consistent environments

• API testing: the layer pipelines can check quickly and reliably

• Reading logs and dashboards: finding the cause of a failure or an incident

• Test data and environment awareness: knowing what your tests depend on

• Risk-based thinking: deciding what must be checked on every change and what can wait

The takeaway

DevOps doesn’t remove the need for testing. It removes the place where testing used to sit. When code reaches users in hours, quality can’t be a phase at the end. It has to be built into every stage of the path.

For QA engineers, that’s an opportunity. The role moves from checking at the end to designing the system that keeps quality visible all the time.

If you remember one line from this article, make it this:

In DevOps, QA isn’t the gate at the end. QA is the safety net that runs the whole way.

Your turn: Does your team’s testing fit the pipeline, or does the pipeline wait for testing? What’s the biggest blocker? Reply or leave a comment. I’d like to hear it.

This is part of the DevOps Foundations series. Next: From Git Commit to Production: The Software Delivery Pipeline.