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 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.
What You Will Learn:
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 of 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:
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. :)
There are two kinds of automation experts.
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 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 especially about object-oriented programming. A combination of 1 automation architect and two automation engineers is great for most of the products.
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:
There are various other factors while selecting the right tool and I will cover them in a separate article.
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:
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 a 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
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.
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 the application, the scripts need 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.
You can also start reading more on automation frameworks in following tutorials:
The execution plan includes selecting which environments the scripts will be executed. The 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.
When the 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.
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.
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 an 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 kinds 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 a 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.