What is automation testing?

To understand automation testing, let us first understand what software testing is.

Software testing is the process of finding defects in a software by running the software under set conditions and comparing the output received with the expected output. (More specifically, this is known as dynamic testing as opposed to static testing, which is dominantly conducted through code reviews).

It requires planning on what to test, under what conditions to test it and with what inputs, and how to verify the results. Once this planning is done, tests are executed, and a tester runs the system under test (SUT**) with the given conditions and manually verifies the results.

However, if we use software to test an application rather than a tester, the testing software runs the SUT, captures the results produced, and compares them with the expected results. Hence the testing software takes the role of the human that would have manually executed test cases and verified results. This is known as automation testing.

How is a software able to test another software?

Testing is a process, and software automates processes. There is a small catch, though. In this case, the testing software does not take inputs from the user or provide output. Instead, it feeds inputs into another software and captures its output.

In this blog, let us limit the discussion to testing web applications. When we have to automate the testing of web applications, then the testing software should be able to mimic the behavior of a human who is interacting with the SUT through a browser. For this, it should be able to manipulate the functions of a browser. There are many such tools in the market, with Selenium being the most popular.

For one, Selenium is open source and free to use. Secondly, it supports multiple programming languages so that it can be adopted by testers and developers with different skill sets. These reasons make Selenium the de-facto choice as an automation tool.

Selenium provides APIs that can interact with the browser. Using these APIs, we can search for different components or “elements” on a given web page, i.e., a particular textbox, button, or cell in a table. Once we find the element on the page, we can interact with it using the APIs of Selenium. For example, we can populate a textbox, make a selection from a dropdown list, or click on a button. This is the way we can mimic user behavior and proceed with testing.

How does automation help?

Once Selenium is programmed, the test scripts can be run repeatedly. Firstly, the test scripts run faster compared to the manual execution of test cases. Secondly, it does not make mistakes that human testers can make. And also, these test cases can be run even at times when the engineers are away (i.e., as night or weekend jobs). All these reasons make automation testing efficient, effective, and economical.

But isn’t creating these test scripts a lot of work?

Yes, it is quite some work. But let us compare it with the work needed to run test cases. If a test case is to be run only once, manual test execution will be much easier and faster.

However, this is rarely the case. Typically, an application is tested multiple times because we conduct similar and overlapping test cases during unit testing, then during system testing, during retesting when the reported defects are fixed, and so on.

Even when we make no changes to a given module, we have to perform testing on the unchanged modules because there may be new defects because of changes made elsewhere. This is known as regression testing.

In an agile methodology, we make multiple small but frequent releases. This means that the testing is to be repeated in quick succession. Also, the objective of agile is to bring out smaller increments faster, so they must be tested fast too. So we can see that the testing efforts escalate, and the time available to test continues to shrink as the application matures.

Given this, it is easy to see that the effort to write test scripts once is soon compensated for by the time and effort savings it provides with each subsequent release.

Can we automate testing without programming?

The testing tool will have to be programmed to perform automation testing. However, there may not be a need to write code manually. This can be done using the following two approaches:

• Use a record and play approach
• Use a scriptless automation testing tool

The record and play approach is also supported by Selenium (The component that does that is known as Selenium IDE). Many other tools in the market can do the same. This is a straightforward approach to start with automation testing, but unfortunately, this does not take you too far.

Automating test cases is not just about repeating the same actions repeatedly but a lot more than that, e.g., running the given case with multiple data inputs, verifying multiple parts of a function, and so on. Hence, this approach is usually not preferred for a professional software application.

Scriptless automation tools are much more advanced than the record and play solutions. You can build your testing logic using the test tool's drag-and-drop approach. You do not need to write the code and learn its syntax. This is a viable option even for professional software. However, please do realize this is not a silver bullet and has its share of shortcomings, the most important ones being:

• You get locked in with the vendor.
• While you may not need to learn the syntax of a language like Java, you still need to build the logic using the drag-and-drop tool. That is a lot easier but is also an effort that cannot be neglected. Also, if the script does not work the way you want, you have to troubleshoot and debug, which could be a little challenging sometimes.
• There are always some corner cases that the tool cannot cover, and you either have to live without those, or if the tool provides for that feature, you could solve that part by writing your custom code.

To automate or not to automate, and how?

If your application is going to evolve over time, it is a good idea to automate your testing, at least partially. The ROI is obvious and significant.

To answer the question - of how to automate, we have three broad choices:

• Record and play is not an approach for professional applications, though it could be an approach for a quick proof of concept.
• You may want to consider a scriptless automation tool if you are entirely bought in into the vendor, as there will be a vendor lock-in. Also, the resources will have to be trained on the particular tool. However, this approach will help you get started faster. In addition, this approach is beneficial if you already have a team of manual testers and want them to bring automation into the mix.
• If you are planning a long-term approach, your best bet is to build a framework in-house using stable products like Selenium, TestNG, Cucumber, Cypress, etc. This may seem somewhat time-consuming initially, but efficiencies accrue over time, and flexibility will pay back in the long run.

Wishup offers software testers who are proficient in automation testing. To know more about them, send us an email at [email protected] or visit our website Wishup.co

**SUT - System Under Test - This is the system or the application that is being tested. In the manual testing world, it sufficed to call it the system or the software. However, in automation testing, there are two softwares, the one that is being tested and the one that does the testing. So to clearly disambiguate, we call the system being tested as SUT, and the one that performs the testing is called testing software.