Some months ago, we started a blog series about doing low code right. While the technology provides great benefits — offering plug-and-play components, making development easy and accelerating delivery — the very same benefits could easily turn into pitfalls. While speeding through development without a rigid way of working, some organizations end up with low-quality, poorly performing products that are hard to maintain.
In our last post, my colleague Riccardo explained how we prevent a spaghetti architecture and build a stable 4-layer lasagna instead. With the consistent foundation designed in the solution canvas, the maintainability and extensibility of your application landscape significantly increases.
Unfortunately, solely drawing out a solution canvas is not a guarantee for success. To stick to our Italian food metaphors, even a pizza with a delicious base can be ruined by the wrong toppings. Ask Riccardo.
There will always be unforeseen situations. There will always be a chance of breaking existing things when building new functionality. In addition to designing quality, you need to assure quality. To do this, we support every project with a Low Code Quality Assurance plan.
Our Low Code Quality Assurance plan is built upon 5 principles, which are explained in the remainder of this post:
One of the reasons for product teams to skip quality assurance is the feeling that it seems endless. Reviewing every page and flow before going live, testing every previously built functionality when a new user story is finished, it’s a very long list of items to check. While this might be the way that things are done when development budgets are limitless, your average does not have the time or budget to always check everything.
Therefore, a QA plan starts just like a Design Sprint, it starts with focus. There’s a couple of things to ask yourself in order to determine your focus:
While all your products are awesome and flawless when designed, some issues will appear when it is actually used. To prevent that, testing is at the core of your Low Code Quality Assurance plan.
Testing whether there are no bugs in new functionalities, but also testing previously built functionalities when a new user story is finished. Testing is a continuously recurring activity and hence not the most fun part of the job. However, continuously recurring does not have to be equivalent to time-consuming. Testing may not be fun, but with a little bit of discipline we can make it better:
Defining the focus for your testing and automating your tests is a good start to assure the quality of your solutions. However, testing is not only about preventing the break-down of critical functionalities, but also about ensuring the application functions as expected in all possible scenarios.
While all possible scenarios is pretty infinite, we can limit the unexpected by keeping the following things in mind:
We probably don’t have to inform you on the importance of keeping your security up-to-date for your applications, especially if it contains sensitive information. Luckily, most (low-code) programming platforms have many built-in security features to accelerate the development of secure applications (easy configuration of authentication & authorization, encryption of data, etc.). The vendors improve these features regularly to compete with the knowledge increase of hackers.
However, having the best tools does not automatically make you a good cook. It is the way the built-in features are applied, that determines the security of the application. Some examples:
Best practices are just like recipes. Most of them are already defined and thought through by other chefs, ready for you to cook with. When you want to improve your cooking however, one of the first mechanisms is tasting and improving.
As technology is continuously improving, the best practices may not remain best practices in the future. Additionally, your own preferences and experiences will influence your opinion on best practices. Reviewing is therefore an important part of your Low Code Quality Assurance plan. We define three levels of reviewing:
Ensuring successful low-code projects requires a bit of discipline. In the three blog posts of this series, we’ve highlighted three essential elements of this discipline at Quatronic:
Business Technology Consultant