5 principles of a Low Code Quality Assurance plan

Ensuring high quality applications

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:

Know what's important

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:

Which parts of your application are crucial? Which breakdowns will block the process?
Which parts of your applications are error-prone? What are the places where logic is complex, dynamic and/or often changed?
What does your (low-code) platform take care of? What are the things that you need to correctly configure on top of the platform features?
What are your thresholds for success? Is there a certain response time, number of concurrent users or other measure that’s important to the organization?

By answering these questions, you quickly turn an infinite list into a comprehensible set of key quality criteria. These are the criteria that your plan will focus on.

ABT - Always Be Testing

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:

Focus on the foundation. Define the crucial units, build unit tests and combine several unit tests into scenarios. Having a solid foundation improves the speed of delivery in the future. Without a solid foundation, the technical debt will increase rapidly, making you application hard to maintain. We get that you want a happy customer and deliver fast, but all clients and developers are happier with a stable solution.
Start immediately. It is easier to solve bugs in the beginning of a project, when the foundation is built. Redesigning the foundation later during the project brings many issues. The earlier you start testing, the longer you can enjoy a solid fundament.
Automate your tests where possible. It might seem a lot of work, but once it is in your routine you will see it costs much less time than testing old functionalities over and over again by hand. Keep in mind to focus on critical parts, automating everything is not necessarily the most efficient way.
Make testing part of your definition of done. To ensure testing is done in a disciplined way, accept a functionality as done only when the necessary tests are built. This way you motivate the team to work disciplined and you prevent a big pile of work at the end.

Expect the unexpected

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:

Your application might work perfectly now, but will it work well once it goes live? There is a maximum load the server can handle, so you might need to make some changes to ensure the application will not break down. If you expect many users and/or server calls, it might be a good idea to apply some load and stress testing before going live to prevent issues during go-live.
You might walk through your happy flow hundreds of times before go-live, but there will always be this user that happens to have a completely different way of working in mind. To anticipate on this it can be useful to randomly bootstrap data to test your application. While this might result in testing non-realistic scenario’s, it will definitely make you aware of some realistic but unforeseen behavior.

Keep it safe

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:

OutSystems has built-in roles that can be used to deny access to a screen for unauthorized users. However, it is important to ensure the other data is not even fetched and the screen components cannot be made visible by inspecting and injecting the application’s source.
Features to encrypt data are very useful to safely store passwords in the database., but one should not only rely on the encryption of data as there are other ways to hack someone’s credentials. It is highly recommended to apply a password policy to ensure strong passwords.
Random tokens can be created to allow access for specific screens to non-registered users. As these tokens might be intercepted, it is a good idea to apply 2-factor verification and let the token expire after a certain amount of time.
While low- and high-code frameworks can generate URLs based on your page’s input parameters, be aware that it’s easy to change one of the IDs that are passed. You might encode the URL, or double-check someone authorizations on the load of a page.
Session variables and offline databases might speed up your application but are relatively easy to peak into. Only make use of these types of storage when handling non-sensitive or encrypted information.

Review, review, review

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:

Peer review each feature. It is good to check whether all known best practices are applied and four eyes see more than two.
Review your own product & architecture after some time. Iteratively building new functionalities results in technical debt over time, as new insights are gained during the project. Therefore, it is important to sometimes take a step back and critically review your architecture with the newly gained insights. The longer you wait to do this, the harder it becomes to make a change.
Review best practices. We learn from experience and therefore benefit from reviewing our best practices regularly. By sharing knowledge and experiences we can gain new insights and have substantiated discussions to determine what the best practice is. Reviewing other products can also be very useful, as you learn unknown practices and gain new insights on known practices.

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:

A ‘discover’ phase allows you to design the user experience before using the plug-and-play components, leading to a technology-agnostic design of your solution. Experience first, technology second.
Starting your development phase with a solution canvas is the beginning for solid, high-quality and effective solutions. It will drastically increase the flexibility and stability of your landscape, allowing you to easily scale and maintain your products.
Having a Low Code Quality Assurance plan complements this design of quality with mechanisms to assure quality during development. By knowing what’s important, continuously test that, prepare for unexpected incidents and always reviewing your best practices, your create a loop that increases your ability to deliver high-quality applications.

Would you like to know more?

Maud van Paassen

Business Technology Consultant