Functional Decomposition Method There are a couple of TAFs (Test Automation Frameworks) for Projects Automation.

For any Project to be automated, the main features to be considered are Maintainability, Durability, Reduced Redundancy which ultimately leads to saving Cost and Effort. Functional Decomposition is one of the best Methods for large/complex projects. The main and most important concept behind functional decomposition is to separate the data from the functions. In order to accomplish this, the test data can be stored Separately in a file or in a database. This data files/database is used as data input and also return value verification (verifying with the data returned form the software). This is achieved by employing a hierarchical architecture with a modular design. Implementation of Automation The highest script in the hierarchy is the controller / controlling script (Driver Script). This is the engine of the test automation suite. 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 (Verification Scripts), which perform the application testing. Apart from this, usually there are a few utility scripts that are used by the driver and verification scripts to perform a number of tasks. Controller / Driver Scripts: perform initialization (if required), and then call the business logic verification scripts in the desired order. Verification / Test Case Scripts: perform the Business Functions. Usually, the entire business logic is embedded within these scripts. Subroutine / Utility Scripts: perform application specific tasks required by two or more Business scripts. The generic nature of these scripts can contribute heavily to rapid script development. User-Defined Functions: general and/or application-specific functions. Such scripts can be shared across test automation suites. All utility scripts and functions are called, as needed by Drivers, Main, and Business Function scripts. Test Data (Data Driven Methodology) Database Design: Database is mainly used for Test Data i.e., Input values, Expected values and to Track the Results after execution. The values or records about the particular script details are entered in to the tables which will be used to input to the application and validate/compare based on the will Input Tables Contain the Input data or values which is taken by WinRunner Utility Scripts and put into Policy Link Application.

Validation Tables Expected values are entered from TT Reports or relevant output provided. These values are base values which compare with actual values from the application with the help of WinRunner and ultimately reported in the Result tables. Results Tables These tables contain the Results based on the comparison done by WinRunner with the Validation Tables. Accordingly a PASS or FAIL or a WARNING is added to the corresponding field. Based on the Results, Metrics are updated Database Query: These queries are created for input/validation tables (Get validation Records) Advantages of this Architecture: The modular design and use of files or records to both input and verify data, reduces redundancy and amount of effort in creating automated test scripts. Scripts can be developed even when the application development is in progress. If the functionality changes, only the specific verification/validation scripts containing the business logic need to be updated. Script reusability is very high. As the scripts are written to test various business functions independently, they can easily be combined in a controlling script in order to accommodate complex test scenarios. Maintaining the expected results for such scripts is very easy. Error handling is much more robust in these scripts. This allows unattended execution of the test scripts. Since such scripts have very little interdependency they can be used in a plug and play manner. Error handling is much more robust in these scripts. This allows unattended execution of the test scripts. GUI and Scripts maintainability is easy. Disadvantages: Technical and skilled personnel are required to create and maintain the scripts. If the test automation suite is very large, then maintaining the expected results can be quite time consuming. The testing team needs to maintain both the scripts as well as the test data. Proper care should be taken to make sure that the test data is maintained in appropriate file formats. If the test data is updated using some non-standard tool, it can lead to problems during test execution. Conclusion: Definitely there is cost saving with automation, but implementing best practices like Key word driven, functional decomposition, we could save lot of effort and money also. I would recommend to use this methodology for projects automation, irrespective of any functional/regression automation tool.