This is a Menditect guest blog by Ruud van Berkum Test Automation Consultant and Jan Jaap Cannegieter, Principal Consultant at Squerist where they argue to keep using the product risk analysis as a powerfull tool to optimize testing of low code apps.
The use of Low Code is increasing rapidly. Initially, low code was used for organizations to create small, self-contained and generally non-mission critical applications. Soon, organizations were using low code to create applications that run “on top of” other applications, such as SAP. Testing was not so important with these kind of applications; if it didn’t work, the consequences were manageable and there was often a workaround. For example, testing in production was fine. But low code has become more widely used. Organizations now make extensive, complex, business-critical applications where, for example, reliability, security and speed are essential (see state of low code report) Due to the size, complexity and because the business processes have become dependent on low code applications, testing can no longer be ignored or done in production. So testing has simply become a full part of low code development.
But isn’t the quality of a low code application the responsibility of the supplier of the low code platform? Partly yes. If you only use the generic part of the low code platform and only use the standard options and building blocks from the supplier, you can assume that this works well. Unfortunately, practice shows that this varies quite a bit per platform supplier, this works well with some of the suppliers. But certainly when we make large, complex, business-critical applications, we never stay within the aforementioned limits.
Certainly the development of business rules, the real functionality, is so complex with some platforms that mistakes are easily made and these defects are not always visible quickly. This also has to do with the complexity of some business rules. With some platforms you also build the functionality via old-fashioned programming. This indeed offers the maximum possibilities, but you should definitely test this ‘high code’. In addition, there are also various freely available building blocks that do not come from the supplier. The quality of these building blocks varies quite a bit, so it’s better to test them well. A third reason why you need to test large, complex and business-critical low code applications nowadays is that the non-functional requirements, such as compliance, security and performance, become very important and this does not always go well.
So here arises a choice; take the risk or test and know for sure. The last reason that you should test large, complex and business-critical low code applications is that these applications do not stand alone, but are often part of a chain. So that means interfaces, connectors and the like. To be sure that the chain works, you have to test end-to-end.
We now know that you should always consider whether you should test a low code application or not. And to answer this question you should always perform a product risk analysis. Because time and resources are limited, so we have to spend them as well as possible. In low code there are in a general sense things that you do not need to test and things that you do need to test. What you don’t have to test are the parts that have been developed with the standard functionality of the platform. You should consider the following things to test with low code:
The approach of a low-code product risk analysis is not different from the approach of a classic waterfall process or agile system development. So determining the stakeholders, determining the business risks and technical risks and quantifying those risks. We then assess whether we want to mitigate the risks and if so, what the best way is. The above list of generic risks can be used as input and when estimating the technical risks it is best to involve platform experts to determine how big the risk is with that specific platform.
There is one more non-product-oriented risk in low code development that should not go unmentioned. And that is that with low code the developers can come up with so much functionality, system parts and adjustments so quickly that testing becomes the bottleneck. To reduce this risk, you should certainly consider low code testing and apply test automation from the very beginning as explained in the Menditect blog “Mendix apps don’t need test automation, on the contrary”. Without test automation, the chances are quite high that you will lose the match, resulting in a lot of delay or unmitigated risks in production. So include test automation from the start. And it is obvious that you then use a low code testing tool; it would be a shame if we minimize programming in development and have to program extensively in the test phase.
Choosing the test automation tool for Mendix asks for a high-speed, low maintenance solution that has strong support for small teams.
In the next blog, we’ll throw some light on how to meet these criteria without writing new testautomation software.
| info@menditect.com | |
| +3185 - 4010494 | |
| KvK: 82975795 | |
| Volg ons op LinkedIn |
Enter your information and choose a day and time when you would like to receive the demo (1,5 hrs).