On a large (300 screens) software replacement development project, should Q/A report to the development contractor or the user? The developer was awarded the contract based on a scope and change control will consume resources if Q/A identifies missing requirements. However, how is the user to be assured that all existing forms and procedures are converted or replaced? My experience is that Q/A reports to the development contractor. I suspect that Q/A could be more useful reporting to the user.
What is your experience? How have you dealt with this situation?
This may depend on who employs the QA group. If the user company hired the QA group then you report to the user company, and likewise for the development company.
I worked on projects that got quite confusing in this area. One project had a team composed of testers employed by the user company and the development company. Occasionally things got nasty on the team because of differing opinions on what was important. The development company's QA group wanted to report every bug, for tracking purposes, but the customer's QA group wanted to hide some bugs and leave things out, since it would reflect poorly on the product (exact opposite of what you would expect, right? I thought the dev company would cover it's butt from the customer.)
Technically, it shouldn't matter which group "owns" the QA team. Every issue should be reported and then project management can decide which defects need to be resolved for which release based on risk, cost and other variables. Both users and developers should be involved in the test plan walkthrough/signoff.
Perhaps the users could also provide some experienced users to do oracle testing - comparing the old application to the new application to ensure no lost functionality. Not only do they know the old system better than any new testers on the project, but the testing could also serve as an acceptance test, to make sure the customer likes the new application.
Tim Van Tongeren
[This message has been edited by vantontl (edited 04-23-2001).]
This has been an issue just about everywhere I've worked. I firmly believe that one of the (if not THE) biggest keys to an effective QA effort is the autonomy of the QA team. The QA folks shouldn't report to the same person that the development folks report to- leaving this person to referee the "It's a bug"/"No, it's not" arguments between the two. There are cases when it's not practical to have a seperate structure, and they must report to the same person, but this is by no means ideal. In your situation, if the customer is defining requirements with no input from your company- basically telling you "this is what we want", then you verify that their needs are met. Higher-ups in your company are left to decide what happens when you find that the customer isn't getting what they require, but that's outside the scope of your duties.
Report TOTALLY to whoever decides your next pay-rise. If you can't, get a job somewhere less ludicrous.
To any other stakeholder (customers, dependant departments, others) Report the MINIMUM for everybodies sake.