The following is a description of two methods that have proven effective in implementing an Automated Testing Solution:

 

"Functional Decomposition" Method:
The main concept behind the "Functional Decomposition" script development methodology is to reduce all test cases to their most fundamental tasks, and write User-Defined Functions, Business Function Scripts, and "Sub-routine" or "Utility" Scripts which perform these tasks independently of one another. In general, these fundamental areas include:

Navigation (e.g. "Access Payment Screen from Main Menu")
Specific Business Function (e.g. "Post a Payment")
Data Verification (e.g. "Verify Payment Updates Current Balance")
Return (e.g. "Return to Main Menu")

In order to accomplish this, it is necessary to separate Data from Function. This allows an automated test script to be written for a Business Function, using data-files to provide the both the input and the expected-results verification. A hierarchical architecture is employed, using a structured or modular design.

The highest level is the Driver script, which is the engine of the test. The Driver begins a chain of calls to the lower level components of the test. Drivers may perform one or more test case scenarios by calling one or more Main scripts. The Main scripts contain the test case logic, calling the Business Function scripts necessary to do the application testing. All utility scripts and functions are called as needed by Drivers, Main, and Business Function scripts.

Driver Scripts: Perform initialization (if required), then call the Main Scripts in the desired order.
Main Scripts: Perform the application test case logic using Business Function Scripts.
Business Function Scripts: Perform specific Business Functions within the application.
Subroutine Scripts: Perform application specific tasks required by two or more Business Function scripts.
User-Defined Functions: General, Application-Specific, and Screen-Access Functions.

(Note that Functions can be called from any of the above script types.)

 

Processing Note: 
If an error occurs in the processing, such that we cannot continue with the Test Case, a "FALSE" condition is returned to the calling script. This script, in turn, returns the "FALSE" condition to its calling script, etc., until control is returned back to the Driver script. If the Test Case dependencies have been properly controlled, the Driver can then continue with the next Test Case, otherwise the Driver would have to exit.

Advantages:

• Utilizing a modular design, and using files or records to both input and verify data, reduces redundancy and duplication of effort in creating automated test scripts.
• Scripts may be developed while application development is still in progress. If functionality changes, only the specific "Business Function" script needs to be updated.
• Since scripts are written to perform and test individual Business Functions, they can easily be combined in a "higher level" test script in order to accommodate complex test scenarios.
• Data input/output and expected results is stored as easily maintainable text records. The user's expected results are used for verification, which is a requirement for System Testing.
• Functions return "TRUE" or "FALSE" values to the calling script, rather than aborting, allowing for more effective error handling, and increasing the robustness of the test scripts. This, along with a well-designed "recovery" routine, enables "unattended" execution of test scripts.

Disadvantages:

• Requires proficiency in the tool's Scripting Language;
• Multiple data-files are required for each Test Case. There may be any number of data-inputs and verifications required, depending on how many different screens are accessed. This requires data-files to be kept in separate directories by Test Case.
• Tester must not only maintain the Detail Test Plan with specific data, but must also re-enter this data in the various data-files.
• If a simple "text editor" such as Notepad is used to create and maintain the data-files, careful attention must be paid to the format required by the scripts/functions that process the files, or processing-errors will occur.