Mattew Heusser prepared an article with some suggestions on how to answer the impossible to answer questions in testing. As a sketch let me try to answer another impossible to answer question in testing using the same approach:
Why is QA always the bottleneck?
The underlying premise here is, that QA is the bottleneck. Now, let’s try to deal with this.
Embrace the premise
Simply answering the question here could do the job. “QA is the bottleneck since we’re understaffed and not getting the right informations timely. By improving communication channels and compensating for missing testing staff from the whole team, we could relax this problem.”
Of course, this just holds if the situations fits to your context. Mostly I think the following would be the case:
Challenge the premise
According to the Theory of Constraints it could be the case that QA is not the bottleneck, but a victim of statistical fluctuation and dependent events. If you want to know more, I would point you out to The Goal from Goldratt, a business novel where this fact is described pretty good.
So, a possible answer in this case would be something like this: “Ok, you seem to think that QA is the bottleneck on the project. According to our gathered data we see that 40 percent of the requirements changed in the last month, nearly 80 percent of the whole system design and the source code changed in this timeframe under high pressure – maybe while even forgetting to care about internal code quality. I don’t see QA being the bottleneck on the project, but more a victim of dependent events here.”
Reply with a question
“What have you done to support your testers lately? Have you pair tested on the story you just finished? The feature you wrote yesterday, did you get in discussion with the assigned tester? Did you talk to the test manager about this and provide support from the development team on this?” Ok, I exaggerate a bit, but just a tiny bit (and I would be a bit afraid to ask these questions, too).
Reframe the discussion
“Ah, ok, Michael. You seem to notice that testing is the bottleneck activity. What is your opinion we can do on this in order to improve?” While reading the article I was pretty much reminded on the stuff on project retrospectives I learned. Involve Everyone.
Change the subject
Now, these are my answers to an impossible to answer question in software testing. Which one is your preferred one?