expertise as to how the ERP application was configured and what data sets are appropriate to define test cases and test sets to test the ERP application, however these functional testers have little knowledge if any as to how to properly develop an automated test script that successfully plays back with an automated testing tool.
The test manager should identify which testers within his/her team have the ability to develop automated test scripts and identify a tool champion for script automation within his/her team. In the event that the test manager does not have the in-house expertise to assign an automated test tool champion he/she should seek to hire an automation expert or contractor to impart tool knowledge to the other core test automators. The reader should note that the technical tester might rely heavily for support on the functional tester for functional expertise and subject matter expertise associated with the application under test.
Automated tool training
The test manager will in all likelihood get some days of training for the testing tools from the vendor after the purchase of the automated tools. The test manager should decide which testers within his/her team would be the core test automators and should therefore provide training for the testing tools to the core automators and users in general of the automated testing tool such as the test management tool, and the defect reporting test tool.
Some test managers after choosing test automators to receive training for a test tool, sent the testers training with the concept of "train-the-trainers". The purpose of this concept is to have the "trained-trainers" share their knowledge with other testers within the project that may work with the automated test tools in the future. I have seen this concept worked with mixed results since at the beginning the newly trained core automators and testers do not have sufficient knowledge or know-how of the automated tools to teach other testers right away, and these core automators and testers only gain enough knowledge of the automated test tool after having worked with the automated tool extensively for a period of at least 1 year.
The test manager should also be cautious that often times the vendor of the automated test tool only has generic training with generic training materials on a generic environment which might be considerably different from the test environment in which the automated tools will actually be used against for the project needs. In such a scenario the test manager may request customized training from the vendor for the project specific applications and testing needs.
In any event the test manager should ascertain that the recently trained core automators have a tool champion with them for at least one release of the software in case they encounter difficulties automating test cases and test scenarios.
What to automate
In this document under the section of misconceptions I provide some scenarios under which test cases should not be automated. In general one should automate processes: 1. That will be repeated, 2. That require testing with multiple values of data, 3. That are stable and constant, 4. That require verification of multiple business rules, 5. That are resource intensive, 5. Critical to the application, 6. That will be part of regression testing, and 7. That require integration testing. This is not an all-inclusive list of all the general rules for automating a test script but a set of criteria guidelines for reviewing which test cases are good candidates for automation. The reader should note that in order to automate a test script, a stable or non-changing environment is needed to