The Death of the Non-Coding QA Role

Now cross-posted on Medium.

If job postings, career paths, and hip tech blogs are any indication, the non-coding Quality Assurance (QA) role is dead. Driven by some of the same forces driving Operations' shift to DevOps, urgent needs for Automated Testing pushed non-coding QA roles right out of the hiring budget. What kind of gap will the departure of non-coding QA roles leave in development organizations? This article makes some observations and suggestions about the path forward.

What have Non-Coding QA Professionals been Doing all this Time?

In the organization in which I started my software career, a typical non-coding QA engineer performed the following functions:

1. Defined test cases and testing strategy;
2. Acted as deputy Product Manager to ensure that features were developed to fill a business need, in a way that customers would value;
3. Acted as Project Manager/Business Analyst to keep dev projects on schedule and shepherd teams through business processes;
4. Executed manual functional testing for regressions and new features; and
5. Executed all the kinds of tests you get "for free" by executing manually: exploratory, install, upgrade, configuration, edge-case, and user experience.

Just to level-set, automated testing is only a direct, superior replacement for #4: the execution of functional tests. Other aspects of the non-coding QA role demand solutions that go beyond the automated testing pipeline.

Generalists

Non-coding QA professionals serve a valuable role as reliable, business-connected, generalists to fill whatever gaps exist in a particular development organization, commonly acting as deputy Product or Project Managers (list items #2 and #3). Quality Assurance's role in release management -- and it's need to carefully provision resources across dev projects -- gives it a natural affinity for business and process, but QA has probably filled other needs as well.

Agile -- itself one of the forces creating the need for test automation -- provides a solution in this regard. An Agile Product Owner acts as a business representative on a development team (see list #2). An Agile Scrum Master helps the development team manage process and stay accountable for timelines (see list #3). Indeed, many non-coding QA professionals have made a seamless transition to these roles -- so if your organization is considering either "How do we utilize our existing non-coding QA talent?" or "Where can be find good candidates for our new Agile roles?" -- here is a ready answer.

Human Eyes and Ears

As noted above, manual testing comes with a lot of nearly-freebie types of product quality coverage (see list #5). After installing the company's product 10 times a week, manual testers tend to speak up about that one administrative control that seems to take forever or works counterintuitively. That's a really, really good thing for companies that take advantage of it: free User Experience (UX) testing.

UX finally has a well-recognized name because it matters more than ever. In the past, many companies did not have dedicated UX experts; the free coverage from manual testing may have been one reason why. Today, many development organizations invest in dedicated UX designers, but what about UX Quality Assurance? Many organizations expect the UX design team to play both the development and QA positions, but there are two good reasons not to do this:

1. Checks and balances -- consistent quality demands an outside perspective, and
2. Specialization -- the UX design team spends it's time on production and cannot (reliably) spend the focus and time to develop expertise in new UX field activities like interacting with and getting feedback from real customers.

Wise companies might identify their most sensitive and savvy non-coding QA professionals and re-charter them as focused UX testing experts. Customer expectations in this area will only continue to grow, and at the same time, incidental coverage of UX will only continue to decrease as the release pipeline becomes automated.

Note: For other low-value tests (see list #5), it's a simple cost-value calculation -- spend resources to automate them, spend money to outsource them, let your customers find them (ick) -- whatever provides the most value for the least cost.

Quality Assurance Experts

The non-coding QA professional is first and foremost an expert in Quality Assurance: the study of practices, processes, and controls to ensure that customers receive a high-quality, defect-free product. These QA specialists are being replaced by specialists in a new field: QA Automation. This distinction is a nuanced, but worthwhile. The QA Automator studies how to build an automated pipeline that receives and appropriately validates, rejects, and/or provides feedback for code of indeterminate quality. Aspects of QA like performance, UX, organizational/business process, etc. will probably not receive equal consideration.

Furthermore, as recognized in the philosophy espoused in How Google Tests Software, SETs (Software Engineers in Test) and Test Automators tend to have a development focus. After all, it is what they do... They interact with the product in the same way that developers do (through code), and many technical aspects of their craft occupy their attention.

So, if the roles "killing" non-coding QA are not providing the same expertise...

Who are the new Quality Assurance Experts?

Test Engineers

Some organizations seek to maintain Quality Assurance expertise by adopting Google's "Test Engineer" role. The Test Engineer role essentially mirrors the old, non-coding QA role, except test automation replaces manual test execution. This allows an easy transition: keep all the existing staff with minimal fuss, and just add coding to their learning plans. This works fine for many QA employees, although the danger remains that the role will select for individuals with capacity to automate over individuals with Quality Assurance expertise.

Quality Managers

What happens if brilliant, non-coding QA professionals who provide undeniable value to the organization -- who see their value in terms of their quality expertise and not in embarking on a new path by learning to code -- become marginalized by the addition of coding to the QA career path? Here I'm referring to the non-coding QA engineers who seems to be leading and speaking for every project they are on; who are associated with challenging, but ultimately successful projects; who get pulled into customer relationships; who know who to talk to and how to talk to them to produce results; and who have passionate opinions about how processes and strategies impact Quality. I have seen these individuals pull success from the jaws of failure on critical projects, and theoretically development organizations should be fighting over, not marginalizing, their talent.

The key question ends up being: "Is there room in software development organizations for professionals who do not code?" Consider Product Management. Product Managers are development-aligned professionals who marshal and prioritize resources within an overall product strategy to achieve maximum market value from development efforts. Outside of a minority of ex-programmers, they do not code, and they do not need to.

The Quality Manager would be a Quality Assurance-aligned role that parallels Product Management. The Quality Manager is a specialized expert focusing on marshaling and prioritizing resources within an overall strategy to ensure product quality. This role can:

• House and cultivate Quality Assurance expertise and utilize this expertise to develop a product quality assurance strategy,
• Ensure that resources are deployed to achieve maximum product quality coverage,
• Prioritize initiatives across teams so that teams focus on the highest-value efforts,
• Provide Quality Assurance feedback from the market, and
• Assume the currently-missing role across from Product Management in the conversation about how to prioritize efforts between quality and new feature work.

Your organization probably already has the perfect candidate to pilot and develop a Quality Manager role, and they are probably searching in vain for job descriptions that match their expertise.

TL;DR: Summary of Recommendations

Test Automation replaces only the manual functional test execution portion of the non-coding Quality Assurance (QA) role. Other, less-appreciated aspects of the role need different solutions:

• Organizations must consider how to supply development teams with generalist, business-connected talent; those robustly implementing Agile practices can utilize Product Owners and Scrum Masters. Non-coding QAs tend to be good at these roles.
• User Experience (UX) focus and staffing should be increased relative to the progress of release pipeline automation, and some of the prime talent candidates for these roles should come from QA.
• Finally, development organizations need to cultivate non-automation-focused expertise in Quality Assurance. Many engineers can swap manual testing for test automation and assume the Test Engineer role. Some of the best, people/process-oriented, non-coding QA professions should be tapped a new role: Quality Manager.