Audits are easy to pass. You have a documented process. You have a pile of documentation that shows that you followed the process. An auditor independently validates the documentation. Much like running your suite of tests on a CI server.
In an average IT shop you may even have audits of your software process. Recently I used our CI server to help streamline the audit process. We actually had a formal document for unit test plans and unit test results. I value the idea behind the documents, but I don’t know that filling out the Word template was going to accomplish much beyond passing an audit finding.
Upon a request I simply sent a URL over to the PM on the project. It just pointed to that particular project’s JUnit test case reports. That URL should be constant through the life of the project. Now you have documented real time evidence that unit tests are being written and executed. Your CI server can make life easier for auditors.
Having just been through a few CFR 21 Part 11 (FDA regulations) Audit for my software development lifecycle I can tell you that those pieces of signed paper are very important and you’ll get no credit for all your good work without them.
With regard to JUnit for audit purposes, you also need to have a formal SOP for Unit Test Validation which adds additional overhead on the testing side. “Testing the tests”…
Whenever the auditors start to tell me that my “SOP for writing SOPs” needs to be improved I want to change jobs and write silly little iPhone apps instead.
Admittedly I’m only dealing with internal audits based on our CMMI SDLC. I’ve been lucky enough not to have to deal with SOX and other painful audit standards.
Maybe adding e-signature options to future CI servers will help out some.