A Detailed Look at the Idiosyncrasies of Test Tool Training

There are numerous events that might give rise to new training requirements. Some of those events could be:

1. The hiring of a new tester with no experience with the existing test tools.
2. The vendor upgrades the test tools or releases a new tool to replace an existing test tool.
3. The organization purchases a new test tool-end users conducting user's acceptance test need some familiarity with the test tool for logging defects or executing test scripts.
4. Test tools have been heavily customized for a particular organization.

Unrealistic Expectations
Some test managers want to maximize their ROI after spending their training dollars on test tool training. They may have an erroneous expectation that the recently trained testers are accomplished and prolific with the test tool because they had two to three days of training. The fact that a student spends a few days recording and playing back scripts during a lab session does not by itself guarantee that they have sufficient knowledge to record any or all of the project's business processes or requirements.

Test managers should attempt to pair the recently trained students with a mentor or test tool expert in order for the students to gain some automation experience with the project's application. Many times the students only learn a limited percentage of the test tool's capabilities and features during a two- to three-day training class. This means that they will have difficulty in adapting to how the project specifically wants to record its business processes in the absence of a skilled mentor who has several years of experience with the automation test tools. In general, recently trained testers need exposure to a test tool mentor for six months.

The Training Instructor
Who provides training for the project and the students is a question that the test manager needs to consider carefully. Some companies hire independent contractors to provide training for a commercial test tool. The test manager should inquire for references about the instructor, how long the instructor has worked at the company providing the training, and if the instructor holds current certification on the test tool in question.

Also, some companies hire instructors to perform the actual training, then to do mentoring after the training is completed. It might be wise to assess how much "hands-on" experience the instructor has with the test tools, since teaching out of training slides for pre-determined lab exercises is substantially different from developing automated test scripts for actual business processes and requirements. Again, it would be most appropriate to evaluate the instructor's credentials before agreeing to bring the instructor on board. Be sure to get assurances from the training company that they will send a new instructor if the initial instructor is unsuccessful in providing adequate training.

Other places you may find good instructors could be among your own project team members. It is possible that the project has local test tool experts who are capable of training and mentoring other testers with customized training material or the vendor's own generic training material.

Identify Who Gets the Training
The test managers should decide who obtains test tool training. Not everyone in the test team will need to record and automate test scripts, but perhaps everyone in the testing team and the QA team will need to know how to work the test management tool for reporting defects or mapping test cases to requirements. You may also want to train end users.

The test manager should prioritize the training classes based on the available training dollars. Testers who will be "hands-on"-or core automators-should receive the highest priority for training on the recording test tools. Testers who will be "passive" users of the test management tools might receive informal training from the project's local test tool expert.

Train the "Trainers"
It may also be worth the effort to train the trainers. Students are trained for a few days with the expectation that they will train other users after the instructor departs. The recently trained trainers are expected to master the information from the training exercises and the test tool that they have just been trained on. Then they must impart their new test tool knowledge on to other users, especially the test management tools. This technique works best when the trainers educate casual or passive end users who are doing activities such as logging, opening a defect, or reviewing a test case. It often backfires when the newly trained employee is expected to teach complex features of the test tool. After initial training, the test manager should lay out a plan for what the newly trained employees are expected to contribute to other testers or end users.

Document Unresolved Issues
The test manager should ensure that the instructor documents any unresolved issues that arise during the training exercises. For instance, I was in a training session where the vendor stated in its product literature that its test tools were compatible with a particular operating system. However, this was not the case. Much time was wasted trying to install the software on an operating system that did not support the test tool.

The wasted hours should be documented. In another example, the vendor's training exercises could not be completed because the vendor's test tool software had a bug that prevented the execution of a particular step. The bug again wasted contracted training time. Anything that impacts or delays the student's training should be documented. Different events serve as the catalyst for training team members on the use of automated testing tools. What is often overlooked is the approach for training the human resources. Exactly how the testers are trained on an automated test tool is as important as the contents provided in the training materials.