To understand automation testing, let’s first understand what software testing is.

Software testing finds bugs in a software by running the software under specified conditions and comparing the output obtained with the expected output. (Strictly speaking, this is called dynamic testing, as opposed to static testing, which is mostly done through code reviews).

Planning must be done on what to test, under what conditions and with what inputs, and how to verify the results. Once this planning is complete, tests are performed and a tester runs the system under test (SUT**) under the given conditions and manually verifies the results.

However, when we use software to test an application instead of a tester, the testing software runs the SUT, captures the generated results and compares them to the expected results. The test software thus takes on the role of the human who would have manually executed test cases and verified the results. This is called an automation test.

Testing is a process, and software automates processes. However, there is a small catch. In this case, the test software takes no input from the user and provides no output. Instead, it feeds input to other software and captures its output.

For this blog, let’s limit the discussion to web application testing. If we need to automate web application testing, the testing software should be able to mimic the behavior of a human interacting with the SUT through a browser. To do this, it should be able to manipulate the functions of a browser. There are many such tools on the market, with selenium being the most popular.

For one thing, Selenium is open source and free to use. Secondly, it supports multiple programming languages, so it can be adopted by testers and developers with different skill levels. 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 “items” on a given webpage, i.e. a specific text box, button or cell in a table. Once we’ve found the element on the page, we can interact with it using Selenium’s APIs. For example, we can fill a text box, make a selection from a drop-down list, or click a button. This allows us to mimic user behavior and continue testing.

Once Selenium is programmed, the test scripts can be run repeatedly. First, the test scripts run faster compared to running test cases manually. Second, it doesn’t make mistakes that human testers can make. In addition, these test cases can also be executed during times when the engineers are absent (ie as night or weekend jobs). All these reasons make automation testing efficient, effective and economical.

Yes, it’s a lot of work. But let’s compare it to the work required to run test cases. If a test case should only be executed once, manual test execution becomes much easier and faster.

However, this is rarely the case. Typically an application is tested multiple times as we run similar and overlapping test cases during unit testing, then during system testing, during retesting when the reported bugs are fixed, etc.

Even if we don’t make any changes to a particular module, we still need to run tests on the unchanged modules, as new bugs may appear due to changes elsewhere. This is called a regression test.

In an agile methodology, we make multiple small but frequent releases. This means that the exam must be repeated in quick succession. Also, the goal of Agile is to get smaller increments out faster, so they need to be tested quickly, too. So we can see that the testing effort escalates and the time available for testing continues to shrink as the application matures.

With this in mind, it’s easy to see that the effort of writing test scripts once is quickly offset by the time and effort saved with each subsequent release.

The test tool must be programmed to perform automation tests. However, it may not be necessary 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 this is known as the Selenium IDE). Many other tools on the market can do the same. This is a simple approach to get started with automation testing, but unfortunately it doesn’t get you very far.

Automating test cases isn’t just about repeating the same actions over and over again, it’s about much more than that, e.g. B. running the given case with multiple data inputs, verifying multiple parts of a function, and so on. Therefore, this approach is not usually preferred for a professional software application.

Scriptless automation tools are much more advanced than the record and play solutions. You can create your test logic using the test tool’s drag-and-drop approach. You don’t have to write the code and learn its syntax. This is also a viable option for professional software. However, please note that this is not a silver bullet and has a few shortcomings, the main ones being:

• You will be connected to the provider.
• While you may not need to learn the syntax of a language like Java, you still need to create the logic using the drag-and-drop tool. This is much easier, but also a not inconsiderable effort. If the script doesn’t work as intended, you need to troubleshoot and debug, which can be a bit difficult at times.
• There are always some corner cases that the tool can’t cover and you either have to live without them, or if the tool provides that feature, you can solve that part by writing your custom code.

If your application will evolve over time, it’s a good idea to automate at least some of your testing. The ROI is obvious and significant.

To answer the question of how to automate, we have three big options:

• Record and Play is not an approach for professional applications, but could be an approach for a quick proof of concept.
• You may want to consider a scriptless automation tool if you are fully bought into the provider as there will be provider lock-in. In addition, the resources for the respective tool must be trained. However, this approach will help you get started faster. Additionally, this approach is beneficial if you already have a team of manual testers and want them to bring automation into the mix.
• If you plan to take a long-term approach, it’s best to build a framework in-house with stable products like Selenium, TestNG, Cucumber, Cypress, etc. and flexibility pay off in the long run.

Wishup offers software testers who are skilled in automation testing. To find out more about them, email us at [email protected] or visit our website Wishup.co

**SUT – System Under Test – This is the system or application under test. In the world of manual testing, calling it the system or the software was enough. However, in automation testing, there are two pieces of software, the one being tested and the one running the tests. To make the distinction clear, we call the system being tested SUT and the one doing the testing is called test software.