In many organizations, quality is the first preference. If you are found to be in such an organization and still there is no formal test automation is done, you could be the person to inaugurate it. It will assist your organization to build more quality products in less time and likewise be able to market it early.
=> In this third piece of the ‘Test automation tutorial series’, I will discuss about how to introduce test automation in your organization. It is significant to understand that which step is to perform first and why.
Sticking with these steps will help you to introduce automation in a seamless way and allow you to avert common pitfalls which leads to automation failures.
Steps to introduce test automation in your organization:
Steps to introduce test automation in your organization:
Step #1. Convince the Management
No matter how much you are eager to discover and initiate test automation in your organization, you cannot do anything if your management is not convinced about the benefits test automation offers. It is a universal fact that test automation is expensive. The tools are expensive (HP QTP/UFT license cost around $8K per machine). There is a cost of a test automation architect or engineer (which, by the way, are expensive too). After that, the benefits of test automation cannot be seen immediately. You have to wait 2-3 months before your scripts are prepared, tested, and that can run reliably for you to test the application.
You have to convince the management to bear the pain of these expenses and also you have to tell them to be patient before test automation can start giving them results.
So how they will be convinced? You have to tell them the cost benefit analysis. Like you can ask questions that how much time we take to test the BAT (Build Acceptance Testing) of our application? Then you can say, if it takes a day, with test automation we can test it within 2 hours. The cost is that you have to purchase the tool, train the resource and wait for the results for two months. After two months, we will be able to run a BAT in two hours. That will save 6 hours of manual testing each time whenever a new build releases. If build is released 4 times a month. You will be able to save 24 hours or 3 days of manual testing!
That doesn’t mean that manual testers will not be doing anything. They will use these 6 hours of testing to focus on new and important functionalities of the application, while automation will take care about the regression issues. This setup will overall improve the quality of product a dozen times.
If your management is not willing to pay for the quality of their products, then nobody can force them to do so. They will learn automatically when clients will complain about the products. Quality affects everything. It affects your sales, it affects your relationship with clients, it affects your perception in the minds of consumers. So, intelligent management has always invested in the quality of their products.
So five points to remember about convincing your management:
1. Tell them about the benefits of test automation in detail.
2. Tell them, that test automation is expensive and it will cost you money initially but then the cost will be reduced once scripts are prepared and start executing.
3. Tell them that they have to wait for around 3 months before expecting any result from test automation.
4. Tell them, that test automation is not to replace manual testers, but to aid manual testers as they will able to test more in the same time.
5. Test automation does not mean more testing in less time; it means more testing in the same time. (If manual testers used to test the BAT in 8 hours, they will be able to test the BAT plus new functionality plus many other things in the same 8 hours in the presence of automation.)
Remember, convincing your management is the first and most important step in introducing test automation in your organization. If they are not convinced, forget test automation or change your organization.
Step #2. Finding Automation tool experts
There are two kinds of automation experts.
1. Automation architects
2. Automation engineers
Automation architects are a rare breed. They are hard to find, extremely expensive and extremely necessary for the success of the automation project. These people are usually responsible to build automation frameworks. (We will discuss about automation frameworks in detail in a separate article)
Automation architects are experienced in different kinds of tools and they usually know the strengths and weaknesses of each tool. They will also help the management in selecting the right tool for automation by carefully analyzing the application and technologies used in that application. They will also help to build the framework, designing the naming conventions and creating rules for scripting. They will also assist in selecting which test cases to automate first.
If you are able to find a right resource for the post of automation architect, your half work is done in successful automation in your organization
Automation engineers on the other hand are the people who will convert manual test cases into automated scripts. They will work under an automation architect and will be responsible for creating and executing scripts.
Some companies hire automation engineers from outside and some companies do in house hiring by training their existing manual testers. Whatever the case, the resource must be good in programming. He/she has to know specially about object oriented programming. A combination of 1 automation architect and two automation engineers is great for most of the products.
Step #3. Using the correct tool for automation
This point deserves its own article (and I will write one on that). This is another difficult step in the process of starting automation. There are various tools in the market, but you have to select those which are best for your application.
To make it short, I will write the most important considerations while selecting the tool. I will explain the tool selection process in detail in a separate article.
The most important things to consider while selecting the right tools are:
The tool must be in your budget. The automation tools are really expensive. So the company should have the budget to purchase the tool.
The tool must support technologies used in your application. If your application is using flash or Silverlight, the tool must support it. If your application is running on mobile, the tool must be able to execute scripts on mobile. You can purchase a single tool that supports all technologies used in your application or you can purchase separate tools for each technology. For example, you can use selenium for your web applications, Robotium for your Android applications and MS Coded UI for desktop applications. Whatever the decision, this should be in your budget.
You must have the necessary skilled resources who can use this tool or learn that tool in less time. For example, you have hired the automation architect who has only experienced in QTP, and you are purchasing a license for MS Coded UI, the resource might not be comfortable using it. Tools are like good cars, but you must have good drivers too to drive these good cars.
The tool must have a good reporting mechanism to show the results to stakeholders after each execution.
There are various other factors while selecting the right tool and I will cover them in a separate article.
Step #4. Analyzing various applications to determine those which are best suited for automation
If your organization is working on 5 applications, it is not necessary that each should be automated. We have to see the various factors while selecting any application to automate.
The application which should be automated must have these factors:
1. The application should not be in the early stages of its development. (The application should have all or some modules which are stable and tested by manual testers)
2. The UI of the application must be stable. (The UI must not change frequently)
3. The manual test cases of this application should be in written form.
4. The main goal of automation is to make sure that if the application is bug free in one build, it should remain bug free in the next build. The manual tester should not waste their time in finding regression issues, these issues should be identified in automation.
So to find regression, we must have an application which is already stable and has some test cases written for it. Automation team will convert these test cases into scripts and will run these scripts on every build to make sure no regression appears.
Also read => How to Select Correct Test Cases for Automation Testing
Step #5. Training the Team
After tool selection and resource hiring, the next step is logically the training of the resources.
If manual testers are converted into automation engineers, they have to be trained on automation terminologies and concepts. If automation architect is hired from outside, he must get knowledge about the product to test, the manual testing process and what management is expecting.
Give resources some time to try different things until they finally come up with a winning automation strategy. Train them on the tools which organization is already using like bug tracking software and requirements management software.
Good training and strong communication between manual testers, developers and automation team is really necessary.
Step #6. Creating the test automation Framework
The biggest task for the automation architect is to come up with an automation framework that should support automated testing for the long run.
Automation framework is basically the set of rules and careful planning to write the scripts in a manner which results in the least amount of maintenance. If anything changes in application, the scripts needs little or no updating to cope up with that change. That is the beauty of an automation framework.
There are five kinds of automation frameworks, namely linear, modular, data-driven, keyword-driven and hybrid. All of these frameworks will be covered in detail with examples in a separate article in this series.
Step #7. Developing an Execution Plan
The execution plan includes selecting which environments the scripts will be executed. Environment includes OS, Browser and different hardware configurations.
For example, if the test case demands that it should check the website in 3 browsers, namely, Chrome, Firefox and IE, then the automation team will write the script in such a manner that it will be able to execute in each browser.
This should always be told before writing the scripts because it will be taken care in scripts if the automation team know it beforehand. The execution plan should also state that who will execute the scripts. Normally the automation team executes the scripts on every build, but it varies from company to company. Some managers ask developers to execute these scripts on their build before release and some companies hire a dedicated resource just for the execution. Even some companies run scripts in unattended mode, which of course requires no additional resource.
Step #8. Writing Scripts
When framework is designed, the execution plan is known and resources are trained on the new tool, now it’s the right time to start writing scripts.
Scripts should be written in an organized manner with proper naming convention. The source code should be maintained in a source control to avoid code loss. Version control and history should be maintained. Test automation is just like software development. All best programming practices should be taken care while writing the scripts.
Also read => How to Translate Manual Test Cases into Automation Scripts
Step #9. Reporting
The reporting feature is usually provided by the tool. But we can create custom reporting mechanisms like auto-emailing the results to management.
We can create reports at the end of each execution in the form of charts and tables if management needs it. The management should always be informed about the test case coverage, that means which manual test cases are covered in automation and which of them are remaining.
Step #10. Maintenance of Scripts
If best programming practices are followed and framework is good, then maintenance will not be a problem.
Maintenance usually occurs when there is a change request in application. The scripts should immediately be updated to cope with that change to ensure flawless execution.
For example, if you are writing some text in the textbox through the script and now this text box becomes the drop down list, we should immediately update the script.
Some other kind of changes include that your scripts were running on the English version of the application. Now there is a change request that the application should support Chinese. Your framework should allow you to update your scripts with little effort to support execution in Chinese too! (That is why Automation architects are expensive )
If the framework is not good and best practices are not followed, then maintenance will become a nightmare. Most automation projects fail due to poor maintenance of scripts.
This article describes how you should do automation in your organization from start to end in a step by step manner. If you follow these steps, I hope your automation will be a success.
There are some parts (like Automation tool selection and Automation Frameworks) which deserve their own articles. We will cover these in upcoming parts of this automation testing tutorial series.
=> Meanwhile click here to check all the tutorials we already posted in this series.
I tried to cover all aspects in broader view and use my own experience to write this tutorial. If you feel that I missed something important or some portion of this tutorial needs a little more explanation, please ask me in the comments section. I would love to answer your queries.