“No-code only shifts the topic of testing. Quality assurance remains necessary!” - Richard Seidl
Low and no-code platforms have become increasingly popular in recent years. At least in the media. There is a wide range of opinions about them, from “old wine in new bottles” to “the software revolution”. The solution promises are somehow the same as with all other software revolutions: Cost efficiency, speed to market, flexibility and ease of implementation.
The question of whether it makes sense to use low/no code can be answered with the most frequently used consultant quote: “It depends.” It depends on many factors. We need to examine this carefully! Because where there is light, there is also shadow. And of course we want simple solutions and abstractions for our now highly complex software world. We want to make complexity manageable.
What about quality assurance?
But what about testing and quality? I’ve heard that you don’t have to test with no-code. Well, I see it differently. For the lower test levels, we can rely on the manufacturers of the platform (cough, cough). But quality assurance at the higher test levels remains. And here especially questions like:
- Has a suitable architecture been selected for the processes/interfaces?
- Do the processes meet the technical requirements?
- Are the modules used sensibly?
Huh? These are the same questions as always. Yes. Because we’re just shifting “development” to a higher level of abstraction here. Instead of code, we are putting together modules, interfaces and processes. And here, too, there is an architecture, a development and a test. In my opinion, there is even a lot to be said for a very proper test. After all, anyone can be a “citizen developer”. And this often changes the roles. An example: a business analyst who, instead of testing and approving the in-house development, now starts to click together his applications himself. It’s practical, he has the technical know-how. But I’m simply assuming here that they don’t have the same in-depth skills:
- The BA is not a software architect. They will not think in terms of software design, entities, data flows and reusability, but rather put together modules, interfaces and other things as they see fit.
- He is also not a software developer. He probably lacks the paradigms, patterns and best practices of how a software flow works in the best possible way.
- He is also not a tester for his own implementation. In other words, testing and technical acceptance must take place elsewhere.
Software is software. Each one is different. Low-code does not mean low-test and no-code certainly does not mean no-test. But 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 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 interfaces tend to be put together based on personal judgment rather than a well-thought-out structure.
