Author: Julia Caldwell

Low-code dev platforms have been around for 30 years, but in 2020, adoption has reached an inflection point. Today, a majority of developers report they are either planning on or have already implemented a low-code platform to build digital business applications (see figure). As proponents push into more mission-critical use cases and pro-dev shops look to augment and accelerate traditional environments with new capabilities, low-code is going mainstream. Yet concerns remain — can low-code deliver software with the appropriate levels of quality, scale, and sustainability?

 

Advocates and critics alike continue to probe low-code’s boundaries. An emerging piece of this puzzle is the degree to which apps created with low-code are tested, can be tested, and should be tested. Organizations should not deploy idiosyncratic business applications into production without verifying and validating requirements and functionality. Malfunctioning or maldeveloped applications create waste and rework in the most benign instances and revenue loss and brand damage in more serious ones.

The merits of testing do not change in low-code development, but the rigorousness may. The layers of abstraction in low-code development create a somewhat uncharted gray area — how much traditional testing is still relevant when bundles of code come in precreated components? In cases of customization, how much custom code can be tested in the native low-code platform, and how onerous is it to integrate with existing continuous integration/continuous deployment tools? These and other testing-related challenges come to light as we work with clients on low-code deployments, and we are exploring the best practices for testing low-code applications in forthcoming research.

Organizations looking to take advantage of low-code’s heightened speed and collaboration should join this conversation. How an application’s functionality, productivity, and experience can be tested natively in low-code platforms and/or whether it should be subject to traditional testing frameworks will help determine which workloads users should target for early low-code projects and which should be shelved for a later date.