“No-code only shifts testing somewhere else. Quality assurance is still needed!”
(Richard Seidl)
Low-code and no-code platforms have been getting more and more popular for a few years now. In the media, at least. Opinions range widely, from “old wine in new bottles” to “the software revolution”. The promises sound much like those of every other software revolution: cost efficiency, faster time to market, flexibility and easy implementation. So let me say this up front about no-code testing: you still have to test.
Does low-code or no-code make sense? That question gets the consultant’s favorite answer: “It depends.” It depends on a lot of factors, and we need to look at them closely! Because where there is light, there is also shadow. And of course, in a software world that has become so complex, both in business terms and technically, we long for simple solutions and abstractions. We want to make complexity manageable.
No-Code Testing: The Higher Test Levels Remain
So what about testing and quality? I’ve actually heard people say that with no-code you don’t need to test. Well, I see that differently. For the lower test levels, we can rely on the platform vendor (ahem, cough). But quality assurance at the higher test levels stays. Above all, questions like these:
- Has a suitable architecture been chosen for the processes and user interfaces?
- Do the workflows meet the business requirements?
- Are the modules being used sensibly?
Huh? Those are the same questions as always. Yes. Because all we’re doing is moving “development” to a higher level of abstraction. Instead of code, we piece together modules, user interfaces and processes. And there is still an architecture, a development and a test.
Citizen Developers Change the Roles
I’d even argue that there’s a strong case for really thorough testing here. After all, anyone can be a “citizen developer”. And that often changes the roles. One example: a business analyst who used to test and accept the in-house development now starts clicking together their own applications. Handy, since they have the business know-how. But let me simply assume a few skills that aren’t quite as developed:
- The BA is not a software architect. They won’t think in terms of software design, entities, data flows and reusability, but will put modules, user interfaces and whatever else together as they see fit.
- They aren’t a software developer either. They probably lack the paradigms, patterns and best practices for making a software flow work as well as possible.
- And they drop out as tester of their own implementation. In other words, testing and business acceptance have to happen somewhere else.
Software is software. Each one is different. Low-code doesn’t mean low-test, and no-code certainly doesn’t mean no-test. Just different.
Frequently Asked Questions
Is low-code a fundamentally new idea or just old wine in new bottles?
Opinions on this vary widely, ranging from “old wine in new bottles” to “the software revolution.” It’s striking that the promises are the same as those made during previous software revolutions: cost efficiency, rapid time-to-market, flexibility, and ease of implementation. What’s new is primarily the level of abstraction at which work is done, not the basic pattern of the promise.
Is using low-code or no-code platforms generally worthwhile?
No. Whether it makes sense depends on many factors and must be carefully evaluated on a case-by-case basis. The desire for simple solutions and abstractions is understandable in a highly complex software world, both functionally and technically. However, it is no substitute for assessing where the platform excels and where its shortcomings lie.
Which test levels remain relevant when an application is built without custom code?
The higher test levels remain fully applicable. For the lower test levels, one can rely in part on the platform vendor, though with a healthy dose of skepticism. Everything that results from the combination of modules, user interfaces, and processes is new software and requires testing and functional acceptance.
What aspects of content should be reviewed in an application built with no-code?
Three questions take center stage: Has a suitable architecture been chosen for processes and user interfaces? Do the workflows meet the business requirements? Are the modules being used effectively? These are the same questions as in traditional development, just asked at a higher level of abstraction.
How do roles change when subject matter experts build their own applications?
Roles are shifting. A business analyst who previously conducted testing and accepted in-house developments now builds the application themselves. This removes a layer of oversight from the process. Testing and functional acceptance must then be deliberately organized elsewhere; otherwise, both will simply fall by the wayside.
Can a citizen developer perform functional acceptance testing on their own application?
No. Anyone who has built the implementation themselves is disqualified from testing that implementation. Testing and functional acceptance must take place elsewhere. This applies regardless of how strong the person’s subject matter expertise is, because reviewing one’s own work makes one blind to one’s own errors in reasoning.
Why doesn’t subject matter expertise replace architectural and development knowledge?
A business analyst is neither a software architect nor a developer. They generally lack the ability to think in terms of software design, entities, data flows, and reusability, as well as the paradigms, patterns, and best practices for a robust software workflow. Without this knowledge, modules and user interfaces tend to be put together based on personal judgment rather than a well-thought-out structure.
