12 Answers
12

Seriously, this question has been around forever. At least as long as there has been QA & Developers.

Personally – I don’t think the org. chart matters as long as you have a good, ethical & honest manager.
The argument that an “R&D Manager” could pressure QA folks to do/report certain things is true. You can also have a QA manager who likes flexing their muscles & proving a point. You can also have 2 separate departments & if you have a poor manager you can still have problems or people being pressured to “tweak” things. Any way you cut it you could end up w/infighting & political BS – which leads to a poor release.

However if you have a manager who understands & values both pieces of the process and is truly focused on the best possible release it doesn’t matter what the org. chart looks like. QA could report to the front desk or janitorial staff and if they are able to honestly report their results & the information is given appropriate weight & consideration, then everything is okay.

If you imagine the QA department to be your customer (note: QA, not test) then you will do very well. Bugs will get fixed, products will get developed to good standards, development will realise they are there to serve the business and code products accordingly.

However, company politics gives seniority in other ways, so generally development does become more senior to the smaller QA department, if you have a QA department at all.

EDIT:
a little addendum to explain myself: at one company I worked at, we had a 'model office' that was set up as a customer site. We'd build the installer CD and deliver it to the QA team, who would install it onto a cleanly-restored set of machines. If there was problems with it in any way, it's be reported back to us and we'd have to fix it (obviously, depending on bug severity) before building another CD and repeating the process. At first I thought "this is gonna be hell", and it was.. but only for a couple of iterations, then dev got the message and made sure those CDs worked, and the software it installed worked.

My current company needs something like that, feedback from site is through a mailing list, installer often doesn't fully work, sometimes there's missing dependencies, and the same install issues crop up again and again. Quality here is poor in comparison to the QA dept that made sure it worked so well before. Here we have a dev-driven group, they're always focussed on the next release, new features. QA is always concerned about the current release, the existing product. It makes a huge difference to what the end-user gets.

So, even if the QA dept is there to ensure quality is acceptable, I still think it should be treated as if it is the customer that development 'reports' to.

that just delays the problem, you need qa to work together with the team during the development of the release, not after.
–
eglasiusApr 23 '09 at 18:07

don't think that didn't happen, but after any debugging and fixing that occurred, the process was repeated from scratch. I've seen too many times the "it just needs this patch adding' doesn't work when you're onsite fixing a broken system that the customer never got that patch. Better to do it right than try to work around it to "save time"
–
gbjbaanbApr 23 '09 at 18:17

1

I agree with your last comment, but that still doesn't address that you don't need to wait to the end of each iteration (hopefully 2-6 weeks) for that to happen. In that scenario, consider what happens if someone on the dev teams knows well how to work with that scenario i.e. combining vms during the automation for example, if the team is working closely there is a better chance you will use those skills to help in the situation. It works the other way around too, qa can contribute with the dev team.
–
eglasiusApr 25 '09 at 17:37

also, needing qa department to be your customer to: "bugs will get fixed, products will get developed to good standards, development will realise they are there to serve the business ...", means you have problems with your managers/leads: development manager/leads, project managers, product managers.
–
eglasiusApr 25 '09 at 17:40

I usually don't report to customers. The QA department can be one of my customers, that works fine, but I don't have to report to them.
–
David ThornleyJun 2 '09 at 20:00

I think it depends on who is responsible for delivering software of appropriate quality. If it is the development group, then QA should be a part of that, where development decides the resources needed for QA vs. resources needed for development.

If, on the other hand, it is the technology department in general, then they may be equals, with both reporting to a Director or the CIO or CTO, where the resource allocation decision is made by balancing the needs of both groups to reach the greater goal.

If the QA department drives the development goals, then Development reporting to QA might make sense, although it would certainly be unusual.

If QA is a specific practice within the organization, and not just part of the development process, then it probably shouldn't be reported to the Development group, but in many cases around internal app development, QA just isn't given the importance.

effectively development should be responsible for delivering appropriate quality, specially with common qa vs. dev effort distribution. I wouldn't say that means development decides the resources needed for QA vs. for development, but its more a matter of the hats the members of the teams will have during the development of the projects. When working with the development team, there are many different ways qa can achieve its goals.
–
eglasiusApr 23 '09 at 18:17

In a company I worked about a year ago, and which to my mind had the best dev practices I ever seen, QA and development worked side by side. Both worked as equals, but QA had responsibility of releasing and supporting the released code, e.g.: if a problem is discovered with the code in the field, and a couple of first levels of support cannot fix it, it will first arrive to QA for fixing, and only after that it goes to dev

Have developers create automated smoke tests for anything they work on, and have qa augment/collaborate on those. Its not that qa reports to development or the other way around, but employees doing the qa roles are in the same boat as the ones doing development.

If you are going for separate hierarchies, you still need them to collaborate closely. Each role contributes to project success from its own view. Adding a hierarchy across teams will give priority to one or the other, affecting its contribution to project success.

I think this answer gets Test team and Quality teams confused. (many do, as they both perform a test role) Quality is more about end-user, or "final, complete product" testing, not unit, system or even regression tests.
–
gbjbaanbApr 25 '09 at 13:59

@gbjaanb you are correct in the sense that I clearly focused on quality control / testing (as most answers did). That said, based on your answer, I think you have your particular view on what QA (quality assurance) means, if we focused on QA we shouldn't be talking about tests. QA is about the process, not about validating the products (which is in quality control / testing area), see en.wikipedia.org/wiki/Software_quality_assurance.
–
eglasiusApr 25 '09 at 17:11

1

The way QA is involved in projects is through audits to help the different team members perform their activities (based on the process) better. QA needs to interact with people in different roles, which already can be in different departments. QA is not management for all the departments involved in software development, so all of those shouldn't be reporting to QA. QA shouldn't be reporting to development neither, as it needs to deal with many factors that go beyond the ones managed by the development team.
–
eglasiusApr 25 '09 at 17:25

I'm from a small shop where the final product's quality is critical. I've also dealt with shops where a dominant personality(ies) (i.e a demagogue) caused people to ignore the true reality of a product until a customer (embarrassingly) brought the true reality into perspective.

As the gatekeeper of the final product, the QA department needs both autonomy and authority to declare something incomplete or unacceptable. QA must 'keep things real'.

In addition to the domain over product quality, the QA department should also possess (and use) authority to change/evolve development processes that affect quality. (i.e. prevent future problems, improve things)

Distance and perspective are something QA needs to perform properly. The QA department should not be involved in the actual code writing activities of actually developing the code to be tested. Perhaps some testing automation, but NOT the actual code to be tested. Neither should QA be involved in day to day operations of Development.

Interesting comment - how small is the shop you work in ? I have an engineering team of 7 people in total, and find it very hard to have a deicated QA person who is not also tasked with other things like documentation, build or support (although I have managed to avoid having QA people do development at least).
–
gareth_bowlesJul 16 '09 at 16:48

We have a handful (under 10) development department. Roughly a third of that size comprises the department responsible for QA, Support, Installation, and IT. (And yes, these are probably too many duties for such a small department...but we manage.) Development is responsible for their own build support..et al. Product documentation is the realm of a technology team (i.e. some poor engineer who gets the assignment). How about your situation..?
–
CMBJul 16 '09 at 19:15

Hey.
Focus of your question is a little bit mixed. Is it about company structure, and departments organization? Or about project organization?

If you meant to ask about the issues, bug reports and project organization, than qa reports to a role responsible for deciding what should be done with issues in given project. it can be developer, analyst, business owner, client representative. Someone who can make a decision what to do with given issue and make others comply.

If you meant to ask about vacations, overtime and company organization, than qa reports to their line manager. Depending on the size of organization it can be one manager for qa and developers or their own manager, as there is so many testers and developers in organizations that they have separate departments.

In both cases developer-tester position in company hierarchy is not relevant (which I believe should be equivalent).

Your question seems to be ambiguous; I’ll reply to the sense which the rest of the answers don’t address: Should individuals doing testing report to non-QA managers? That does have an answer, and the answer is: “The QA department should be independent and powerful, it must not report to the development team, in fact, the head of QA should have veto power over releasing any software that doesn't meet muster.” “Top Five (Wrong) Reasons You Don't Have Testers” by Joel Spolsky (http://www.joelonsoftware.com/articles/fog0000000067.html)

Having testers report to engineering rather than a single head of QA seems to be something that companies want to try every other re-org. It’s generally a sign that upper management wants to ship something on time rather than when it meets the criteria they supposedly support. It’s always a good way to avoid accountability for quality problems, even if that wasn’t the supposed intent.

A strong, accountable head of QA is crucial even for bugs he never hears about: If I’m deciding whether to file, or dispute, a bug which I consider important, if I know that I the head of QA will back me up if it’s genuinely important, then I’ll probably do what’s right, even if engineering doesn’t want to fix the issue. If I know that the ultimate decision will be made by an engineering manager whose bonus is determined by meeting a schedule, and unaffected by quality, then I’ll be tempted to duck a pointless battle.

I see QA as an integral part of the development department, however QA as a group should be half a step higher on the ladder in terms of power. If the QA department must pass or certify code to work, they are by nature higher up, as they can tell development to go back and do it again.

There will be a conflict between developer time and release date. Sometimes, imperfect code has to be released, or the developer doesn't feel like a bug should be fixed right now. I'd say ideally the QA lead and lead developer both report to the same person, and these two individuals are seen as equals.