I like the idea of a bright future, but we need to know the necessity of those changes through history and understand better where we are going in terms of new ideas. If you know the Test Automation landscape before, it could be easy to identify those slight differences and positively reshape your current Automation landscape. In this article, we’ll look at the software testing evolution that shaped the future of test automation.
What is Test Automation?
Test Automation can be defined as a practice in software testing that leverages automation tools or test automation frameworks to manage the execution of tests instead of a human tester. It compares actual test results with expected results translated as assertions inside of our test scripts. As a result, automated Testing provides great effectiveness and faster results.
Test automation can be considered critical for continuous delivery and continuous testing.
Test Automation in the late 90s
Back in that time, we had one Testing strategy for all circumstances, adapting sometimes depending on the company. Talking about Testing tools, we used spreadsheets, HPQC, Rational, and in-house test management tools.
For the lucky ones exploring automating test cases, we had SQA, Mercury, and Segue dominating the automation landscape ( 25+ years ago), Selenium appeared in 2004. Still, it required some years for some companies to adopt it (For those interested in history, SQA was acquired by Rational Software, and later on, IBM acquired Rational. HP acquired Mercury Interactive. Segue branded its toolset under the Silk banner, and the company was acquired by Borland, which was, in turn, acquired by MicroFocus).
“We can follow the evolution of software test engineering by examining changes in the test processing model and level of professionalism over the years. The current definition of a good software testing practice involves a preventive methodology.”— William C. Hetzel
Many early adopters attempted to apply automation to applications under development, not exactly the most stable of platforms. As a result, they spent more time developing and maintaining automated test scripts than they did testing software.
Why does the necessity for test automation arise?
In terms of traditional software development, testing is completed at the end of a development cycle. However, in today’s software landscape, we see more companies moving to a continuous delivery model. As a result, the software is constantly in development and must always be deployed continuously. That’s where continuous testing comes in to ensure quality at every stage.
Ensuring high quality is the most crucial part of this continuous testing model. The speed at which development and testing also occur matters if something fails; it slows down the release of new products/features. Test automation can help save time and manage those testing needs, including the different tests covered and optimizing testing activities to deliver faster.
Automation testing is a game-changer; the ability to run many test cases automatically and conduct so many validations makes it a critical weapon for any QA Engineer. Although automation is here to help testers focus on other activities such as Exploratory testing or creating efficient test cases, the intention is not to replace testers. Instead, we need to consider it a powerful ally during our agile testing.
The rise of Test automation tools and frameworks
While reading this blog post, you probably wonder if your current test suite is a test framework, a testing tool, or perhaps a library. In pragmatic terms, the important thing is understanding the different options and using the best one to fit our current test automation needs.
Huggins started showing “the test tool” to several co-workers. Many were amazed about its fast and intuitive visual feedback and its potential as a reusable open-source “testing framework” for other web applications; as you can see, Selenium started as a tool as many existing frameworks. In terms of the proper definition, Selenium is primarily a framework for automating web applications for testing purposes but not limited to just that, compelled by Selenium Webdriver, Selenium IDE, and Selenium Grid; it is one the most popular for web automation.
Selenium WebDriver –
the heart of Selenium uses browser automation APIs provided by browser vendors to control the browser and run tests. It is as if a real user is operating the browser. Since WebDriver does not require its API to be compiled with application code, it is not intrusive. Hence, you are testing the same application which you push live.
Selenium IDE –
IDE stands for Integrated Development Environment; It’s an easy-to-use Chrome and Firefox extension and is generally the most efficient way to build test cases faster. In addition, it records the users’ actions in the browser for you, using existing Selenium commands, with parameters determined by the context of that component. Thus, it is not only a time-saver but also an excellent way of learning Selenium script syntax.
Selenium Grid –
The parallelism of Automation allows you to test in different machines across different platforms. Able to run tests in parallel on multiple machines and manage different browser versions and browser configurations centrally (instead of in each test).
We explored the past, but what about Selenium in the present? A couple of weeks ago, in blog post time, we had a new release, Selenium 4.0, including many new features and improvements; let me say this, a new fresh look was necessary, kudos Selenium.
Appium is another example of resilience; if you do not know the story, Dan Cuellar’s geniality about fixing the challenge of running the UIAutomation framework working for his project was the precursor of the Appium open source project. Thanks to Jason Huggins for encouraging Dan to release and contribute to the initial stages of the project, Appium began to grow and mature significantly. In May 2014, Appium 1.0 was released, which stood as a milestone in Appium’s development. Appium became the most popular open-source, cross-platform mobile automation framework.
Appium is denominated as cross-platform; it allows you to write tests against multiple platforms (iOS, Android, Windows) using the same API. In addition, it enables code reuse between iOS, Android, and Windows test suites. Appium incorporates vendor-provided frameworks such as XCUITest, UIAutomation, UIAutomator, WinAppDriver in one single API similar to Selenium WebDriver; it is easy for us to use the “automation libraries” and manage our test any way we like.
For those not familiar with BDD, let me give you a phrase I like referring to BDD “User Stories in Simple Sentences keeping our tests focalized.” I do not intend to oversimplify it, but if you cannot explain the concept in simple words, perhaps we need to remove complexity. BDD is a software development process including collaboration, exploration, and discovery between Technical people and business people. Related to Cucumber, Aslak Hellesøy was the leading mind behind this open-source project; Hellesøy had experience working with the Rspec project, but he wanted a BDD framework for everyone, including non-coding stakeholders.
We know a bit of BDD, but what is Cucumber? Cucumber is a cross-platform that reads executable specifications written in plain text and validates that the software does what those specifications say. The specifications consist of multiple examples or scenarios. Then, Cucumber verifies that the software conforms with the specification and generates a test report indicating the status of every scenario. Cucumber uses Gherkin grammar rules to pursue these validations that make simple text structures (Given, When, Then) for Cucumber to know the scenarios.
It is relevant for us as Automation Engineers to know Cucumber better; we can always translate our test scripts into BDD using Gherkin and Cucumber.
We have seen a lot of changes in the world of software testing; low-code automation (We have a variation of codeless automation tools) has grown in popularity in recent years. It can help with many challenges with test automation; some low-code/codeless automation tools include AI and machine learning self-healing mechanisms to enhance test stability and save maintenance time and cost.
credits: Forbes 2021 State of Test Automation Report
We know AI and Machine Learning are the hottest topics at this moment. Still, ML and AI have been there for many years, so what changed? First, the increase of cheap computation has driven the plenty of data we are collecting—the increase in the capability of machine learning methods. Lastly, AI and ML have matured both in terms of identity, techniques, and tools.
We previously explored test frameworks, so can I incorporate ML into my test automation ecosystem using an open-source framework? The short answer is yes. But keep in mind different factors such as hiring the data engineers and data scientists to help with the design and implementation; it could be a long and costly process.
If you want to try low-code/codeless, you probably wonder the best fit for your current project. Should I go for Low code Testing tools? Or codeless, well, both have the same goal, optimize Automation and save time, but let’s go deeper. Low-code testing tools, as the name implies, help write stable code in less time and adjust the test scripts using intelligent visual editors. Some Automation Engineers love to write code; if you are planning to move to low-code/codeless alternatives in your company, perhaps you must consider low-code for them. If you go with low-code, the change can be accepted than the codeless tools.
Codeless testing tools simplify UI testing with functionality that doesn’t require the user to write any code; The user or the ML model records a test scenario, and then adjustments to the test can be performed in a visual editor to complete the test. ACCELQ can provide this functionality and more as it incorporates Web, API, Mobile, and Packaged Apps on the same platform.
Benefits and challenges in Automation Testing
Automation testing can be a valuable ally during our Agile Testing; always keep looking for opportunities to save time or challenges while doing functional Testing. Automated Testing is the process of performing software testing activities using Automation Tools or Test Frameworks with no human interaction. This helps to achieve higher speed and efficiency. So basically, these Automation tools can be code, low-code or codeless.
“Automation Testing without a clear Automation strategy may result in a lot of activities but little or null value to your customers.”
Now, let’s talk about some challenges identified in Automation Testing:
Selecting the right Testing Tool or Test Framework –
Choosing the right automation tool could be as hard as choosing the right test automation strategy; codeless tools are more capable and autonomous than before. In addition, integrating the software into existing CI/CD pipelines attracts more practitioners. Moreover, significantly adopts the technology to decrease test automation maintenance and reliability costs.
Running automated tests too soon –
An essential aspect of continuous Testing is testing early, but what about when the applications under test are not ready, and we want to start designing our test scripts. Creating test scripts from day one will waste much time shooting at a moving target. Avoid waste of time and focus on your Automation strategy first.
Over Automation can kill your project –
Avoid the temptation of automated everything or the fallacy of 100% test automation coverage. Instead, Automation must focus on repetitive/tedious tasks and risk-based scenarios.
Lack of skilled Resources – Perhaps, this is not your case. Still, many companies are struggling to hire Automation Engineers; they constantly ask if there are sufficient Automation resources or training their current Functional Testers. My recommendation is to try with some low-code/codeless tools if you can’t hire.
Understanding the cost of Automation Testing:
Test Automation can help us speed up our test activities; still, we must understand different aspects like cost of automating, time constraint of the project or the sprints, resources available, and other factors. Also, keep in mind other options such as Exploratory Testing, Mob Testing, Pair Testing, and most importantly, don’t automate tasks that will not add value.
Test Automation is a necessity in today’s Agile environments. Whether you work for a tech company or a highly regulated government entity, as we mentioned initially, I prefer the dreams of the future to the history of the past. Still, we need to know the past to reshape our present and future. It does not matter if you use an open-source Test framework or some codeless testing tools. The idea is to perform Test Automation smarter.
Happy Bug Hunting!
Enrique DeCoss | Senior Quality Assurance Manager | FICO