Here is the URL to the IBM site on Compliance ... SOX, CMMI etc with IBM Rational Tools. I'll be updating our company corp web site to showcase some of the ESS solutions build around these i.e. Quality Solutions for Compliance. Stay tune .....

Here is another common question ....
"We have more than thousands of test cases for a system, but how to run them all in the shortest time and gaurantee the quality ? "

The answer seems direct i.e. automate them. However, before you start automation, have you wonder are all the thousands plus test cases good and effective test cases ? In fact the rule of thumb in test design is : it is not the quantity of test cases that matter, is the quality.

Who will deliver quality test cases ? Only trained tester will. So before you jump into test automation to shorten your test cycle ....look at the root problem. Make sure you have "qualified" tester to developed "quality" test cases. Automation is not must, but an option if you have stable and quality test cases.
Do not be fool by myth that more test cases mean more test coberage, mean good quality.

I got a question from the ground after delivering my RUP Testing seminar at IBM City Centre last Thurs.

Q. We have all the necessary tools on shelf but no one seems to be interested to use them.
How to make sure the code is tested with bugs found and trace to the code, and fix get them even before reahing the QA.

This is an ideal case, and in fact there case code coverage tools that can help to do the works, but then why bugs still there for test to find out ? To answer this question, it all boils down to effective use of testing tool and testing process.

The tools are useless if user does not know how to use then effectively. Also tools are useless if they are being used at the wrong time i.e. too late or too early.

There is no such thing as bug free code. Quality is linked with Risk, Risk is linked with resource and time i.e. when is the best time to test ?

Here is a snap-shot of an article on when to use the code coverage to uncover coding bugs at the appropraite time ...

"Static code analysis, the act of analyzing source or object code without executing the program, is a good way to find errors and vulnerabilities before testing begins. But what's the best time in your SDLC to employ a static tool?
According to systems design engineer Ian Gordon, good times to perform a static analysis would be during your everyday work immediately prior to check-in. "[Developers] could analyze software they are developing and make changes to code" based on input from the tool, he said. After corrections are made, "they can rerun the analysis before they check their code in. That results in the lowest possible cost of correction."
Another good place to perform this type of analysis is as part of the nightly build process. "The benefit is that you're able to be really sure that your people are using the tools they are given, and you know how good your code is."

In summary ..... start testing early, enforce policy / process with build-in automation tool as much as possible.