What QA Taught Me About DevOps

During my shift from QA and validation to Cloud and DevOps, I was initially concerned about leaving my QA background behind. However, I soon discovered that many habits developed as a QA engineer proved to be valuable in the new roles. Here are the lessons I've learned from QA that now guide my work in Cloud and DevOps.

1. Anticipating failure: QA training emphasizes considering potential failures beyond just whether a service works. This mindset proved useful when working with Kubernetes and AWS. For instance, while building my LibraryCorner project on Amazon EKS, I didn't just validate that the application was running. Instead, I examined scaling, health checks, database availability, monitoring, and recovery. The focus shifted from "Can I deploy it?" to "How does it behave when something goes wrong?"

2. Automation goes beyond time-saving: As part of my QA work, I had already implemented automation in the form of tests, validation processes, and repetitive checks. When transitioning to DevOps, automation became even more crucial. Infrastructure can be automated using Terraform, application delivery through CI/CD, Kubernetes maintains desired states, and monitoring continuously checks system behavior. The goal isn't merely to eliminate manual work; it's to make processes repeatable, predictable, and trustworthy.

3. The importance of reproducibility: In testing, the frustration of "It worked on my machine" is all too familiar. A reliable test environment should be reproducible. Similarly, infrastructure can be managed using Terraform to describe configurations as code, avoiding manual creation of resources in AWS. Kubernetes manifests and Kustomize allow for consistent application configurations across environments.

This shift in thinking about infrastructure has made the question "Can I reproduce this configuration?" more valuable than "How did I configure this?"

4. Observability as part of validation: QA professionals spend considerable time analyzing evidence - logs, test results, error messages, and system behavior - to answer what actually happened. Observability follows the same principle. During my work on LibraryCorner, I implemented Prometheus and Grafana monitoring for the EKS environment.

Metrics, which extend beyond mere dashboards, provide valuable evidence about system behavior. CPU usage, pod count, resource consumption, and application performance can help explain system behavior. Observability is thus closely related to validation: you can't validate what you cannot see.

5. Testing remains integral in DevOps: Initially, I associated DevOps with infrastructure, pipelines, and deployments. However, I now see it differently. Testing is still present, but it becomes part of a larger feedback loop. Code changes lead to tests, builds, deployments, monitoring, and feedback. The objective is to detect issues early and shorten the time between a change and reliable feedback. This aligns well with my QA background, where testing was a continuous part of the development process.

6. Mindset shift over tool adoption: The most significant takeaway from this transition is that moving from QA to DevOps isn't solely about learning new technologies. While I did have to learn AWS, Terraform, Kubernetes, Linux, networking, and CI/CD, the most valuable aspect I brought with me wasn't a specific tool. It was a mindset - challenging assumptions, seeking failure scenarios, automating repetitive tasks, ensuring reproducibility, collecting evidence, and monitoring system behavior.

These principles remain relevant, whether the system is a test environment, a Kubernetes cluster, or an AWS architecture.

In conclusion, my transition from QA/validation to Cloud and DevOps has been a natural progression. It built upon my existing knowledge, allowing me to leverage the valuable skills and mindset developed through my QA career. The shift has revealed that these two perspectives complement each other more than I initially anticipated, highlighting the importance of a well-rounded approach to system development and operation.