For low code applications there are technical things you don’t have to test, like the integration with the database and the syntax of a screen, says Jan Jaap Cannegieter. But you still have to test functionally, to check if you’re building the right thing. End-to-end testing and non-functional testing can be very important for low code applications.
Cannegieter will speak about testing low code at QA&TEST Embedded 2022. This conference will be held from October 19-21 in Bilbao, Spain.
Testing can help to address risks in low code development as Cannegieter explains:
With low code, we still have risks related to human mistakes and complex business rules. But there is an extra risk because low code platforms look misleadingly simple. It looks as if everybody can build systems. And in some situations, this is true! But when the business rules are complex, the database is big and complex, and the customer journey asks for several related functionalities, defects are easily introduced. The extra risk is that inexperienced developers introduce defects.
According to Cannegieter, technical reviews and testing of the screens, business rules, and database handling can help to address the risks of low code development. It is up to the team to use the platform in the right way and make the right functionality, and reach the desired level of performance and security.
InfoQ interviewed Jan Jaap Cannegieter about testing low code applications.
InfoQ: What are the main differences between "high code" and "low code"?
Jan Jaap Cannegieter: High code is program code as we know it, where developers type in the code using a specific syntax. Like C# or Java. This is very labor-intensive and error-prone. Besides that, there are not enough well trained and experienced developers available.
In a low code platform, you build an application by means of a user interface. For instance, building screens by dragging and dropping items and building logic using process-like flows. This sounds simple but it can be very complex and error-prone.
We’ve seen four generations of low code applications. First, there were small, simple, stand-alone applications. Then we have small apps on top of SAP, Oracle Fusion or Microsoft Dynamics. The third generation were business-critical but still small apps to offer extra functionality besides the ERP system. With these apps, you don’t have a workaround. Now we’re building big, complex, business-critical core systems that should be reliable, secure and compliant. The level of testing increases with every generation and in the fourth generation, we see that testing is only slightly different from testing high code applications.
InfoQ: What about the vendors of low code platforms, what kind of testing do they do?
Cannegieter: That differs per vendor. For the big, well-known platform vendors, the platforms work well. Some vendors also have standard building blocks available; these blocks also work well. But when you use building blocks built by others you never know what the quality is. With so many low code platforms today, there are also platforms that are not that well-tested.
InfoQ: What can we skip when testing low code applications?
Cannegieter: The technical working of the platform, integration within the platform and the standard functionality of the platform can be skipped when you are using a well-known, widely used platform.
If you select a date-field and drop it on the screen, you are making a connection to a database field. You don’t have to test the integration with the database, but I would certainly test if the date entered in the field is used correctly in the business rule.
Testing is important if you want to limit the risks when you go into production. Especially when the application is critical for the users you should test it in a professional way, or when the application is technically seen as complex. Testing is still an important part of system development, no matter whether you use high code or low code.
If you’re making simple applications only using the standard functionality of the platform, only using standard building blocks, don’t use high code, and when there is a workaround available you could test less or test with non-professional testers, like untrained users.
