When I started moving from QA and validation toward Cloud and DevOps, I initially thought I had to leave my QA background behind.
I was wrong.
The more I worked with AWS, Terraform, Kubernetes and CI/CD, the more I realized that many habits I developed as a QA engineer were still useful — sometimes even more than I expected.
Here are the lessons from QA that I now carry into my Cloud and DevOps projects.
1. Think about failure before success
QA teaches you not to ask only:
“Does it work?”
You also ask:
- What happens if the service is unavailable?
- What happens if a dependency fails?
- What happens with invalid input?
- What happens under load?
- What happens after a restart?
This mindset became very useful when working with Kubernetes and AWS.
For example, when building my LibraryCorner project on Amazon EKS, I didn't want to validate only that the application was running.
I also looked at scaling, health checks, database availability, monitoring and recovery.
The question changed from:
“Can I deploy it?”
to:
“How does it behave when something goes wrong?”
2. Automation is more than saving time
Automation was already part of my QA work.
Tests, validation processes and repetitive checks are much more reliable when they can be executed automatically.
Moving into DevOps made this principle even stronger.
Infrastructure can be automated with Terraform.
Application delivery can be automated with CI/CD.
Kubernetes can automatically maintain the desired state.
Monitoring can continuously check what is happening.
The goal isn't simply to eliminate manual work.
It is to make processes repeatable, predictable and easier to trust.
3. Reproducibility matters
One of the most frustrating situations in testing is:
“It worked on my machine.”
A good test environment should be reproducible.
The same principle applies to infrastructure.
With Terraform, I can describe infrastructure as code instead of manually creating resources in the AWS console.
With Kubernetes manifests and Kustomize, I can define application configurations consistently across environments.
This changed the way I think about infrastructure.
Instead of asking:
“How did I configure this?”
I can ask:
“Can I reproduce this configuration?”
That's a much better question.
4. Observability is part of validation
QA engineers spend a lot of time looking for evidence.
Logs, test results, error messages and system behavior help answer:
“What actually happened?”
Observability follows the same principle.
While working on LibraryCorner, I implemented Prometheus and Grafana monitoring for my EKS environment.
Metrics aren't just dashboards that look nice.
They provide evidence about what the system is doing.
CPU usage, pod count, resource consumption and application behavior can help explain why something happened.
For me, observability is therefore closely related to validation:
you cannot validate what you cannot see.
5. Testing doesn't disappear in DevOps
Before moving into Cloud, I sometimes associated DevOps with infrastructure, pipelines and deployments.
Today, I see it differently.
Testing is still there.
It simply becomes part of a larger feedback loop.
Code changes → tests → build → deployment → monitoring → feedback.
The objective is to detect problems earlier and shorten the time between a change and reliable feedback.
That is one of the reasons my QA background fits naturally into this environment.
6. My mindset changed more than my tools
The biggest lesson from this transition is that moving from QA to DevOps isn't only about learning new technologies.
Yes, I had to learn AWS, Terraform, Kubernetes, Linux, networking and CI/CD.
But the most valuable thing I brought with me wasn't a specific tool.
It was a way of thinking:
- Challenge assumptions.
- Look for failure scenarios.
- Automate repetitive work.
- Make environments reproducible.
- Collect evidence.
- Monitor what happens after deployment.
These principles remain useful regardless of whether the system is a test environment, a Kubernetes cluster or an AWS architecture.
From QA to Cloud
My transition from QA/validation to Cloud and DevOps didn't mean starting from zero.
It meant building on top of what I already knew.
QA taught me to question systems.
Cloud and DevOps are teaching me how to build, automate and operate them.
And I'm discovering that these two perspectives complement each other more than I initially expected.
That's probably the most important lesson I've learned so far in this transition.
Your previous experience doesn't necessarily disappear when you change careers. Sometimes, it becomes your advantage.
Top comments (0)