Low-code app frameworks (meaning those that let developers write an app with minimal original coding) reduce the amount of time and programming skills required to produce an app.
But low-code doesn't necessarily mean that QA teams are off the hook when it comes to testing the application. Functional testing and performance testing for low-code apps are just as critical as they are for any other types of apps. In fact, in some ways, having a solid QA process in place for low-code environments is even more important than it is for conventional applications.
In a nutshell, a low-code app is one developed using a tool or platform that minimizes the amount of original code that developers have to write to produce the app. Most low-code tools let programmers implement business logic using point-and-click interfaces instead of having to write out computer code in a text editor or IDE.
Low-code doesn't always mean no-code—in many cases, low-code apps still require some custom coding or configuration—although there are some no-code tools that claim to enable totally codeless development.
There are two main reasons why businesses choose low-code apps. One is to allow non-programmers or employees with minimal coding skills to create basic applications. The other is to save time for experienced programmers by letting them build an application quickly using prebuilt functions and components instead of having to write out all of that code by hand.
Because low-code programming minimizes the time and effort it takes to write an application, you might be tempted to think it also minimizes the time QA teams have to spend testing the application.
In some ways, that is true. Low-code apps do generally eliminate the need for unit tests because there are few, if any, original "units" of code introduced into the codebase; instead, each component of the app is a prebuilt unit that ships with the platform, and its source code may not even be visible to the team that uses the platform.
Low-code apps also typically support a limited range of deployment configurations. Part of the way in which low-code platforms reduce the complexity associated with building an app is by requiring the product of a low-code development process to be deployed in a specific type of environment instead of trying to support every configuration out there. By extension, testing teams have fewer environment configurations or variables to test for.
But in other ways, low-code apps require thorough testing and vetting before they can be released confidently into production. Here are some of the main reasons why QA teams need to be a central part of the low-code delivery chain.
The first and most obvious reason is that the prebaked modules that low-code platforms provide to help build applications may well contain bugs. Just because the low-code vendor ships a component to you (and theoretically tested it before shipping it) doesn't mean it will be bug-free—especially not under whichever configuration or architecture your team uses to build it into a low-code app.
Functional testing of low-code applications is critical to discovering these bugs. You might not be able to find them within prebuilt components that were not developed internally, but you can at least determine that they cause problems and find ways to work around them or avoid them.
Low-code applications rarely exist in their own, isolated world. Instead, they are part of larger workflows, and they must integrate with resources that are external to them. Typically, they rely on APIs to enable these integrations.
Testing APIs to ensure that your low-code app can use them as required is therefore crucial. So is making sure that any external storage, networking, or other resources that a low-code app needs to function are available and can be consumed in ways that allow the app to behave as required.
In some situations, QA teams are the only thing standing between a low-code app developed by a non-professional and your end-users. Thus, in cases where companies use low-code to empower employees with few or no programming skills to build apps, the QA team has a very important role to play in reviewing overall quality before the app reaches the real world.
This isn't the case with conventional apps that are developed by professional programmers. Those apps still need testing, but by and large, they are more likely to work as required than one tossed together by a marketer or salesperson who has no formal training in things like best practices for UI design or software performance.
This may not be a key consideration for low-code apps that are built to be used by only a handful of people or to solve a one-off, temporary need like helping to crunch numbers for a budget report. But for low-code apps that will be used regularly by an entire internal team or actual customers, you'd better hope a QA engineer makes sure the app is fit to do its job.
Speaking of performance, app performance is not typically something that low-code platforms prioritize. Instead, their main purpose is to make it easy to develop an application quickly. Low-code apps are unlikely to be as optimal performance-wise as their conventional counterparts.
This is another reason why software testing (and specifically performance testing) for low-code apps is even more important than testing for conventional apps.
I wrote above that most low-code platforms are designed to produce apps that run only under certain types of configurations or on a certain host infrastructure. That's true. But just because the low-code vendor expects your team to deploy to a given configuration doesn't mean that your team actually will. It can sometimes happen that your team decides to deploy on a different type of environment for some reason. Maybe the low-code vendor expects you to host on one type of Linux distribution, for example, but your organization uses a different one.
In these situations, the QA team must ensure that the application is fit to support whatever type of environment it is deployed into—or make sure the team reverts to a different strategy if necessary.
There are many reasons to use and love low-code development platforms. But don't make the mistake of assuming that low-code means low-QA. On the contrary, low-code makes QA oversight and engagement with the software delivery process even more important.
Chris Tozzi has worked as a journalist and Linux systems administrator. He has particular interests in open source, agile infrastructure and networking. He is Senior Editor of content and a DevOps Analyst at Fixate IO. His latest book, For Fun and Profit: A History of the Free and Open Source Software Revolution, was published in 2017.