Should QA report to development? [closed]

Question

Here's a question I've run across in many, many companies: should QA teams report to the development organization, or be equivalent to development in the company hierarchy?

Answer 1

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.

Answer 2

Quite the opposite. Development should report to QA.

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.

Answer 3

Equivalent. The goals should be the same - release of quality software. Without an open discussion between equals, this cannot happen.

Answer 4

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.

Answer 5

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

Answer 6

I guess it depends a little on what QA actually does. In the very typical scenario where QA's mission is to provide lack of errors (and only indirectly (hopefully) improve quality), then I think that having them equal is the best option. If QA on the other hand really had improving quality as the primary mission, then I think I agree with gbjbaanb that development should report to QA.

Answer 7

Integrate it as part of the development team(s).

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.

Remember that test automation requires developer skills, and usual dev/quality effort distributions are wrong.

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.

Answer 8

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.

Answer 9

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).

Answer 10

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.

Answer 11

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.

Answer 12

They should work as equals so that they politically can't be shut up by development managers who don't want to acknowledge problems. Qa can;t report to dev ever if they are to be effective.

Answer 13

I think QA and development should go hand in hand, because both work for the best product delivery. It is the QA and the developer who are responsible for the best quality of the product that can be delivered by the organisation. Anything hampering QA and developer relation may as well hamper the product development.

Answer 14

QA should report to DEV is wrong and not accepted in any case. Dev can never be held responsible in case of failure at Production Environment. Why would they report to QA, why not the other way around? After all, they hold responsibility of releasing a functional requirement as per the client's requirements. Seeing products through client's perspective is the main job of QA. In case if anything crashed/failed in sanity, they'd be responsible of shipping the incomplete/immature product. Still this is a traditional approach.

After the advent of Agile Methodologies, QA and Dev should work side by side under product development manager or QA and Dev can have separate heads but working for the same agenda which is Delivering a full-fledged product in accordance with client's requirements.

Answer 15

As a QA I would recommend you that must report those issues you faced,May be developer missed something which shouldn't occur.