For user testing: 1.For testing there needs to be a testng policy or guide line re: how to decide on the severity of an error based on the impact on business, which type of error is acceptable, at what posint you can go ahead with the change, test sign off requirements, etc. 2.Test scenarios, test cases / scripts: a)Understand the changes' business requirements. b)Understand what is the change in the use of the system. Is it a new report, or how a transaction is done, or a new field, or how a field is derived, etc. c)List possible business scenarios affected by the change. This will equate to a Test scenario. d)For each scenario, you may have one or more test cases. e)Develop the test case details. Input conditions, actual inputs, output expected, etc. Document all the above. f)Create test scripts. 3.Run the testing. Check the results and document the results. If results are incorrect, decide on the severity of error. feedback to the developer of the changes. When the problem is corrected, re-test whatever part of the tests are necessary. If you are using automatic testing tools, you can save the test scripts and results in this tool. You can use it to re-test in case of correction and re-test. Once all testing and test result review are completed, the change can be signed off. The developer will move the changes to production environment. The Business client area may need to notify affected areas or employees of the change. With large scale changes or a new implementation, both the developers and business will monitor the production, to ensure correct processing. Hope this helps. Regards, JG

For user testing: 1.For testing there needs to be a testng policy or guide line re: how to decide on the severity of an error based on the impact on business, which type of error is acceptable, at what posint you can go ahead with the change, test sign off requirements, etc. 2.Test scenarios, test cases / scripts: a)Understand the changes' business requirements. b)Understand what is the change in the use of the system. Is it a new report, or how a transaction is done, or a new field, or how a field is derived, etc. c)List possible business scenarios affected by the change. This will equate to a Test scenario. d)For each scenario, you may have one or more test cases. e)Develop the test case details. Input conditions, actual inputs, output expected, etc. Document all the above. f)Create test scripts. 3.Run the testing. Check the results and document the results. If results are incorrect, decide on the severity of error. feedback to the developer of the changes. When the problem is corrected, re-test whatever part of the tests are necessary. If you are using automatic testing tools, you can save the test scripts and results in this tool. You can use it to re-test in case of correction and re-test. Once all testing and test result review are completed, the change can be signed off. The developer will move the changes to production environment. The Business client area may need to notify affected areas or employees of the change. With large scale changes or a new implementation, both the developers and business will monitor the production, to ensure correct processing. Hope this helps. Regards, JG