Uncharted Waters

Aug 19 2019   3:35PM GMT

Mind the test bottleneck

Matt Heusser Matt Heusser Profile: Matt Heusser

Software testing

Bottlenecks on the Scrum BoardIt’s been exactly ten years since I published a two-part series on answering unfair questions. The first was general; the second was how to answer the question “why is testing always the bottleneck?” Ten years later, those questions are as relevant as ever. In fact, I’ve got that question coming from multiple directions right now.

The articles have aged well, and are worth a read — yet we’ve learned a thing to two in ten years.

Let’s talk about it.

Bottlenecks at the daily standupThe testing bottleneck?

Most of the teams I work with today are likely to be doing “something like Scrum.” I mean that literally. They will call it scummerfall, or scrum-but, or say “our executives think we are doing Scrum.” They certainly have standups, stories, and sprints, probably story-points too. Yet something is missing.

Here are the two problems I see.

First, the last mile problem.

The team has a kickoff meeting. The developers go develop, and the tester does … stuff. Perhaps they create test plans. Perhaps they explore emergent risk. Somewhere between day 8 and 9.5 of a ten day sprint, all the stories get dumped into test.

That’s not the bottleneck, man. That’s just last in line.

The second problem is staffing.

The staffing bottleneck problem

Yes, it is possible for a group to exist without testers at all. Those groups typically have a large number of things going right. They likely have code that is well-isolated. Their requirements are clear with concrete examples. The programmers are likely test-infected, hone their craft, and pair or mob to share learning. Such a group typically has very high first-time-quality.

Then there is everybody else.

This second group sees the success of the first, argues that test is a bottleneck and say “we don’t need no testers.” After that approach has … limited success … eventually, testing is re-introduced as a role. When it is, the ratio might be four, five, six, or ten to one. Given low first time quality, testing has a choice to be a bottleneck or to skip testing, leading to low quality in production.

Face with both, my choice has historically been to focus on the first problem. After all, doubling the resource during “crunch day” also doubles the waste for the rest of the sprint.

Fixing ItSave Our Scrum

Lean thinking gives us the tools to fix this. We break the work into smaller chunks, limit the amount of work in progress the team has, and change the team from “dumping” work at the end of the sprint to dribbling out a continuous stream.

This isn’t easy, but it is an improvement over ten year ago.

Ten years ago, testers were responding to ridiculous accusations. Today, those of us who are left tend to have a much broader role — and we are solving problems.

Doing “something like Scrum” is incredibly hard.

Yes, I am working on a book on it, available for sale now, called Save Our Scrum: Tricks, Tips and Techniques for Teams in Trouble.

It may be time to get back to it.




 Comment on this Post

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: