Testing Policy

As a general rule, we test the issue that lead to the CTP. Test the process not just the form. So if it is part of the Req process, I would test req to check. Also since this is materials related, keep in mind back office ctp's could effect MSCM.

I've said it before and i'll say it again...Test everything, everytime. It sounds daunting, but you should be able to create a very robust set of tests that can be completed by 1 or 2 people in 1 or 2 days. If you always test everything, you don't miss anything. You also can easily plan test time and you don't have to do a full analysis of what may or may not have changed. And after reading a few of those CTP docs or the compile report and knowing that Lawson documentation lacks completeness, it is just so much easier to test everything.

 I agree.  Although a CTP may fix your original problem, it can cause others that aren't found days, weeks, and sometimes months later depending on how much of Lawson you use.  If there are programs you know you don't use that were affected by the CTP, you can probably get away with not testing.  However, other programs might rely on them, so there definitely is a risk.  I would recommend testing everything if possible.

We have developed a list of testing scripts in our testing tool that we have in-house that we are required to test and attach documentation whenever a CTP is put in.

This defnitely includes the entire req to check process as well as month end closing process for all subsystems and finally GL.

we then include a customized script to test the specific perice that is broken. After we complete testing we are required to get an official sign off from business owners that they are comfortable with the CTP.

This allows the patch to be implemented in production. This keeps all users in sync with the whole testing and sign off processes.

In face the scrpts are reviewd with all the business owners for each area and if they like to add any additional scenarios additional scripts are created.