Professional Scrum Trainer
Licensed by Scrum.org

Certification Path for Testers

Posted: September 13, 2019

Learning Path for Testers

Starting with PSF (Professional Scrum Foundations), 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 (or 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 (or 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.

I expect we will see a change in the balance across those three groups.

 Present Day (Rough Estimate)10 Year (Informed Guess)
Type 155%15%
Type 235%30%
Type 310%55%

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.

Why would a tester take each of the courses illustrated above?

  • PSF: Professional Scrum Foundations. A training course (which is an alternate path to PSM I certification) is a hands-on, product development simulation. People describe it as “a profound experience” and it serves well to help people understand real Scrum.

  • PSD: Professional Scrum Developer. A training course (with a parallel certification) which covers things like:

    • foundational programming concepts;
    • Scrum with Agile engineering and DevOps practices;
    • incremental design (e.g. architectural, visual).

    This brief experience certainly helps bridge an empathy gap (if not also a knowledge gap) between test-minded and code-minded team members.

  • Specification by Example. (Self-study or pursue master classes with Gojko Adžić, or his students.) This material would help a tester to:

    • write automated end-to-end acceptance tests;
    • explore an alternate sense-making approach (alternate to the conventional QA practices) to capture abstractions or novel ideas/concepts by way of boundary stories, examples, and tests;
    • communicate, with ubiquitous language, between business stakeholders, designers, and engineers.
  • PSK: Professional Scrum with Kanban. A training course (with a parallel certification) which covers things like:

    • skills-fluidity across shared services or within self-organizing teams;
    • how to balance demand and capacity in light of knowledge work;
    • how to improve workflow in light of customer-service and operational demands.
  • PSU: Professional Scrum with User Experience. A training course (with a parallel certification) which covers things like:

    • testing and validating user-interfaces in light of frequent delivery;
    • design systems and how they can map to software engineering design patterns;
    • design is a discipline, not a job title, and QA specialists have such discipline!

All About Certification — A Blog Series: Table of Contents

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

David Sabine
David Sabine
Professional Scrum Trainer (PST)