The purpose of testing is to ensure that an application behaves according to its specifications; quality is assumed but not guaranteed without testing. To fulfill this goal, we create tests at various degrees of granularity, including unit, integration, and system tests. While tests at these levels are essential and aid in investigating the root cause of bugs, only one testing approach ensures the user experiences our application as intended: end-to-end (E2E) testing. E2E testing is not a level, but a technique, that guarantees that we exercise the system from start to finish in the same manner a user would experience our application. This principle can be extended over multiple applications to exercise an entire business process as well.

E2E tests are often neglected, due in large part to the effort required to implement them. In many cases, E2E tests are performed by hand, which can be a tedious and error-prone task. Automation solves many of these problems by ensuring a consistent, production-like test coverage of the system. Even with automation, though, non-technical personnel are often the most interested in E2E tests — but writing the code necessary to implement E2E tests can be a daunting challenge. No-code E2E testing can bridge this gap by allowing non-developers to reap the benefits of automated testing by creating repeatable E2E tests and recording workflows from the perspective of the user. Before diving into no-code E2E testing, we must first understand the fundamentals of E2E and test automation.

This is a preview of the End-to-End Testing Automation Essentials Refcard. To read the entire Refcard, please download the PDF from the link above.

Software testing can be broken up into different levels of granularity — called phases — where each phase focuses on a specific scope:

1. Unit: Tests individual units — such as classes and methods — in isolation
2. Integration: Tests the interaction between units and components, ensuring that unit interfaces behave as expected
3. System: Tests the entire system, usually mocking external services, such as databases and third-party services
4. Acceptance: Tests the use cases of the application and ensures that the entire application meets the needs of stakeholders

This is a preview of the End-to-End Testing Automation Essentials Refcard. To read the entire Refcard, please download the PDF from the link above.

Years ago, a majority of the E2E application testing was performed manually, with a QA tester using the application and recording the results. In the age of modern software development, this is no longer tenable, and automation has become a foundational part of testing. While automation does solve many problems with manual testing, it does have its own drawbacks. To combat these shortcomings, we can utilize no-code testing to further alleviate the effort required to create E2E tests and ensure sufficient E2E tests are created to exercise our applications.

No-Code E2E Testing 

One of the major drawbacks to creating automated E2E tests in this fashion is the amount of code that we need to create to implement our features. In many cases, the people most interested in E2E tests are not developers (i.e., those with knowledge of or interest in code). Instead, it is often business-level stakeholders — such as customers, business executives, or sales personnel — that are most interested in creating and viewing the results of E2E tests.

While the text-based representation of our Gherkin features helps reduce the technical nature of our tests, they still require code to implement features. Additionally, users will not be executing our application using a text file as the input. Instead, they will be executing actions through a UI or other external interface. Thus, there is still a disconnect between how the test cases are captured and how an actual user will utilize our application.

The solution to this problem is no-code testing. No-code testing is an approach where test code is generated automatically based on a series of captured steps. For example, if a salesperson wants to ensure that removing an item from the cart and then checking out does not result in the removed item being purchased, they can use a no-code tool to capture the steps needed in the UI to remove the item and then checkout. The salesperson can then add a requirement that the removed item is not purchased.

Consequently, the no-code tool will record the actions executed by the salesperson in the UI as a set of discrete, ordered steps. Some tools may even allow the steps to be altered or reordered. Additionally, the test case requirements — such as the removed item not being purchased — will be recorded as a set of postconditions. When the no-code tool executes the test case, it simply executes the set of ordered steps and checks the results against our recorded postconditions. If all the postconditions are satisfied, the test case passes. Often, the set of steps and postconditions are visually represented in a UI, which allows us to categorize and browse test cases and view the steps and postconditions for individual test cases.

The major benefit of this no-code approach is that a tester — in this case, a salesperson — can use the application in the same way a user would in production. Unlike code-based testing, there is no chasm between how tests are recorded and how the user will use the application in production.

One of the previous drawbacks to no-code automated testing is test fragility. For example, if the salesperson clicked the Checkout button on the UI of our application, the no-code tool would need to record this button press. If the tool recorded this button press using the position of the button (i.e., executes a click at location X and Y on the visible screen), moving the button in future releases could cause the test to fail, since the button will no longer be located at the same X and Y coordinate on the screen — or worse, a different button or link may now be located in the same position.

As no-code testing tools have matured, these problems have been greatly reduced. Instead of recording the location of the button, the tool will usually record the ID of the button. For example, if the UI uses Hypertext Markup Language (HTML), the div id of the button may be recorded. So long as the id does not change, the button can be moved to any location on the screen and the tool will still know to click the desired button by its id when executing the test.

This is a preview of the End-to-End Testing Automation Essentials Refcard. To read the entire Refcard, please download the PDF from the link above.

E2E testing is an essential part of any serious application, but the effort required to implement E2E tests often results in insufficient tests. Automated E2E testing (using frameworks such as JUnit and Cucumber) and automated deployment (using Docker and Kubernetes) go a long way in removing the burden of E2E testing, but there are still drawbacks to these approaches. Namely, writing code.

Often, the stakeholders most interested in E2E tests are those least interested in code. Using no-code E2E automated tests, we can bridge this gap and allow non-developers to create repeatable, useful tests in the same manner that customers will use our application in production. This ensures that we not only test our applications in the same way that customers will use it, but also, the testing process includes all the interested stakeholders, earning increased confidence in our application and, ultimately, increased buy-in.

This is a preview of the End-to-End Testing Automation Essentials Refcard. To read the entire Refcard, please download the PDF from the link above.