How to ship superior code by separating QA skillsets

Asking manual and automation QAs to merge skillsets can be a recipe for context switching. Separating them will result in significantly faster development cycles and productivity.

Illustration by Kate Mangostar

With the evolution of testing, there is an increasing discrepancy in job duties and obligations between manual and automation QA. As a manual QA, you are planning test suites, pairing with the development team to reproduce and log software defects, and crafting test cases to hit the expected (and unexpected) user paths in new features. As an automation QA, you are using tools and code to design, test, and deploy effective automation solutions and scripts in different test environments.

In my experience, it’s fairly difficult to context switch between manual and automation planning and testing. Not only is this difficult due to the nature of fast/staggered release cycles, manually testing new functionality/user flows/multi-device test scenarios, but also because in many cases, the developer to QA ratio largely exceeds the ideal 2:1 to 3:1 dev: QA.

Developers operate in “stacks” of software, in terms of tooling and languages they use for specific projects that allow them to hone their focus and specialize more efficiently. This concept of “stacks” should apply the same way to QA, but it does not. Manual and Automation QA have separate stacks, whether it be in test management or code. However, planning tests and coding tests are two completely divergent mindsets. Asking manual and automation QA to merge skillsets will cause a rise in context switching — and, inevitably, a significant contraction in productivity.

The major unstated difficulty with these high Dev: QA ratios is the misinterpretation that the QA workload and necessary coverage will not continue to increase after every release. Each additional feature will compound and add more test cases (not to mention on all compatible devices and browsers) to the already large major testing suite that will need to be tested every release cycle moving forward. This will multiply the QA’s time spent testing each cycle, all of which are still required to meet business demands for new feature implementation.

There are 3 outcomes of this.

1. Hire a proportional amount of QA to keep up with the increasing number of features being released.

2. Slow down release cycles to allow the QA “bottleneck” to catch up.

3. Threaten the overall quality of the product when QA does not have time to test comprehensively.

Training time might slow down the team for the first few months of a new employee onboarding, but that time investment will result in significantly faster development cycles and productivity to ship superior code to customers and stakeholders.

With the skillset requirements and needs between manual and automation QA, it makes sense to have two separate but interconnected teams to allow the QA to streamline their work process with less context switching.

If manual QA work specifically on planning cases and suites for feature developments, exploratory UX testing, and user flows, automation QA can write automation code for those new features and make sure new bugs were fixed. This would ensure that manual QA could stay on track on the same development cycle and automation engineers were only one sprint behind. Furthermore, this split would facilitate more efficient and quicker releases, more trust in overall product quality with fewer random regressions.

Of course, every team is different, and not all QA strategies are made equal. But quality is a collaborative effort. Sharing and splitting demands across specialized QA teams will result in more mutual respect, communication, and confidence among the entire development team — not to mention make meaningful impacts on the business itself.