> ## Content Index
> Fetch the complete content index at: https://www.kenst.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Throw someone else in to help QA it faster!
- URL: https://www.kenst.com/throw-someone-else-in-to-help-qa-it-faster/
- Published: 2012-05-09T20:53:00.000Z
- Updated: 2023-06-28T19:59:45.000Z
- Author: Chris Kenst
- Tags: Folklore, Test Planning, Testing, Greatest Hits, Management

> 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](http://en.wikipedia.org/wiki/Verb?ref=kenst.com)?), 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](http://en.wikipedia.org/wiki/Brooks%27s%5Flaw?ref=kenst.com):

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

Fred Brooks coined the term in his book [The Mythical Man-Month](http://www.amazon.com/The-Mythical-Man-Month-Engineering-Anniversary/dp/0201835959/ref=sr%5F1%5F1?ie=UTF8&qid=1336514152&sr=8-1&ref=kenst.com) 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.