Functional Test Automation Life Cycle
Functional Test Automation Life Cycle
Functional Test Automation life cycle Methodology comprises of below phases:
1. Decision to automate testing: it is not that, directly we can kick-start automation for any project/AUT. The Test Manager and client has to take the decision on whether to go for Test Automation or not. First, the need for Test Automation for the current project has to be determined considering the current status and future plan of the project. During that phase a Cost-Benefit Analysis has to be performed, during which the ROI(Return-On-Investment) has to be calculated and when the ROI is positive and considerable in acceptable time frame, the automation for the project can be given a nod.
2. Acquisition of Testing Tool: Once the decision has been made to go for automation, then the tool to automate the manual test cases has to be decided based on analysis of all the available tools in the market. There are several factors to consider like capability of the tool, compatibility of the tool with the application, cost and ease of automation- design, execution and maintenance. If the tool is an easy to learn one then the aspect of “Availability of skilled resources” which we discussed earlier can be waived off as the available resources can be trained to make them skillful to work on the project.
3. Automation test planning: Once the Automation and tool are decided, the most important phase is the Test Planning Phase. This is the phase where the Test Manager/Automation Lead along with the client, has to plan on how to automate, what to automate, when to automate and who to automate. This phase also included the plan for the creation of Automation framework. The framework needs to be designed based on the need and scope of the project.
4. Set-up the automation environment: When the plan is ready, then the environment needs to be setup. This includes several activities like creating the application environment for automation similar to Dev-Environment and QA-environment. Sometimes due to budget/ any other constraint, a separate application environment for automation may not be available. In such cases, the QA-environment is used for automation. But, it is always a best practice to create a separate test data for automation so as not to interfere with regular manual testing activities. This phase also involves the formation of the team, necessary trainings and making the required test wares available.
5. Design the Automation framework: The automation framework is designed in this phase so as to carry on the automation script development, integration, and execution and maintenance activities at ease.
6. Design/development of test scripts: Automation scripts are created in this phase.
7. Review and rework of test scripts: This is one of the most important phases, which is neglected by many. Each and every test script has to be reviewed with the help of an optimal checklist and by entering the review comments in a pre-defined review template. Once the review is completed, appropriate rework needs to be done implementing the review comments.
8. Integration of test scripts: All the scripts created by the Automation team are integrated in order to be executed during the execution phase. Baseline results are created for all the scripts developed.
9. Execution of test scripts: Test scripts are executed in this phase either by the Automation team or the manual testers. This is execution for the final regression of the release/phase.
10. Analysis of test results: Test results are analyzed after execution & defects are logged accordingly in the Defect Management tool.
11. Documentation: Reference documents & support documents are prepared explaining the Functionalities that were automated. A Test Coverage Matrix with the mapping of manual test cases that were automated. In case of Keyword driven framework, a keyword catalogue is also prepared.
12. Enhancement of test scripts (Maintenance Phase): Some of the test scripts may need to be updated depending on the change in the functionality for a particular version/build/release of the application and sometimes test scripts may need to added if new functionality is included in the application. Again, review comes into picture, followed by rework and so on