Share on email
Share on twitter
Share on skype
Share on facebook
By Jeppe Resen Amossen
November 27, 2020
By Jeppe Resen Amossen
November 27, 2020
At Pharma IT, we have extensive experience with the use of tools for automated testing of user interfaces, and we would like to introduce you to 3 capable tools – tools that present different approaches to the task of creating and maintaining automated UI tests. The tools are
TestComplete, LEAPWORK and ACCELQ are all codeless or no-code tools, meaning that automated tests can be built without requiring any coding or scripting experience. Instead, scripts are created automatically by recording user actions on screen or by interacting with the graphical user interface (GUI) of the tool. The tools are capable of both methods, and have the option to execute snippets of custom code as a part of tests.
Furthermore, all of the tools are capable of testing web applications, web services, as well as desktop applications. Specifically for SAP, however, the LEAPWORK tool is especially capable, due to its dedicated feature set for handling SAP.
With regards to collection of evidence, the tools use different strategies, but all of the tools let you review scripts, logs, and evidence collected in a step-by-step fashion.
Finally, the tools are all capable of integration with software used in Continuous Integration (CI)/Continuous Deployment (CD) through API calls.
The most noticeable difference between the tools is the way the automation scripts are presented to the user. See the summary of the approaches below:
The TestComplete user interface can, on the surface, appear a little daunting, but the thinking behind it is very straight-forward: Scripts are executed line-by-line from top to bottom.
There are no arrows to connect or screens to capture – just line-by-line execution. This means that simple tests are extremely fast to set up, but this also means that the tool does not assist the user as much when setting up complex tests and maintaining a large suite of tests as the other tools (LEAPWORK and ACCELQ) in this comparison. Instead, TestComplete presents us with no-nonsense automation that works in a straight-forward manner. In this way, TestComplete is very well-suited for quick creation of small, discrete tests.
As the test is executed, screenshots are captured immediately before each step and can be compared with a baseline image that has been previously recorded.
LEAPWORK uses a blueprint methodology to visualize the test script. The script is created on a canvas onto which functional blocks with various functions (such as “click on this”/”read data from Excel”/”validate against that”) are placed. The blocks can have inputs, outputs, and inner logic that can be configured in the block. The order of execution is determined by connecting green arrows while the data can flow from block to block using blue arrows:
The concept of LEAPWORK is especially appealing for those of us who think visually, as well as for complex test cases and scenarios where the flow of actions and flow of data may otherwise be hard to follow.
As the test is executed, a video is recorded. This is highly useful for debugging purposes. Furthermore, screenshots may be captured in addition to the video if required for documentation.
ACCELQ takes a radically different approach to UI Test Automation by focusing more holistically on the long-term testing experience. For this reason, ACCELQ requires a little more explanation, and it may seem overly complex at first. There are, however, some benefits to be had with the more elaborate approach of ACCELQ.
Instead of approaching a test as a series of user input, logic and validations, a “universe” is built from contexts (think: “login screen”/”user start page”/etc.) that are recorded and used as static assets when defining the actions that can be performed on them. Since the same context may contain different elements at different stages, multiple views can be recorded of the same context to capture all desired elements.
Examples of actions could be a small set of steps that constitute a meaningful business operation. Examples are: “login”, “click on link”, or any validation activity. The action script definitions are presented to the user like the wording of a step-by-step description – just like what would be used in a manual test. In addition, an action also specifies the context(s) from which the action is valid, as well as to whether the action leads the user to another context. Below you will find an example of an action definition:
In ACCELQ, tests are defined by specifying the starting point (a context) followed by specifying a list of actions to perform with appropriate input parameters. At this point, tests are a breeze to define since the tool has already gathered information on: (1) which actions are available in each context, and (2) what context each action transfers the user to as well as what parameters are needed in the process. The test scripts are presented in plain English using the names of the actions in the text and the names of the contexts in the right-hand column:
Why this approach? One important advantage is that the ACCELQ-approach defaults to reusing any existing object identification strategy and action instead of relying on discipline on the test creator’s part to achieve efficiency. Re-use of actions and object identification strategies is important in order to keep test maintenance levels at an acceptable level. This is because the number of actions and objects expand over time and if, say, a login button is changed, you would rather want to fix it once than fix it in every test in which the button is used.
As a bonus to the ACCELQ approach, an interactive map (“universe”) is drawn from the defined tests. This map visualizes the contexts and actions included in the test suite. This provides a visual map of the test coverage.
Since the benefits of the holistic ACCELQ-approach comes with a cost, the ACCELQ-approach is best suited for cases where the complexity of actions is limited and the need for reuse of object identification strategies or actions is high.
In ACCELQ, the evidence collected by default is a series of screenshots together with the log.
In addition to the three tools mentioned in this insight, two other tools deserve mention as they have very specific strengths. The first is TestIM – an excellent tool for testing web-applications. Due to its strong utility of AI, TestIM is quite resilient to change and may be particularly well suited in situations where the application in question is expected to undergo significant changes after the test has been designed. The second additional tool worth mentioning is Applitools, which is a highly capable tool dedicated to visual testing. Applitools may, for this reason, be a good candidate to strengthen the visual testing capabilities of another tool.
A variety of approaches exist for building and maintaining automated UI tests. The question of which approach and tool is best suited for a particular context does not only depend on the preference of test designers, but also largely depends on the needs and nature of the application(s) and the particular setting in which the tool will be used.
Choosing the right tool for your context is an important part of forming your test automation strategy seeing as a well-picked tool can have a high impact on both the initiation and overall maintenance cost of an application. To learn more about how Pharma IT can assist you in your automation, visit our subsite for UI test automation.
Jeppe Resen Amossen is a senior consultant specialized in project management, test automation, and Agile methodologies.