“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.
