What is Automation Testing (Ultimate Guide to Start Test Automation)

Here is the Complete Guide to start Automation Testing on Your Project. Let’s get started. 

Let us first understand what Automation Testing is?

Automation testing is a Software testing technique to test and compare the actual outcome with the expected outcome. This can be achieved by writing test scripts or using any automation testing tool. Test automation is used to automate repetitive tasks and other testing tasks that are difficult to perform manually. 

The Ultimate Guide to Automation Testing

Do you want to start the automation test on your project but are you struggling with the most basic steps as mentioned below:

• How do you introduce automation to your project?
• How to select the best and right automation tool?
• How to develop scripts effectively?
• How to execute and maintain test scripts?
• Finally, what are the best practices that you need to follow for successful automation testing?

This is our attempt to enrich your knowledge with a series of tutorials on “Getting Started with Automation Testing”. This series of automation tutorials will answer all the above questions in a step-by-step manner with simple examples.

Let’s look at the series of Tutorials on Starting Automation on Your Project!!

Automation End-to-end Process:

Tutorial #1: Best Guide to Start Automation on Your Project
Tutorial #2: Types of Automated Tests and Some Misconceptions
Tutorial #3: 10 Steps to Introduce Automation on Your Project
Tutorial #4: The A to Z Guide on Selecting the Best Automation Tool
Tutorial #5: Script Development and Automation Frameworks
Tutorial #6: Execution and reporting of Automation
Tutorial #7: Best Practices and Strategies of Test Automation

Automation Tips:

Tutorial #8: 10 Tips you should read before automating your testing work
Tutorial #9: How Does Test Planning Differ for Manual and Automation Projects
Tutorial #10: When To Opt For Automation?
Tutorial #11: Automation Test Challenges
Tutorial #12: Guide to Implement Proof of Concept (POC) in Automation
Tutorial #13:How to Select Correct Test Cases for Automation
Tutorial #14: How to Translate Manual Test Cases into Automation Scripts

Automation Career:

Tutorial #15: Tips to Become a Better Automation Tester
Tutorial #16: Test Automation – Is it a Specialized Career? Can Normal Testers Do Automation Also?

Popular Automation Tools:

Tutorial #17: Selenium Tutorials 31+ Best Free Selenium Training Tutorials
Tutorial #18:QTP Tutorials
Tutorial #19: SoapUI Web Services Testing Tool
Tutorial #20: HP LoadRunner for Performance Testing

Automation Frameworks:

Tutorial #21: Why Do We Need Framework for Automation
Tutorial #22: Most Popular Automation Frameworks

Automation in Agile:

Tutorial #23: How to Implement Efficient Automation in the Agile World

Other Automation Tools:

Tutorial #24: Best Automation Test Tools
Tutorial #25: Sikuli GUI Automation Tool
Tutorial #26: PowerShell: Desktop Application UI Automation With PowerShell
Tutorial #27: Katalon Automation Recorder (Selenium IDE Alternative)
Tutorial #28: Geb Tool: Browser Automation Using Geb Tool
Tutorial #29: AutoIt: How to Handle Windows Pop-up Using AutoIt
Tutorial #30: Cucumber: Automation Using Cucumber Tool and Selenium
Tutorial #31: Protractor Testing Tool for End-to-end Testing of AngularJS Applications

Mobile Automation Testing:

Tutorial #32: Appium Studio Hands-on Tutorial
Tutorial #33: Appium Tutorial for Beginners
Tutorial #34: Selendroid Tutorial: Android Mobile Automation Framework
Tutorial #35: Ranorex Tutorial: A Powerful Desktop, Web, and Mobile Testing Tool

Domain Specific Automation Examples:

Tutorial #36: Automation of JAVA/J2EE Applications

Interview Preparation for Automation Jobs:

Tutorial #37: Automation Testing Interview Questions
Tutorial #38: Selenium Interview Questions

Let’s explore the first tutorial from “The Ultimate Guide to Automation Testing” series!!

What is Automation Testing

If a software can do anything then, why can’t a software test a software?

Does this statement sound logical to you?

If yes, you are now thinking about Test Automation, which is the focal point that we are going to discuss in this series of informative tutorials.

Imagine yourself on the first day at your job as an SQA. You will be presented with an application to be tested. It’s an ERP application containing 100s of forms and thousands of reports. You can begin your exploratory testing by opening a form containing around 50 different fields.

You try to enter random data in this form, which will take around 20 minutes. Then you press submit. An error message is shown which looks like an unhandled exception. You note down the steps and report the bug in your bug management system.

You feel really confident and energetic. You continue testing until the end of the day and find some more bugs. “It has been an amazing first day”, you thought.

Suggested reading =>> Top Online Automation Testing Courses

Now comes the next day, the developer has fixed the issue and releases a new version of the build. You test the same form with the same steps and found that the bug is fixed. You then mark it as fixed.

You have contributed to the quality of the product by identifying that bug, and as this bug is fixed, the quality is improved.

Now comes the third day, a developer has again released a newer version. Now you test that form to make sure that no regression issue is found. It will last for 20 minutes. You’re starting to feel a bit bored now.

Now imagine 1 month from now, newer versions are constantly releasing and on every release, you have to test this lengthy form plus 100 of other forms like this, just to make sure that no regression is there.

Now you feel angry and tired. You begin to skip the steps. You only fill around only 50% of the total fields. Your accuracy is not the same, your energy is not the same and definitely, your steps are not the same.

And one day, the client reports the same bug in the same form. You feel pathetic. You feel unconfident now. You think you are inadequate in terms of skills. Managers are questioning your ability.

I have a news for you; this is the story of 90% of the manual testers out there. You are not different.

Regression issues are the most painful issues. We are humans. And we cannot do the same thing with the same energy, speed and accuracy every day. This is what machines do.

Automation is required for this purpose, to repeat the same steps with the same speed, accuracy, and energy as they were repeated the first time.

Whenever such a situation arises, automate your test case. Test automation is your friend. It will help you focus on new functionality while taking care of the regressions. With automation, you can fill that form in less than 3 minutes.

The script will fill all the fields and let you know the result along with screenshots. In case of failure, it can pinpoint the location where the test case failed, thus helping you to reproduce it with ease.

Automation – A Cost-Effective Method for Regression Testing

Automation costs can be really high initially. This includes the cost of the tool and the cost of the automation testing resource and his/her training.

But when the scripts are ready, they can be executed hundreds of times repeatedly with the same accuracy and rather quickly. This will save many hours of manual testing.

Hence, the cost gradually decreases and ultimately it becomes a cost-effective method for Regression testing.

Scenarios That Require Automation

The above scenario is not the only case when you will need automation testing. There are several situations, which cannot be tested manually.

For Example,

1. Comparing two images pixel by pixel.
2. Comparing two spreadsheets containing thousands of rows and columns.
3. Testing an application under the load of 100,000 users.
4. Performance Benchmarks.
5. Testing the application on different browsers and on different operating systems in parallel.

These situations require and should be, tested by tools.

So when to automate?

This is an era of agile methodology in SDLC, where the development and testing will go almost in parallel and it is very difficult to decide when to automate.

Consider the following situations before stepping into automation:

• The product may be in its primitive stages, when the product does not even have a UI, at these stages we must have a clear thought on what we want to automate. The following points should be remembered.
  • Tests should not be obsolete.
  • As the product evolves it should be easy to pick on the scripts and add on to it.
  • It is very important to not get carried away and ensure that the scripts are easy to debug.
• Do not attempt UI automation at the very initial stages as UI is subjected to frequent changes, thereby will lead to scripts failing.
• If possible, opt for API level/Non UI level automation until the product stabilizes. API automation is easy to fix and debug.

How to Decide on Best Automation Cases

Automation is an integral part of a testing cycle and it is very important to decide what we want to achieve with automation before we decide to automate.

The benefits that automation seems to provide are very attractive, but an ill-organized automation suite can spoil the entire game.

Testers may end up debugging and fixing the scripts most of the time, resulting in loss of testing time.

This series explains you about how an automation suite can be made efficient enough to pick up the right tests cases and yield the right results with the automation scripts that we have.

I have also covered the answers to questions like when to automate, what to automate, what not to automate and how to strategize automation.

Right Tests for Automation

The best way to tackle this problem is to quickly come up with an “Automation Strategy” that suits our product.

The idea is to group the test cases so that each group will give us a different result. The Illustration given below shows how we can group our similar test cases, depending on the product/solution that we are testing.

Let us now dive deep and understand what each group can help us achieve:

#1) Make a test suite of all the basic functionality Positive tests. The suite should be automated, and when the suite is run against any build, results are shown immediately. Any script failings in this suite can lead to S1 or S2 defects, and those build specifics can be disqualified. This saves a lot of time.

As an additional step, we can add this automated test suite as a part of BVT (Build Verification Tests) and check the QA automation scripts into the product building process. So when the build is ready, the testers can check for the automation test results and decide if the build is suitable or not for installation and further testing process.

This undoubtedly fulfills the objectives of automation, which include:

• Reduce testing efforts.
• Find Bugs at earlier stages.

#2) Next, we have a group of End to End tests.

Under large solutions, testing an end to end functionality holds the key, especially during the critical stages of the project. We should have a few automation scripts that touch upon the end to end solution tests as well. When this suite is run, the result should indicate whether the product as a whole is working as it is expected or not.

Automation test suite should be indicated if any of the integration pieces are broken. This suite does not need to cover each and every small feature/functionality of the solution but it should cover the working of the product as a whole.

Whenever we have an alpha or a beta or any other intermediate releases, then such scripts come in handy and give some confidence to the customer.

To understand better let’s assume that we are testing an online shopping portal, as part of the end to end tests we should be covering only the key steps involved as given below:

• User login.
• Browse and select items.
• Payment Option – this covers the front end tests.
• Backend order management (involves communicating with multiple integrated partners, checking stock, emailing the user etc). This will help the testing integration of individual pieces and also the crux of product.

So when one such script is run it gives confidence that the solution as a whole is working fine.

#3) The third set is the Feature/Functionality based tests.

For example, we may have the functionality to browse and select a file, so when we automate this we can automate cases to include a selection of different types of files, sizes of files etc, so that feature testing is done. If there are any changes/additions to that functionality, this suite can serve as a Regression suite.

#4) Next on the list would be UI based tests. We can have another suite that will test purely UI based functionalities like pagination, text box character limitation, calendar button, drop downs, graphs, images and many such UI only centric features. Failure of these scripts is usually not very critical unless the UI is completely down or certain pages are not appearing as expected!

#5) We can have another set of tests that are simple but very laborious to be carried out manually. Tedious but simple tests are the ideal automation candidates, for example entering details of 1000 customers into the database has a simple functionality but is extremely tedious to do manually. Such tests should be automated. If not, they mostly end up getting ignored and not tested.

What NOT to Automate

Given below are a few tests that should not be automated.

#1) Negative Tests / Failover Tests

We should not attempt to automate negative or failover tests. As for those, the testers need to think analytically and negative tests are not really straightforward to give a pass or fail result which can help us.

Negative tests will require a lot of manual intervention to simulate an actual disaster recovery kind of scenario. Just to exemplify that we are testing features like web services reliability and to generalize, the main aim of such tests would be to cause deliberate failures and see how well the product is reliable.

Simulating the above failures are not straightforward. It can involve injecting some stubs or use some tools in between and automation is not the best way to go here.

#2) Ad hoc Tests

These tests may not really be relevant to a product at all times and this may even be something that the tester could think of at the stage of project initiation. Also, the effort to automate an ad hoc test has to be validated against the criticality of the feature that the tests touch upon.

For example, a tester who is testing a feature which deals with compression/encryption of data might have done intense ad hoc tests with a variety of data, file types, file sizes, corrupt data, a combination of data, using different algorithms, across several platforms, etc.

When we plan for automation, we may want to prioritize and not do exhaustive automation of all the ad hoc tests for that feature alone, and end up with a little time to automate other key features.

#3) Tests with massive pre-setup

There are tests that require some enormous pre-requisites.

For example, we may have a product that integrates with a 3rd party software for some functions, as the product integrates with any messaging queue system that requires installation on a system, setting up of queues, creating queues, etc.

The 3^rd party software could be anything and the setup may be complex and if such scripts are automated, then these will forever depend on the function/setup of that 3rd party software.

Pre-requisites include:

Presently, things may look simple as both side setups are being done and everything is fine. Many times when a project enters the maintenance phase, the project is moved to another team, and they end up debugging such scripts where the actual test is very simple but the script fails because of a 3^rd party software problem.

The above is just an example. Keep an eye on tests that have laborious pre setups for a simple test that follows.

A Simple Example of Test Automation

When you are testing a software (on the web or desktop), you normally use a mouse and keyboard to perform your steps. Automation tools mimic the same steps by using scripting or a programming language.

For Example, if you are testing a calculator and the test case is that you have to add two numbers and see the result. The script will perform the same steps by making use of your mouse and keyboard.

The example is shown below:

Manual Test Case Steps:

1. Launch Calculator
2. Press 2
3. Press +
4. Press 3
5. Press =
6. The screen should display 5.
7. Close Calculator.

Automation Script:

//the example is written in MS Coded UI using c# language.
[TestMethod]
public void TestCalculator()
{
 
//launch the application
var app = ApplicationUnderTest.Launch("C:\\Windows\\System32\\calc.exe");
 
//do all the operations
Mouse.Click(button2);
Mouse.Click(buttonAdd);
Mouse.Click(button3);
Mouse.Click(buttonEqual);
 
//evaluate the results
Assert.AreEqual("5", txtResult.DisplayText,”Calculator is not showing 5);
 
//close the application
app.Close();
}

The above script is just a duplication of your manual steps. The script is easy to create and easy to understand as well.

What are the Assertions

The second last line of the script needs some more explanation.

Assert.AreEqual(“5”, txtResult.DisplayText,”Calculator is not showing 5);

In every test case, we have some expected or predicted result at the end. In the above script, we have an expectation that “5” should be shown on the screen. The actual outcome is the result that is displayed on the screen. In every test case, we compare the expected outcome with the actual outcome.

Same goes for automation testing as well. The only difference here is, when we do that comparison in test automation, then it is called something else in every tool.

Some tools call it “Assertion” or “checkpoint” and others call it “validation”. But basically, this is just a comparison. If this comparison fails, for E.g. a screen is showing 15 instead of 5 then this assertion/checkpoint/validation fails and your test case is marked as failed.

In the event that a test case fails due to an assertion, it signifies the identification of a bug through test automation. You are required to submit a report to your bug management system as you typically do during manual testing.

In the above script, we have performed an assertion in the second last line. 5 is the expected outcome, txtResult. DisplayText is the actual outcome and if they are not equal, we will be shown a message that “Calculator is not showing 5”.

Conclusion

Often, testers come across project deadlines and mandates to automate all cases to improve testing estimates.

There are a few common “wrong” perceptions about automation. They are:

• We can automate every test case.
• Automating tests will reduce testing time enormously.
• No bugs are introduced if automation scripts are running smoothly.

There should be enough clarity that automation can reduce testing time only for certain types of tests. Automating all the tests without any plan or sequence will lead to massive scripts which are heavy maintenance, fail often and need a lot of manual intervention too.

Also, in constantly evolving products, automation scripts may go obsolete and need some constant checks. Grouping and automating the right candidates will save a whole lot of time and give all the benefits of automation.

You can summarize this informative tutorial in just 7 points.

Automation Testing:

• Is the testing which is done programmatically.
• Uses the tool to control the execution of tests.
• Compares expected outcomes with the actual outcomes (Assertions).
• Can automate some repetitive but necessary tasks (E.g. Your regression test cases).
• Can automate some tasks which are difficult to do manually (E.g. Load testing scenarios).
• Scripts can run quickly and repeatedly.
• Is cost effective in the long run.

In this article, automation is explained in simple terms, but that doesn’t mean that it is always simple to do. There are some challenges, risks, and many other obstacles involved in it. There are several ways by which test automation can go wrong, but if all goes well, then the benefits of test automation are really huge.

Upcoming ones in this series:

In our upcoming tutorials, we will discuss several aspects related to automation.

They will include:

1. Types of automated tests and some Misconceptions.
2. How to introduce automation in your organization and avoiding common pitfalls when doing test automation.
3. The process of selecting tools and comparing different automation tools.
4. Script Development and Automation Frameworks with examples.
5. Execution and reporting of Test Automation.
6. Best Practices and Strategies of Test Automation.

Are you eager to learn more about the various concepts of Automation Testing? Watch out and stay tuned to our list of upcoming tutorials in this series and express your thoughts in the comments section below. We would love to hear from you.

NEXT Tutorial#2