Low-No-Code - Does anyone need a tester?

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