Throw someone else in to help QA it faster!

Throw someone else in to help QA it faster!
Photo by Thiago Cerqueira / Unsplash
Throw someone else in to help QA it faster!
A former boss (or two) of mine

I’ve heard this statement many times in my career but it happened again just recently and it got me thinking. Aside from the poor choice of words, about “QAing” something (is that really a verb?), why would someone say this?

The most recent occurrence came when management didn’t communicate the expected release date and freaked at the estimated test duration. My response was "you can have the product whenever you want but let me tell you what won’t be tested". This elicited the response “no we don’t want to not test it, how about we… throw someone else in to help QA it faster?”

Clearly someone hasn’t heard of Brook’s law:

Adding manpower to a late software project makes it later.
Fred Brooks

Fred Brooks coined the term in his book The Mythical Man-Month which states “adding manpower to a late software project makes it later”.

When you bring in someone new who doesn’t understand how the application or project works, the value both will be providing is diminished. You slow down the primary tester as they coordinate with the person being brought in as work is divided up based on skill and comfort level. Configurations of different machines, problems local to the users and a whole host of other problems can crop up as well. It takes time for people to become productive on a project.

Anyone who does time-based work (has a deliverable) can tell you it’s helpful to know when you need to be done. Crazy, right? Testing a product is a never ending journey but specific periods of testing can end, for example when the product is needed in the field. There will always be more testing to do but you don’t always have time nor is it always a good use of resources. Dates can help. If this statement comes up often either Management or the Team has problems communicating with each other about when things need to be done. Setting dates isn’t a sure fire method since dates can change but so can the decision on what needs to still be tested and what’s acceptable risk for the field.

While it’s possible to get an additional person to add some incremental value into a project (they might have some unique perspectives that can help, especially if they are subject matter experts) it’s going to take them awhile. Don’t assume “throwing someone else in” will do anything other than make the testing duration longer.

Subscribe to Chris Kenst

Sign up now to get access to the library of members-only issues.
Jamie Larson
Subscribe