Should QA be part of the development department?

Question

I work for a small company that has had a product development department for quite a while. What we haven't had, however, is a QA/testing group.

We are looking to add a testing group, but are struggling to determine where best to put them in the organizational structure of the company. Specifically, we are going to hire a "lead tester" position. Should they be put in as part of the product development department, or should they be a new department? Should they be somewhere else?

Our company is roughly structured as follows:

• CEO
  • CTO
    • Director Product Development
    • Director Customer Care
      • Developers
    • VP Operations
      • Network engineers
  • Sales/sales engineers
  • President
    • Controller

Answer 1

Yes and no :)

Both developers and QA people should have the same goal (and their performance measured against that): deliver a quality product in time and on budget. You get to define "quality product", but it has to be the same for both groups. Why? Because if it isn't the same, you will get two groups with different agendas and that can quickly deteriorate into a situation that is to the detriment of the product/company.

QA should work (very) closely together with the developers and vice versa, but both should be totally independent of the other in their decision making. They are, after all, responsible for totally different aspects of product development

The way we have set it up is that "Product Development" is a "virtual" department realized by two concrete departments: QA and Development. Both report to the same member of the management team: the CTO. This ensures that there is a single person responsible for the product (our CTO) and that both QA and Development are independent of each other.

Answer 2

It really depends on how serious your firm is about QA. For example will you be doing test driven development?

You mention a "testing group", this would suggest multiple people. If it is in fact a group of several people it should probably be a separate department. What puzzles me however is do you currently have at least one person devoted to QA and testing? If not, do you plan on standing up a whole new group quickly? If so this will be a substantial organizational transformation and may cause extensive friction with your current developers who need to change the way they work as well.

If what you are planning is hiring a single QA person now and perhaps slowly growing the QA function, then it would probably be better to have that person report directly to the director of product development. The toughest part of his job, and most important, will be to transform your organizational culture to integrate QA into all steps of the process rather than something that is done after the fact.

Answer 3

What we haven't had, however, is a QA...

Been there done that - my sincere condolences. Well given above I would say getting tester(s) will be much much better than what you have now, no matter in which department they will land.

Other than that I feel safe recommending separate department for QA.

I participated in two releases that were no-go from QA perspective - once as a tester, another one as developer. In both cases I think having separate QA department was quite helpful.

As far as I can tell when testers are in separate department it becomes harder to hide product quality problems behind fake "team alignment". This helped everyone to clearly understand what we are releasing and why. This in turn helped to manage customer expectations and plan for further development.

Answer 4

In almost all cases, QA should be separate from Development. While the goal between both departments is the same (releasing quality products/solutions), QA needs to feel they have the authorization to correct and make suggestions about products with development, and be on equal footing. If the head of QA reports directly to the head of development, this can lead to QA taking a step back and being at the mercy of development (and consequently sloppier code/products get pushed to production).

Answer 5

Depends on the development methodology you're using : if you're doing agile / lean then Agile Testing could be the way to go and as such would need to be close to developers.

Answer 6

From what you are saying, you have a pretty small company. It makes sense to me to take advantage of that size and ability to communicate while you can, before you become bigger. This implies keeping them with development.

In a larger company when you have decent sized Dev and QA teams, it might make sense to split them up then, and have them maintain their own, separate, team goals etc.

Now, I also would be sure to have the first few QA positions be SDET positions... ie. testers with coding chops. Get your automation up, running and stable from the start.