What Happens After QA Says “Passed”?
For a long time, my view of software quality ended at a fairly clear point.
You test the feature.
You verify the requirements.
You report the bugs.
The bugs get fixed.
You retest.
And eventually, you say:
Passed.
At the beginning of my QA career, that felt like the finish line.
Today, I see it very differently.
Because one question kept coming back to me:
What actually happens after QA says “passed”?
That question gradually pulled me outside the boundaries of traditional testing and into CI/CD, Linux, infrastructure, deployment, observability, alerting, and eventually release engineering.
Not because I wanted to stop being a QA engineer.
Quite the opposite.
I wanted to understand the rest of the system that QA was trying to protect.
“Passed” doesn’t mean the software is in production
This sounds obvious to me today.
It wasn’t always obvious.
A feature can pass testing and still have a long journey ahead of it.
Somewhere after QA, things like this start happening:
QA PASSED
↓
Build
↓
Package
↓
CI/CD Pipeline
↓
Environment Configuration
↓
Deployment
↓
Database Changes
↓
Infrastructure
↓
Health Checks
↓
Monitoring
↓
Production
And every one of those steps introduces another opportunity for something to go wrong.
The application can work perfectly in QA and fail because production configuration is different.
The code can be correct while an external dependency behaves differently.
A database migration can introduce a problem that wasn't visible during feature testing.
A deployment can technically succeed while the service becomes unhealthy minutes later.
The application can be running while nobody notices that the error rate is slowly increasing.
QA saying “passed” is important.
But it is only one piece of a much larger process.
Even environments were confusing at first
When I entered QA, there were many things I had to learn from the beginning.
One of them was something that feels completely normal to me today:
DEV → QA → STG → PROD
At first, I didn't really understand why software needed so many environments.
Why could something work in one environment and fail in another?
Why couldn't we simply test it and deploy it?
Why did configuration matter so much?
They sound like beginner questions because they were beginner questions.
I was coming into software after spending many years in mechanical engineering and manufacturing.
Software development had its own language, processes, and mental models.
I had to learn them.
But those questions turned out to be useful.
Once I stopped seeing environments as boxes with different labels and started understanding what was actually different between them, I also became better at testing software.
Different data.
Different configuration.
Different infrastructure.
Different integrations.
Different dependencies.
Different failure modes.
Environment differences aren't only a DevOps problem.
They can change application behavior.
And anything that changes application behavior should be interesting to QA.
CI was another world I wanted to understand
For some time, CI pipelines were something I mostly consumed.
A job ran.
Tests passed or failed.
There was a report.
Maybe I needed to investigate a failure.
But the system behind it wasn't really something I understood deeply.
Eventually that stopped being enough for me.
I wanted to know:
- What triggers the pipeline?
- What happens before my tests start?
- How are dependencies installed?
- Where does configuration come from?
- How are artifacts created?
- What happens when one stage fails?
- What happens after everything turns green?
Once you start looking at CI this way, automated tests stop being isolated scripts.
They become signals inside a much larger delivery system.
That changed the way I looked at test automation.
Automation made the boundaries less clear
My early QA work was mostly manual.
Automation was something I admired in the work of other engineers.
Later I learned Python, started building my own projects, and gradually moved deeper into automation.
Today I work with Robot Framework and Playwright with TypeScript.
And the deeper I went into automation, the more I had to understand everything around the test itself.
Automated tests need environments.
They need data.
They need services.
They need configuration.
They need reliable execution.
They need CI.
And when they fail, the reason isn't always the test.
Sometimes the application is broken.
Sometimes the environment is broken.
Sometimes a dependency is unavailable.
Sometimes the test data is wrong.
Sometimes deployment changed something.
Sometimes infrastructure is the real problem.
The more automation I worked with, the harder it became to say:
That's not QA. That's DevOps.
The boundary simply wasn't that clean anymore.
A failed test doesn't always mean a product defect
This became an important lesson for me.
Imagine an end-to-end test fails.
At first glance, all we know is:
TEST FAILED
But the actual cause might be:
Application bug
or:
Environment instability
or:
API unavailable
or:
Deployment issue
or:
Network problem
or:
Broken test data
or simply:
Test bug
The failing test tells us that something didn't behave as expected.
Understanding why often requires knowledge outside traditional testing.
Logs.
Processes.
Services.
APIs.
Containers.
CI jobs.
Deployment history.
Metrics.
Infrastructure.
The more of that context I understood, the faster I could investigate failures.
And that was the point where DevOps knowledge stopped feeling like something belonging to another team.
It started becoming useful QA knowledge.
Linux helped more than I expected
One thing made this transition easier for me.
Linux had already been part of my life for years.
I had started experimenting with Linux long before I entered QA, and Bash never felt completely foreign to me.
So when my work started moving closer to CI, servers, logs, containers, processes, and infrastructure, there was already something familiar underneath it.
Commands and tools like:
ps
grep
curl
tail
journalctl
ssh
docker
became useful ways to investigate what the system was actually doing.
And that reinforced something I gradually came to believe:
A QA engineer doesn't need to become a full DevOps engineer, but understanding the environment where the software actually runs can make you much better at QA.
Then I started looking at observability
Over time, my curiosity also moved toward alerting and observability.
And that opened another question.
Traditional testing usually asks:
Does the application behave correctly before release?
Observability asks:
Is the application still behaving correctly after release?
Those worlds are closer than they might seem.
A test may tell me:
Checkout completed successfully in staging.
Monitoring may later tell me:
Checkout error rate increased after deployment.
Both are quality signals.
They simply exist at different points in the software lifecycle.
Once I started thinking about quality this way, production stopped feeling like the place where QA responsibility simply ends.
Production became another source of evidence.
QA can learn a lot from DevOps
I don't think every QA engineer needs to become an infrastructure specialist.
That's not the point.
But I do think QA benefits enormously from understanding things like:
- CI/CD
- Linux
- containers
- environment configuration
- deployment strategies
- logs
- monitoring
- alerting
- rollback
- infrastructure basics
- application dependencies
Because all of these things affect software behavior.
And understanding software behavior is exactly what QA is trying to do.
The deeper I went into these areas, the more I realized that testing a feature in isolation only gives us one perspective.
Users don't interact with test cases.
They interact with the entire running system.
DevOps changed the questions I ask
Earlier in my QA career, many of my questions were focused on functionality.
Does login work?
Can the user complete checkout?
Does the API return the expected response?
Does the validation behave correctly?
Those questions still matter.
But now I also find myself asking:
What happens if this dependency becomes unavailable?
How will we know if this starts failing in production?
What happens if deployment fails halfway through?
Can we roll this back?
What changed between environments?
What evidence do we have that the release is healthy?
Who notices first when something goes wrong?
Those aren't purely testing questions.
They are software delivery questions.
And I think QA belongs in those conversations.
I didn't move toward DevOps because I wanted to leave QA
This is probably the most important part.
I wasn't trying to escape QA.
I wasn't thinking:
Testing isn't technical enough. I need to become DevOps.
It happened much more naturally than that.
QA kept giving me questions that testing alone couldn't answer.
A failed automated test led me to logs.
Logs led me to services.
Services led me to containers.
Containers led me to infrastructure.
CI led me to deployment.
Deployment led me to monitoring and alerting.
And eventually all of those things led me toward release engineering.
It wasn't really a career switch.
It was an expanding field of view.
Quality doesn't stop where testing stops
Today I think about software quality very differently than when I entered QA.
Quality isn't one department.
It isn't a test suite.
It isn't a green automation report.
And it isn't one stage inside a pipeline.
Quality exists across the whole software delivery lifecycle.
CODE
↓
BUILD
↓
TEST
↓
PACKAGE
↓
DEPLOY
↓
OPERATE
↓
OBSERVE
↓
LEARN
Problems can appear anywhere.
Understanding more of that lifecycle gives QA more context for the decisions we make.
It helps us test better.
Debug faster.
Ask better questions.
And recognize risks that might never appear inside a normal test case.
Eventually I started asking a different question
Once I started looking beyond testing, something else became difficult to ignore.
Suppose we have:
Build PASS
Tests PASS
Security PASS
Deployment READY
Does that automatically mean we should release?
What if the change is unusually large?
What if it contains a database migration?
What if rollback hasn't been tested?
What if monitoring is incomplete?
What if QA coverage is weaker than usual?
Nothing is necessarily red.
But that doesn't automatically make the release low-risk.
That was the point where my interest started moving beyond deployment itself.
From:
Can we release this?
to:
Should we release this?
Those are two very different questions.
And that is where release engineering became especially interesting to me.
I didn't move toward DevOps because I wanted to stop being a QA engineer.
I moved toward it because I wanted to understand what happens after QA says “passed”.
And the more I understood, the clearer it became that testing is only one part of software quality.
The rest of the story happens before, around, and after it.
This is the first article in my From QA to DevOps / Release Engineering series.
In the next parts, I want to write about CI/CD from a QA perspective, debugging beyond the test layer, why observability matters to testers, and how understanding deployment and infrastructure changed the way I think about release risk.
