Quality Assurance 1579

  • Under Sarbane -Oxley, is it a conflict of interest for QA dept to be reporting to the head of development.
    At my job we recently had a reorg and the head of our development area was put in control of QA. Just doesn’t seem right.
    Any qcomments would be appreciated.

  • As an IT auditor with Pharma we used to routinely audit vendors and specifically looked at the org chart to see there is a clear delineation between QA and Dev. If there wasn’t it was a red flag and would get written up in the audit report. The most common response would be that proper policies and procedures around the QA lifecycle are in place. We would also further audit their CM process and verify the Requirements Tracebaility Matrix, essentially ensure that testing is not compromised and code is not released without going through a testing cycle.
    Although its not the ideal situation if proper policies and procedures are in place and followed we would let it slide although our final recommendation would be to separate the depts. At the end of the day its all about what is the risk and how can it be mitigated. A Dev. manager is more likely to be prejudiced and will want to narrow the scope of testing thus affecting what should and should not be tested . But then again testers routinely seek the advice of the dev. team to define the scope and trust their judgment…

  • Agree with the previous comment. Although it may not be the text book answer to report this way it may not be a problem if the appropriate policies and controls are in place. Ultimately, this sort of thing is a judgement called based on a number of factors, including the size of the organisation, level and complexity of development, other controls in place, etc.
    SOx certainly does not stop you from reporting this way.

  • Hi and welcome 🙂
    As Denis and Val share, there’s nothing under SOX governing this, although recommendations could be made by auditors examining controls and guidelines outside of SOX. It’s certainly better to have these areas as 2 separate entities, so you have clearer lines of demarcation and improved functional separation of duties.
    In my 30 years of IT experience, I’ve seen numerous organizational structures. This includes placing QA under the control of IT as you’ve described, which worked out okay for us. For example, they would often bridge the gap well between the users and IT development and helped us effectively on projects. With users usually driving quality as well, I’m not certain that the QA area could also be forced into compromising testing or system quality?
    A lot will depend on the leader, whether they value QA input and if they will use the resource effectively. Personally, I like the separation of areas. Just wanted to add a few comments that it seemed to work out okay for us in the long run.

  • Thank you all for your reponses.

Log in to reply