Low code platforms such as Mendix are conquering the IT world. More and more organizations embrace the value they provide in allowing you to quickly build custom applications at scale, while keeping the infrastructure and necessary platform as standardized as possible.
Although the implementation of the Mendix platform has many benefits, there are some challenges you might encounter that are related to maintaining the required application quality over time. One of these quality challenges is about testing and the use of test automation. The question arises if test automation is required for low-code platforms like Mendix. Or does the nature of low-code diminish the need for testing and test automation?
This blog will evaluate ordinary application and project circumstances that require test automation first. Later on it focuses on the specific characteristics of a low-code platform like Mendix and its effects on the need for test automation.
The use of test automation is not a holy grail and will not automatically deliver app quality by itself. Application and project characteristics should be evaluated wisely on a case by case basis in order to reap the benefits without being overwhelmed by test automation drawbacks.
Mendix apps need test automation more imminent when the app has one or more of the following characteristics;
Examples of project characteristics that add to the decision for test automation are:
If your app or project is not conforming to one of the drivers, you can stop reading this blog. Yet, if one of these drivers apply, you might need to spend so much time on manual testing that a business case for test automation emerges. The search for your optimal test automation strategy begins.
Are there specific aspects of using the Mendix platform that need to be taken in consideration when evaluating your test automation needs?
First of all, the use of the Mendix platform prevents a lot of high-code mistakes and delivery hiccups. Mendix’s unique quality feature, which checks model consistency during development, is adding a lot of value in precluding bugs that can be found by testing only.
But at the same time you should be aware that the Mendix platform is basically an application or group of applications by itself. The platform supports, among other things, app development, deployment, management and hosting. The Mendix application needs regular platform updates to fix platform bound bugs, deliver improvements and add new features. This results in a demand for a complete test of the deployed business application on the platform in order to ensure it’s correct functioning. It’s obvious that these tests can be labour intensive. This can be relieved with test automation to a large extent.
Although an Agile project approach is not reserved for app development with Mendix, its characteristics are quite inviting to use Agile. Without blaming Agile as a method, the day to day practice of using Agile is causing some side effects. Let’s focus on two of them.
One of them is that focussing on constant business value delivery is often causing a lack of focus on design and architecture. This can result in bad structured applications making impact analysis hard and causing unwanted side effects in other parts of the code (regression bugs). Hence, testing is used in order to cope with these consequences. Test efforts need to have quite some coverage to ensure that critical code is working as expected.
Another one is that the drumbeat of short cycled app delivery by Agile sprints implies that test efforts should follow the same drumbeat. If validating the code can’t keep up with app development, an (accepted) low test coverage will be the result – and thus an (accepted) number of production fails.
Mendix promises an increase in app realisation speed up to six times faster than high-code app development.
Involvement in various projects learned that high-speed delivery of low-code has pivoted the overall business experience of software development from slow realisation to slow acceptance. This proves that the claimed increase in speed is true. It also shows that businesses are commonly not capable of executing all the regression tests in time. Especially when regression testing is executed manually – and by that incomplete. It makes test execution by the development team more important in order to maintain quality. So, Mendix apps need test automation even more, to keep both the speed of the team and the quality of the app high.
Some companies use the higher development speed of Mendix as an argument to accept quality flaws. Their reasoning is that bugs can be solved quite fast and therefore are more accepted. While this reasoning is valid for applications that are not conforming to the characteristics of test automation, this approach is undesirable in all other cases especially when data quality is harmed.
As with the Agile drumbeat, the consequence of increased speed is that testing and test automation must keep pace with app development. If not, testing or test automation is becoming the new bottleneck in fast app delivery.
A citizen developer is an employee who creates application capabilities for consumption by themselves or others (source: Gartner glossary). This type of developer generally has no IT knowledge or experience and has not been raised with important development practices like code standards, the use of patterns, code structuring and architecture. Moreover, a lot of Mendix business engineers are quite junior because of the tight market for skilled people. Take note that these qualifications are in sharp contrast with the T-shaped figures that are needed in small teams!
The ease of use of Mendix is empowering these ‘low-IT profile’ developers with the ability to create applications without technical hassles. It attracts people because it stimulates their creativity to rapidly get the functionality they need. Experience shows that they solve complex business problems through ‘process thinking’ instead of finding the root cause of problems. The result will be a piece of software that is as complex as the business problem itself, is badly structured, unmaintainable and unstable. Or spoken in IT-terms; it has a lot of ‘technical debt’. It causes fear in developers to modify application functionality because the end result is unpredictable.
Of course, test automation cannot replace the lack of knowledge and experience. Education, code standards, peer reviewing and other measures are needed to keep the team and code quality on track. But test automation can play a role in two ways.
First of all, test automation is focussing the team on code quality, and by that, plays a role in educating team members and influencing their behavior.
Secondly, test automation is taking away the fear of cleaning up ‘technical debt’ by refactoring code. If refactored code has side effects, the test automation will detect it and warn early in the process.
To be clear, the value of attracting citizen developers in itself is not denied. They often bring a lot of business knowledge and creativity to the team. The mismatch is caused by wrong team balance and wrong expectations and even misuse of the Mendix platform.
Does the use of Mendix eliminate the need for test automation? Certainly not. Mendix apps need test automation even more than apps developed in a high-code environment.
Next question will be, what are the most important criteria that test automation should meet? Read more in our next blog “Desired properties of test automation for Mendix apps”.
| 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).