Segregation of duties: System design and system QA 242



  • Is there a SOX-based argument for preventing someone involved with the design of a system from being involved in the QA of a system?
    A QA guru informs me that system designers are ‘contaminated’ (they are too familiar with what the system is supposed to do and how the system is supposed to behave) and SHOULD NOT be part of the QA process.
    Does something stated or implied in the Sarbanes-Oxley Act support this ‘common sense’?



  • This post is deleted!


  • This post is deleted!


  • This post is deleted!


  • This post is deleted!


  • This post is deleted!


  • This post is deleted!


  • This post is deleted!


  • ISCA.org code of conduct suggests that you cannot audit a system if you are involved in the design of it. Its purely an independence issue. However, for SOX there is nothing to prevent this, however most of the big 4 firms will not rely on testing work performed by the process owner.
    hope this helps.
    tristanatbui.com



  • It depends what you mean by ‘involved in’ and it also depends what you mean by QA and designers.
    Ultimately those responible for the acceptance of business systems should be the business.



  • My job is to write the business requirements (functional specification) for the system. I will review and approve the technical specification but will not be involved in the implementation.
    I am supposed to lead the QA testing (the company is calling it ‘user acceptance testing’, there is no QA group to do the testing). I do not have a QA testing background (nor am I eager to learn). Leaving all the testing to one inexperienced tester (me, unenthusiastic about these duties) for a system that will have 300 end users doesn’t make any sense.
    What I need to build a case against this scenario is a SOX-based argument against the functional specification writer doing the testing. Also, I welcome any other ideas as to how make a business case against me doing QA for this system. What I’m trying to do (or not do) goes against standard practices here (and I am just contract employee).



  • Sarah,
    My suggestions are as follows:

    1. Your arguement should be based on the fact that User acceptance testing is NOT QA testing. One of the fundamental requirements of a good SDLC is for the USERS to test the end product not the functional writer. The only thing you can attest for is to ensure that it functions correctly NOT to ensure that the software MEETS the USER’s needs ( User accpetance testing)
    2. Your second arguement is that Users should be trained on how to use the application anywayz (part of good SDLC) therefore you should suggest that they perform the testing to validate that the procedures are working properly (SOX requirement)
    3. Compromise and tell ur boss that you would perform the critical functions within the system to ensure it functions properly however the users should perform all the bulk of the work.
    4. JUST DO IT U GET PAID BY THE HOUR SO WHY SHOULD U CARE?
      HEHEHEH…good luck and post how u went as i would be really interested
      tristanatbui.com


  • To add to Yoda’s comments.
    Users should have a key role in systems design i.e. the system is being built to meet their needs not to keep developers in a job. Users must also be heavily invoved in testing and acceptance. This is not only good practice but these principles are covered in Cobit.
    However, a key piece of segregation of duties is that Developers should not be involved in UAT. Developers should still test their own code before it goes across to the test environment, but it is for the Users/Business to carry out the final testing and acceptance.
    I take from your description that you are writing the functional spec for the business rather than as part of the development team. In this case I see no reason for barring you from the testing.


Log in to reply