Certification Path for Testers

Starting with APS (Applying Professional Scrum), a crash-course in iterative & incremental product development with self-organizing teams, a tester could then explore Agile engineering practices (PSD, Spec by Example), then new ways to blend Lean UX with development (PSU), and add a dose of Kanban to aid decisions regarding workflow and Sprint Backlog management (PSK).

Three Types of Testers (By Accident)

In my work, I encounter many testers (i.e. QA) and I’ve noticed each of them has arrived at their current position from one of three histories. Quite by accident or circumstance, three main categories have emerged:

1. The majority of QA personnel I encounter, despite not being programmers (and not expected to be), are features of IT organizations. These non-programmer, IT testers generally report to a Quality Assurance manager of their IT organization: they write and conduct manual tests (mostly functional, some exploratory, and so on); and they help maintain requirements documentation of 'done' product.

2. A second type (a sizeable group) are features of “business” units. They are not programmers (and not expected to be). They write and conduct manual tests (mostly functional and end-to-end user acceptance tests) to check whether the software properly abides the business rules and processes. These folks often have a double life as Business Analysts.

3. A third type (a much smaller group) are proficient programmers. They are capable of most engineering tasks; they write and conduct automated tests; many also write production code (e.g. Test-First Development). Some of these folks have come from a QA department but most have not; rather, they are usually called “developers” or “engineers”.

The Bad News for Type 1 and 2

Demand for non-programmer, IT testers (type 1) is not growing — just the opposite. Automated testing tools and skills have become less costly. And I don’t mean that costs have come down (e.g. “less costly than past”); I mean to say, the cost of manual testing and the risks associated with it have proven to be far more expensive than the less costly tooling and skills-development toward automated testing.

I sympathize if type 1 testers have concerns about job security. I’m not going to beat around the bush here; every test that could be run by a robot, should be! And that is certainly the trend we’re seeing in the industry — companies everywhere are making huge investments in automated testing tools and skills. I encourage type 1 QA specialists to develop new skills or risk becoming defunct.

Demand for type 2, non-programmer, business-minded tester, will remain high for a while yet (a decade or two I’d guess). But keep in mind, the reason type 2 exists is largely due to the fact many enterprises grew up in a pre-digital era. Those same enterprises are currently digitizing every paper-based business process and type 2 QA personnel are the transmitters of information. Eventually, all that information will have been transmitted, every old process will have been replaced by a digital-first process. Extinction for type 2 QA is a certainty, but their saving grace (temporarily) is that type 1 has to go first.

The biggest shift I’d like to see is the growth of engineering skills among type 1 — through the next decade (perhaps sooner) they may transition into type 3. I believe this learning path will help us all get there.

The learning path illustrated above would be valuable for all three groups — but for different reasons.

1. A non-programmer, IT Quality Assurance specialist (type 1) may learn to bridge a skills gap between their current practices and Agile engineering practices. For example: every QA specialist in an IT department would benefit from knowing Gherkin language — even if they never write a line of automated test code, Gherkin syntax would increase the value of their requirements documentation. As well, with exposure to pair-programming in the PSD course or exposure to user-centred design in the PSU course, some QA specialists may set upon new paths toward automated testing or business analysis.

2. A non-programmer, business-minded tester (type 2) may develop empathy for the plight of designers and programmers. I look forward to seeing real cohesion and less duplication of effort between designers, coders, and QA personnel. I believe that will be achieved as those three disciplines blend their practices and cultures better. When they have better intuitive understanding of each others’ needs and hang-ups, I’m certain they will discover opportunities for integration.

3. A programmer/QA (type 3) may further hone their automated testing chops but, more importantly, would learn how to work with designers, other QA, and other programmers to simplify the workflow and the code.

Certifications for Testers Explained

Core Scrum.org Courses

Core courses I recommend for Testers are illustrated above along the main horizontal path (left to right).

Related Scrum.org Courses

Related courses are illustrated below the main horizontal path.

Related Courses (Beyond Scrum.org)

Recommended courses through other organizations (not Scrum.org) are illustrated above the main horizontal path.

All About Certification — A Blog Series: Table of Contents

This article is one part in a series I started in 2019 to address questions that I frequently receive about training courses and certifications.