Specialists and Bottlenecks

A few episodes ago on AB Testing, we talked about the Theory of Constraints and related topics. A lot of us frequently see “QA” or “Test” as a bottleneck, even on Agile teams – where several changes may be waiting for signoff from the designated quality or testing specialist before being deployed or marked as done.

If you listen to the podcast, you know I’m against this level of specialization. I’m all for people who have specialization – but things fall apart if they’re the only one who can do a “thing”. I like to imagine the extreme case of specialization where one person just writes design docs, one person writes code, but only internal functions; because another person writes external APIs, and another person tweaks all of the code for performance, and another person writes test cases, and another person runs them; unless they’re automated, then it’s another person…

At this point some of you are laughing because this sounds ridiculous, but others are thinking, “that’s pretty close to my current team – wtf?”

Today, I made a quick (or at least I planned for it to be quick) run to Home Depot to pick up a part. I knew exactly where the part was (aisle 40 – don’t ask how I knew that), so I jogged back, grabbed the part, and went to the front. I jumped in the self checkout line, scanned the part, shoved my credit card in the slot, and got ready to grab my receipt.

But the price was wrong. Or it was right, technically, but I was charged twice. Luckily, there was a cashier right there, so I explained that I scanned once, but was charged twice.

She stared for a moment, and said, “I can’t fix that. You’ll need to go to customer service.” Apparently, I needed the specialist. Or another specialist at least.

I went down to the customer service desk, where I was behind a customer with a cart full of stuff and a lot of questions. I waited 10 minutes for my meeting with the specialist, but it wasn’t moving very quickly, so I walked out of the main store area to the Returns counter to ask the returns specialist about it (the Returns counter is past the check out area to make (I assume) it easier to return stuff without entering the store.

Eventually, the Returns Specialist was able to help me, but he had a very difficult time. Apparently, he knew how to do returns, but since I wasn’t technically returning anything he thought it seemed like a problem that Customer Service should help with.

I try to be a quick thinker, and since my quick trip to the store was pushing twenty minutes in-store time, I grabbed my receipt and part, jogged back to aisle 40 to grab a duplicate part, returned to the counter with both, and I was able to return the item I didn’t want, and all was well.

On one hand, this is just another story of customer service gone south, but at the core, I see it as a flaw of too much specialization – and I think it’s important that we all recognize when we see these things around us. If your software team is ever blocked by a specialist – whether it’s waiting for a tester, waiting for a decision, or even waiting for a deployment, there’s a lesson to be learned, and a potential improvement to be made.


  1. Hi Alan,

    I like many things you are doing and talking about regarding software testing, me being a CTD tester.

    I agree with you that a specialist might be a bottleneck point – I’m thinking of traditional, ISTQB organized type testers who enjoy specializing themselves into functional, performance, security, usability etc testers.
    Supporting my point, I will bring your book as a back-up, for which I wrote a small review: https://www.linkedin.com/pulse/review-alan-pages-book-word-under-covers-test-automation-ion-buzu/.

    I do consider that what a tester should think is HOW CAN I TEST THIS, knowing that he has coding, performance tools knowledge, hacking skills etc.

    However, I don’t quite agree with the disappearance of the tester role. The reason I don’t agree with it (and I’ve been following quite a lot of episodes of your AB Testing Podcast) is that you need to study testing. Testing is related to so many disciplines and fields: experiments design, statistics, philosophy, sociology, physics, mathematics. If you pass the testing to developers, who don’t study testing (because they need to study programming otherwise they will do a shallow, superficial programming), then they will do a shallow testing. If you are claiming that the tester role does not exist then what results from this is that testing is something not worth studying. If you think this is the case then you are going the James Whittaker path (I consider Whittaker to be charlatan), and have the marketer as a replacement for the tester.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.