background to create scripts, develop or revise the code to automate the script, inserting loop statements, insert verification points, add error-handling logic, etc. Merely recording a user action or keystroke against a business process does not by itself create a fully robust automated script or even a valid reusable script for that matter. A functional tester may have some mild success in creating scripts for simple tasks or business processes such as viewing a report or viewing a business process in read-only mode, but this does not necessarily mean that the functional tester can create data driven, correlated, maintainable and fully robust scripts.
I hereby place a special emphasis in separating the roles of the functional expert and the technical expert while these two types of testing roles need not be completely independent they can certainly specialize in different areas. For the functional tester an are of specialization might be drafting test cycles, drafting test scenarios, sequencing of test cases, drafting test sets, providing navigation support and transactional steps within the test script, identifying test data for the test script, ensuring that requirements are tested via RTVMs, etc. For the technical tester (core automator) on the other hand an area of specialization might be to create fully robust, data driven, and maintainable automated test scripts and analyzing the results from the test script execution.
3. Everything under the sun can be automated
A common misconception is to expect that every single requirement, test scenario and test case can be automated. According to industry best practices one does not automate testing cases for all business processes and test scenarios. The following criteria for instance identify business processes and test scenarios that would not be good candidates for automation: business processes/test scenarios that will only be executed once; business processes/test scenarios that require intuitive testing, test scenarios that require negative testing, test scenarios that rely extensively or solely on analog and bitmap testing which could be impractical since recoding a test script based on pixels and screen coordinates may be unpredictable, and recording of test scripts on an unstable or frequently changing environment. Under these aforementioned conditions the test manager should employ manual testing techniques.
4. The automated tool is the means to document the test design, and test script
This is a misconception that I have seen at some projects in which test leads incorrectly believe that recorded automated scripts serve as the basis for a documented test script. There is no substitute for a well-documented test script that is written in coherent English. The test script should include at the very minimum a description of the steps to be captured with the automation tool, the expected results of the step, the data values that need to be populated within the application under test to record the test script, the output that needs to be captured, any pre-work needed to record the test script, and a description of the warning and information messages that the system may display during the recording of the testing script.
A technical tester (core test script automator) should have the ability to work with a self-explanatory, thoroughly documented test script before proceeding to automate it. An approach that requires a technical tester to divine what the testing steps ought to be from a poorly recorded script is not a suitable approach for script automation and is counterproductive as well as inefficient. To augment this argument in the absence of a well written test script the technical tester would not know if the steps that he/she is recording are malfunctioning because the application under test has a