Gaining Speed Yet Losing Altitude - S1:E3

Monday, October 25, 2021

S1:E3 - Test Tooling

For many organisations a continuous flow of application updates is crucial. This requires super-fast software development that addresses customer demand immediately. Low-code platforms are making this a reality for more and more organizations and applications. However, the speed of low-code development requires, even more than 'before', adequate QA and test solutions. The faster your figurative low-code plane flies, the more important it is to take the right measures so as not to lose altitude.

In this series Gaining Speed Yet Losing Altitude we discuss a low-code quality challenge and the measures you can take.

'Testing is the bottleneck'

Organizations that use Low-Code platforms for their software development often run into the problem that testers cannot keep up with the speed of developers. With Low-Code, new software is developed faster and changes to existing software happen more frequently. In these cases we often hear that 'testing is the bottleneck of the release cycle'.

Ask yourself the following questions:

  1. Are your development teams taking more and more time to release new functionality?
  2. Do you spend more time keeping your current test sets up-and-running than building new scripts?
  3. Do you have concerns about the risk coverage and maintainability of your test sets?

Then there probably is a mismatch between your 'software development tooling' and 'test tooling'.

IT objectives

Your organization has chosen software development with Low-Code platforms for certain reasons. For example, the desire to:

  1. Be able to respond faster to changing demands of the market
  2. Get the business more involved in software development
  3. Reduce the risk of technical dependencies (expertise)

Often these reasons come from experiences with traditional, regular code solutions that failed to meet these needs. What is often forgotten however, is to include test tooling directly in this consideration.

Critical Succes Factors for Test Automation

A successful implementation of test automation generally has the following 3 critical success factors:

  1. Type of application landscape: Not every tool can handle all types of applications.
  2. Required speed of delivery of test scripts: Not every tool allows you to immediately start building/modifying scripts. Sometimes a framework has to be built/modified first.
  3. Team composition: Some tools require more technical knowledge than others. A technical team can provide better support for a technical tool.

For Low-Code, the type of application landscape is clear. In this case it is an html application and (probably) all kinds of integrations with other systems via web services.

The required speed is high. Several studies by OutSystems show that with OutSystems, 82% of the 2,200 IT Professionals surveyed, indicate that they have their application in production within 6 months. In addition, Low-Code offers the possibility to quickly make changes to previously built software. If you’re not able to change your test scripts as fast as the developers change software, you’ll easily run out of sync. As a result, you can no longer guarantee the desired risk coverage.

Finally, in the team composition within Low-Code, a conscious decision was made to be less dependent on the scarce Java, .Net and/or C# developers. This means that you can hardly rely on their expertise if you use a testing tool that requires Java knowledge, for example.

The Common Mistake: Testing Low-Code with High-Code Tooling

The IT objectives mentioned above do not only relate to software development, but also to test tooling. Software testing must be in line with software development. This is often overlooked. Especially the team composition I mentioned earlier has a major impact on this.

In addition, technical frameworks are not suitable for the high frequency of changes in the code. One of the most frequently cited reasons for a failing implementation of test automation is the poor maintainability of the test scripts. Just as Low-Code makes it easier to make changes to software, a tester needs to have similar tools to keep everything up-to-date. Here, you do not want to be dependent on technical (scarce) expertise either.

But are you really Low-Code?

More and more test tools claim to be Low-Code. These tools often use libraries that you can refer to, to automate tests. Within these tools, some form of scripting is still necessary before you can use these libraries. Please keep a close eye on what steps are needed to automate a test. It will then soon become clear whether a programming language is actually involved or not.

Test Low-Code with Low-Code

Looking at the critical success factors mentioned earlier, it is actually quite simple: you want to test Low-Code applications with Low-Code test tooling.

Valori often struggled with the same challenge. Our experts helped dozens of customers build technical frameworks for test automation. We quickly noticed that we were always solving the same problems and that these customers also became dependent on the knowledge of our experts. The adoption of these frameworks was subsequently a major challenge for these customers.

JOSF: a future-proof base via Low-Code

We have bundled these learning points in our Low-Code Automation Framework JOSF. JOSF stands for Java Object Selenium Framework. It uses Selenium APIs to steer browsers and uses REST-Assured to steer APIs. This gives JOSF a widely supported, future-proof base.

JOSF responds to the need of a Low-Code organization

The user of JOSF does not need any technical skills to be able to automate tests. This responds to the IT objective of being less dependent on technical knowledge.

In addition, JOSF offers two options for involving the business in test automation. Firstly, via Gherkin scenarios (Given…When…Then) that can be described by the business and they can import into JOSF. Secondly, via an Object-oriented way-of-working that directly relates the test steps to the user interface (so-called Page Objects). These Page Objects are reusable across multiple screens and contribute to the maintainability of the test scripts. If an update is needed, you only have to do it in one place after which all 'usages' are immediately updated.

These two things together enable the tester to quickly respond to the necessary changes made by the development team. Testing is no longer the bottleneck.

Want to know more?

You can download JOSF for free via to get a taste of the tool. In addition, we are happy to plan a meeting with you to further discuss the possibilities and to provide an extensive demo. Send an email to

About the author

Brian van den Brink is Chapter Lead OutSystems at Valori. He is convinced that in-depth knowledge of a Low-Code platform is essential to be a good Low-Code testing professional. This knowledge enables you to create unique test solutions. Brian regularly speaks and blogs about Low-Code in general and OutSystems in particular.