I recently retired from a career in High Tech that spanned over 40 years, with the last 25 or so focused on Software Quality Assurance (SQA). There were several reasons behind my decision to retire. The most prominent one was my desire to pursue a childhood dream. However, I must admit that another factor was the evolving nature of Software QA in modern times, and my inability to keep up with the changes.

As we age in the High Tech industry, many of us struggle to keep pace with the latest advancements in software engineering. During our youth, particularly in college, we dedicated our days to learning and applying new concepts. Our minds were sharp and receptive to absorbing new information. However, after a decade or more, it becomes increasingly challenging to stay up to date. Non-learning tasks consume a significant portion of our time, and falling slightly behind leads to a snowball effect where catching up with the latest developments becomes overwhelming. That’s precisely what happened to me.

I found myself surrounded by young and brilliant software engineers who continuously produced astonishing frameworks and libraries. These advancements were both inspiring and intimidating. Unfortunately, just as I would start grasping one set of testing protocols and APIs, another would emerge and replace it. Each new paradigm was cutting-edge and had the potential to catch me off guard. I was certain that within a year or so, I would be unable to keep up, and my relevance would diminish. Retiring on my own terms was a privilege, and not everyone in my position could afford to do so.

Another concern of mine revolves around the excessive focus on software testing automation as the defining role of Software QA. Leaders in software companies, regardless of their size, increasingly view test automation as the key to maintaining high product quality while incorporating an ever-growing number of features. Admittedly, when test automation works, it excels at detecting certain types of regressions in products. Consequently, companies adopting this approach end up replacing traditional QA engineers with software developers who hope to transition into product engineering. However, software engineers and Quality engineers have fundamentally different priorities. Software engineers are primarily focused on making things work, especially through clever and efficient implementations. On the other hand, good Quality engineers concentrate on uncovering issues with the product—issues that Software engineers may not have anticipated. The best QA engineers possess the ability to envision the various ways users might utilize and potentially break the product. They excel at identifying logic flaws and ensuring that potential crashes and data problems are resolved before customers encounter them. This level of thoroughness cannot be achieved through testing automation alone. It requires humans to think creatively and deviously, a trait that software cannot yet emulate.

Hence, I observe the growing trend toward software testing automation with a certain amount of unease. As hands-on QA roles diminish and “software engineers in test” positions increase, who will be the ones scrutinizing the finer details? In my experience, software engineers tend to focus on testing the expected paths and often overlook testing for error conditions or deliberately pushing their products to their limits. Unless software firms recognize the need for some level of hands-on QA involvement, driven by individuals who find joy in discovering the most elusive bugs before customers do, software quality is bound to decline.