installed thin client software version had the same functionality as the fat client version of the software, the end users now had to adjust to working with the software's Web based browser interface as opposed to the GUI client interface from the older version of the software. Since the end users had to adapt to a new interface I had to create customized training materials for the end users to learn how to work with the new interface of the test management tool.
The training materials included information as to how the previous tool's features would be displayed and accessed in the new interface of the software, and how to remove the older software from the client machine, and any other unnecessary connections to the database that the older software had since the new software was completely Web based.
One also might have to assess the impact on upgrading a test tool given its customizations. For instance, when upgrading a test management tool's repository from one software version to the other, it is conceivable that the test management tool's project specific customizations are not carried over to the new version of the test tool. Under this scenario, the test tool administrator would have to re-establish the customizations to the new version of the test tool.
Some test tool vendors release new versions of a test tool that are substantially different from the previous versions of the test tool. I have also seen test tool vendors that completely phase out a test tool and replace it with a completely revamped test tool with a programming language, interface, and features that are different from the ones offered in the previous test tool.
Under these scenarios the test manager might have to retrain the testers to help them adapt to the new test tool, or hire new contractors to help the project transition off to the new test tool. At any rate, a new version of a test tool that differs substantially from the previous version of the test tool could impose on the test manager the need to allocate new training dollars for the test team. A scenario that impels a test manager to come up with new training dollars might not be viable for every organization.
Any upgrades, customizations, and possibly maintenance on the test tools will necessitate the need to bring down the test tool. Key questions to ask are how long will the application be down? Who will be impacted as a result of the test tool application being down and inaccessible?
The test manager should build a contingency plan in the event that the software cannot be upgraded successfully within the specified down time. If the test management tool cannot be upgraded successfully, the tester might have to construct test cases in a word processor or log defects in a spreadsheet, or the testers might have to test a business process manually as opposed to doing so with an automated test script.
The test manager should coordinate with the tool vendor's support desk when bringing down an application for an upgrade or installation. They should also enlist the vendor's help if the project's resources are unsuccessful in upgrading the test tool within the down time window.
Customization and Changes
Test tools are customized to meet a project's business specific testing needs. A project might need to customize a test management tool to include new fields, modify the defect workflow functionality, or to link it to an email server. Customizing a test tool will require that the newly made customizations have not adversely affected the tool's other