This post is from the Experitest blog and has not been updated since the original publish date.
How to Use Codeless Automation to Turn Your Testers into Automation Testers
We have entered a period where every company is now a technology company. Business environments are constantly driven by connectivity, artificial intelligence, and automation. As a result, technology has become central to how companies operate and create sustainable competitive advantages. Today, the giants of the corporate world (in terms of market capitalization) are primarily technology companies — Amazon, Apple, Alphabet (Google), Microsoft, and Facebook to name a few. What's even more interesting is that as technology evolves and brings innovative solutions within the reach of businesses across industries, companies as varied as Walmart, JPMorgan Chase, Bank of America, Novartis, Exxon, and GE are on the way to becoming technology companies, too. It led to the development of codeless automation practices that can turn any tester into an automation tester.
Every business strives for increased revenue and better customer experiences as their top business priorities. And web and mobile applications are at the heart of those strategic goals. According to research carried out by Forrester in 2017, application development and delivery priorities strive for a 30% improvement in mobile customer experience, 43% improvement in online customer experience and 19% improvement in commercialization speeds of new products. These operational objectives closely tie to the business objectives organizations pursue. This comes in the form of increased revenue and improved customer experiences.
Testing bottlenecks and need for faster delivery
Over the last decade, application development has undergone a paradigm shift. Development environments now favor speed, agility, and risk reduction. The introduction of Agile, DevOps, and CI/CD (Continuous Integration Continuous Delivery) approaches have blended application development and deployment into a more streamlined process. Development and operations team are more tightly integrated and work across the entire application lifecycle. This ensures a faster and more continuous cycle of code creation and delivery. This helps companies innovate and improve products faster.
With these cutting-edge approaches in place, the application development process still encounters delays in some key areas such as testing. According to a Gitlab survey conducted in 2018, testing appears to be responsible for 52% of the delays in application delivery. That far outnumbers all other steps in the development process. The development process is becoming more agile and code production happens in short cycles through a continuous delivery approach. Growing in tandem is the need for various types of testing (including regression tests, component tests, unit tests, functional acceptance test, etc.). As a result, there arises a bottleneck from the need to run more tests in a shorter period of time.
Need for more automation
Manual testing is slow, expensive, and generally unreliable. Therefore, it contributes to the bottleneck that prevents organizations from releasing products more frequently. Automation is a viable alternative that addresses our growing needs for rapid deployment and delivery in the development process. But the drive for automation apparently requires some structural changes. For instance, one of our North American clients is a financial institute that currently employs 60% of its QA team on manual testing. Their envisioned plan is to let automation testers and software engineers take over and fill up the manual testing space. The question, however, is, how to achieve this level of automation without gutting the existing team?
Increasing team automation
Have your most valuable employees work on tasks that they are best suited for. You will need employees with different and unique skill sets to what you currently have. It is more satisfying to employ people where their knowledge and creativity are most needed. Employees with valuable domain knowledge and organizational expertise can acquire cross-functional skills better than those without these merits. Those employees are then all the more relevant for organizations to retain. In addition, the demand for test automation engineers have been constantly increasing in R&D and IT job category (from below 2% in 2010 to more than 6% in 2018), opening opportunities for manual testers to gear up for the new role within their organizations.
Codeless automation with BDD
Behavior-driven development focuses on helping product teams validate and test their applications to function as expected. Contrary to what we find in standard functional testing which includes hard-to-test codes. BDD tests utilize test cases written by changing the way that testers write test codes. First, you define the test, then you write the code that will pass it. So, understanding them doesn't require one to be an engineer or a person of technically-driven abilities. Typically, developing a codeless automation environment based on BDD principles starts with writing feature acceptance test.
This is the process where the entire team, including business analysts, developers, and testers, come together.
They then map out a design that specifies the key features based on user story scenarios. Once testers record these scenarios in a ubiquitous language (such as Gherkin), they become valid as feature acceptance tests. It is that first step of creating test cases in this ubiquitous language that allows for non-coders to enter the conversation and begin writing their own codeless automation tests.
Assuming that Cucumber is your BDD automation tool of choice. Here is a description of the roles involved in the deployment of codeless automation tests.
Scrum Team: Business analysts, developers, and testers comprise this team and work together to study user scenarios, define behavior in ubiquitous language, and create feature files.
Testers: Who write the feature files provided by the scrum team in a plain-text language using Gherkin syntax.
Developers: After the writing of feature files in Gherkin syntax, developers take on the coding process and start coding these features using specific programming languages.
Automation Engineers: These are individuals who are responsible to create step definitions for every feature in the features file. Basically, automation engineers describe how the steps they created will take place in the testing.
Automation project/Continuous testing: Is where automation testers and developers get feedback on the changes they make to help them improve app quality with automation testing.
How it all adds up to codeless automation
Using this method, companies need automation engineers to write the step definitions. Step definitions are usually written in a more established programming language, such as Java or Ruby. They are created once and can be reused. Once the Scrum team agrees upon the test cases, testers can use Gherkin or another ubiquitous language to write use cases. Testers then create more use cases and scenarios using the existing step definitions. Logging into an application is an example of a scenario that a tester may write a test for in Gherkin.
The test is then executed on a real remote device like the devices you would find in the SeeTest Digital assurance lab. The tools that testers can use for codeless automation include Cucumber, and Appium Studio for Eclipse. Cucumber, as we mentioned above, is a software tool that is used to test other software. Using the BDD approach to writing automated acceptance tests, cucumber then runs the tests. Gherkin, is a plain language parser, that is central to the Cucumber BDD approach. Automation engineers also use Appium Studio for Eclipse and the SeeTest Digital assurance lab to write the step definitions.
How we write codeless automation tests
Write codeless automation tests with a feature file using the Gherkin keywords. At this point, the automation engineers have already pre-configured the step definitions. With the step definitions pre-configured, testers have all the necessary tools to start writing tests. Automation makes it even easier for the testers to write the scenarios. Once the scenario has been written in the form of a feature file, the scenario is run through a test runner class. Since the tests are run on real devices, it is important to ensure a device is available.
After running the feature through the test runner class, the test execution will be visible on the SeeTest Cloud platform. Testers can open the device in a new tab, for a deeper look at the execution. Once the tests are complete, the tester can see the results, the tags associated with the test, and the screenshots for each step of the test.
Codeless automation testing is the way forward. Not only because it helps overcome the inherent issues in automated testing but, more importantly, because of the role it plays in enabling quality. Quality assurance is the bottleneck DevOps practitioners today are trying to untangle in the development process. The time-consuming, error-prone, and costly manual testing only adds to the problem than offer any viable solution. While that is true manual testing is not going anywhere. Rather, testing is moving towards more intelligent exploratory testing. As software and web applications grow in complexity, codeless automation testing arms testers with automation tools that make their tasks easier; removing the need for a full-blown software engineer and making the maintenance and sustainability of applications easier for business teams and manual testers.