Software Testing Strategy is: What Tools Functional or performance or both Coverage Scope Uncovered Scope Then comes Test Plan, Test Cases and Scenarios and finally the actual testing If possible. create and maintain a 'standard test' system. This test system is used to verify the current production system and familiarize yourself with its functions. When changes are made to upgrade the production system to the next version, use the 'standard test' system to ensure that only the approved changes were implemented and no other functions were changed (accidentally or otherwise) - such as totals, error checking, audit logs, etc. You will probably need to add new test functions/cases to verify the current set of changes. Once the modified production system has been tested, and accepted by the user community, it can then be implemented into the production environment. The current test system should be saved, and then become the basis for the next set of production changes. This has a nice side-affect - the developers don't need to be the 'parents' of the production system - you don't really need to know all the nuts and bolts of the applications. You can use the test system to ensure that only the approved changes were made, and that no accidental changes/errors were introduced - by comparing the test system outputs between the current production system, and the newly updated version. You can also use this 'standard' test system to verify the functionality of the current production system without having to directly access the production system (setup a production system in the test environment). Perhaps the most important element is to separate the production environment (system, data, etc.) from the test/development environment.

Software Testing Strategy is: What Tools Functional or performance or both Coverage Scope Uncovered Scope Then comes Test Plan, Test Cases and Scenarios and finally the actual testing If possible. create and maintain a 'standard test' system. This test system is used to verify the current production system and familiarize yourself with its functions. When changes are made to upgrade the production system to the next version, use the 'standard test' system to ensure that only the approved changes were implemented and no other functions were changed (accidentally or otherwise) - such as totals, error checking, audit logs, etc. You will probably need to add new test functions/cases to verify the current set of changes. Once the modified production system has been tested, and accepted by the user community, it can then be implemented into the production environment. The current test system should be saved, and then become the basis for the next set of production changes. This has a nice side-affect - the developers don't need to be the 'parents' of the production system - you don't really need to know all the nuts and bolts of the applications. You can use the test system to ensure that only the approved changes were made, and that no accidental changes/errors were introduced - by comparing the test system outputs between the current production system, and the newly updated version. You can also use this 'standard' test system to verify the functionality of the current production system without having to directly access the production system (setup a production system in the test environment). Perhaps the most important element is to separate the production environment (system, data, etc.) from the test/development environment.