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.

Addie Johnson
3 min readDec 9, 2020
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…

--

--

Addie Johnson

writing about the intersection of design, business, and technology // addiejohnson.com