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.
