The Promising Case Of Low-code Testing

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 mal-developed 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.

This post was written by SVP and Research Director Christopher Mines, and it originally appeared here.