WWCode Talks Tech 27: The ABCs of Automating Tests for Software Applications

Women Who Code Talks Tech 27     |     Spotify – iTunes – Google – YouTube – Text

Spreeha Dutta, Software Engineer at Shell, Blogger, and Spotify podcast producer of A Walk Through Changing Times, shares the “ABCs of Automating Tests for Software Applications.” She shares the benefits of automation, with the understanding that it is not practical to always use automation as a tool. She also discusses Chrome extensions versus writing your own automation.

Why automation testing? It saves a lot of manual effort, things that are repetitive, or heavy workflows. Manual effort and resources can be better utilized in other ways when they are automated. Automation testing is also an emerging and growing field. It helps expand your business to a larger audience. It saves not only effort but a significant amount of time. It has become an integral part of the software development lifecycle process. It helps in scaling the SDLC process and further improving it. That is why automation testing is one of the emerging fields today. I think people who’ve done computer science or studied computer science or are programmers, when they see something or task that takes five minutes, I think we all ask, “Can it be automated?” When it comes to automation testing, there is something that we need to be cognizant of. What is it that we are automating? How much time are we saving? We can automate a five-minute task, but will it give a considerable return on investment (ROI)?

Our programmer instinct says, let’s automate everything. Some things sometimes take less time or an equal amount of time with manual effort. We need to critically analyze which parts of an application needs to be automated before we jump into automating something. When people learn automation testing, the focus initially is always on how to automate. Many times I’ve seen people skip the part about what to automate. What to automate always comes before how to automate and is equally important. The thing that happens when you write an automation script. It also interacts with the application you are testing in the way you would have interacted. You script that into your code. When a human uses an application, the human experience is very different when the interaction happens between a script and an application and a human and an application.

Like humans interact with each other in different ways, different humans also interact with applications differently. An automation script cannot always cover all the ways and perspectives different humans may interact with an application. This is why we must understand the requirement from the business side that needs to be automated. Once the requirement is clear, we need to develop an automation strategy. An automation strategy as in which are the critical workflows? What is the data that needs to be taken into consideration? Such things need to be thought out well ahead of time before you start writing your automation script. Third, calculate the return on investment of your automation. Is it very repetitive? How much time and how much cost is it going to save? Is it a workflow that you see in future sprints? Suppose you’re working on a project and you follow Agile. You may be following the sprints where you have a regression suite that you need to execute every sprint. In such cases, you need to consider the automation coverage of the application and how much of it is repetitive or if it is a very important heavy workflow that saves considerable cost.

The ROI needs to be calculated before zeroing down on what needs to be automated. An open-source survey interviewed different project groups, and it was found that 40% of the people were using automation scripts that were very frequently linked with Agile methodologies. 37% frequently used CI/CD or continuous integration, continuous delivery, and CI/CD pipelines. 10% said that in their projects, automation was only done in a scheduled manner when needed on a need-for basis. 9% said only when certain issues arose would they automate something. 4% said they never used automation. The automation coverage is vast and expansive. Knowing automation, knowing what to automate, and writing automation scripts is an in-demand skills. We also hear that automated testing will slowly replace the manual testing job.

The most popular implementation type of automation is regression testing. 90% of the automation suites are linked with regression testing. Regression is workflows that are repetitive in nature, things that come up every time you need to execute that. Automation helps save time and effort and gives you proper accurate results as well. Next, we have repeated test executions that are also automated, and then performance testing, load testing. This is done mainly for APIs if they are working under heavy load or a lot of users come and start using the application. We have a different set of tools for performance testing. We have tools like Apache, JMeter, or LoadRunner.

These are the main areas in which automation is done in our software project. Knowledge of a programming language is a must have when it comes to automation testing. Knowing the automation concepts is also essential. There are Chrome extensions and tools where you can quickly record tests. You don’t need to know a programming language, but what happens in those cases they have its drawbacks. You can’t customize them for your needs. To correctly automate whatever you need and to have the freedom while automating something, you must know a programming language. The next point is very well-versed in functional testing. You can be good at automation testing, but you must be great at manual testing. You need to know the end-to-end workflows, edge cases, how the application would behave under different scenarios, and things we learned in data structures in college about decision trees and boundary conditions.

Those concepts we learned come into use when you’re writing your automation scripts. These are things that we need to be careful about and cognizant of and apply these techniques, like finding out edge boundary conditions. These are the responsibilities of the person writing the automation script, and only when they know the application in and out can they frame their automation script in a way. Then the automation script is poetry when you understand the application to that level. Customizable scripts use a tool or framework and write from scratch. There are available Chrome extensions, but they come with their limitations. When you’re using your scripts, you can customize them. In the software development lifecycle process, the client’s requirements change from time to time. When you have your scripts, and you clearly understand how and what they do, you can make changes to it as per your needs and validate things that would otherwise become very difficult. You can’t validate everything you wish to with such quick testing tools.

The automation testing market is an ever-growing market. It is increasing year on year. It is in demand, and it is a must-have skill. In the software industry, the tools change, syntax changes, and things get replaced every five years. The basic concepts remain the same. It is good to know what the latest tools are coming in, which features they have, and if and when you may need to switch. If your base is clear about how and what you should automate, then switching to a different tool would not be a major problem.

As programmers, we jump to writing code when given a problem statement. It is very important that we are clear on what the exact requirement of the business is. There can be different workflows to an application. People interact with applications in very different ways. It would be best if you discussed with your team and the stakeholders to decide which workflows need to be automated. Inform them about the possible dependencies or what automation testing can miss. It would be best if you clarified what your automation test covers and what it does not. Such things need to be discussed before the automation scripts are written, also to analyze and mitigate the risk in the first place. Identify the regression cases and inform them about automation’s value add and the merits and demerits of having versus not having automation. Such discussions, such feedback loops need to be introduced within the team. That way when you’re doing automation tests, your job is not restricted just to the automation tests. It is understanding the requirements and communicating them properly. All these fall under the responsibilities of someone writing automation scripts.

When we write automation scripts, human error is reduced. We deliver quality software products and increase release velocity through CI/CD. In almost all projects, CI/CD is also DevOps. Knowing DevOps is an important skill. Writing automation scripts alone won’t do, but maintaining them and the releases through CI/CD is also important. Then CI/CD means continuous integration and continuous delivery. If you’re automating something, you don’t have to recruit another human resource, which saves cost. It ensures faster time to market. The last point that is a must-have for automation testing is good reporting. Someone who doesn’t understand software engineering terms should also understand what the report is saying, where the test cases have passed, what has failed, and why it has failed. All that needs to be clearly reported. Remember, when you’re writing the script, that the person reading the script has not written your code. You have to print proper lines when you’re reporting so that the reporting is done properly. That also helps in further maintaining the scripts.

There are mainly two types of applications. One is workflow intensive, and another a data-intensive application. Applications that deal with a lot of data and applications that have many workflows in them. Depending on the type of application you’re using, you should decide which automation tool you should be using. In your learning automation, don’t focus on learning a particular tool or technology. First, know what it is that you are automating. Based on that, you have to choose your particular tool or application. You need to understand what the application does and deals with. These are just broad classifications, but if you go more into it, there are linear automation frameworks. If it’s just one single flow, then you have modular applications. If you have different modules within your project and each module needs to be separately automated, you have library architecture frameworks. This is where different modules together can be integrated and simultaneously run. You also have data driven frameworks and hybrid frameworks, which can be a combination of one or more. Automation frameworks are a platform where you have all libraries and all tools in one place in a structured way. It makes it very easy for our developer or a tester to use particular functions, et cetera, and invoke them in their code. When you use an automation framework, the maintenance is much easier because you have to upgrade the framework and the particular libraries and other dependencies also get upgraded.

You can scale your automation tests. You can also run parallel tests. Then reusability of code, if you have components that can be reused, the frameworks make them much easier to reuse. Selenium is the most traditional and most popular framework because it has large language support from Java to C-sharp, to JavaScript, to Ruby, to Python. It is portable and supports cross-browser testing across different browsers like Chrome, Mozilla, or Edge. Selenium has something called Selenium IDE that comes as a Chrome extension where you can record your tests. But for more intensive testing, there is also Selenium Webdriver, which can work with any of these programming languages. You can set it up with Java. You can set it up, and then within each of them, you have more libraries and tools.

You can use TestNG for working with Excel sheets, writing things, taking things from your application, extracting things from web elements, and writing them to Excel sheets and reporting them. Developers can use NUnits to do unit testing. There are some more libraries and tools available within that. Then there are other frameworks like WebdriverIO, which supports both browsings across mobile as well as web applications. It’s also easy to learn. You have another tool called Cypress, which supports the parallelization of tests. Another very good feature of Cypress is that it allows taking automatic screenshots. Whenever your test fails somewhere, the Cypress application automatically takes a screenshot at the point of failure, which makes reporting much easier. Some other quick testing tools are Cucumber, APM, Serenity, and TestCafe. These are all testing frameworks.