S1:E6 - Low-code testers aren't ingenious (enough)
For many organisations a continuous flow of application updates is crucial. This requires super-fast software development that addresses customer demand immediately. Low-code platforms are making this a reality for more and more organizations and applications. However, the speed of low-code development requires, even more than 'before', adequate QA and test solutions. The faster your figurative low-code plane flies, the more important it is to take the right measures so as not to lose altitude.
In this series Gaining Speed Yet Losing Altitude we discuss a low-code quality challenge and the measures you can take.
Ingenuity ensures that you continuously challenge yourself to find better, faster or cheaper solutions to a problem you encounter. In this blog I'll tell you how a low-code tester can distinguish his- or herself with this.
Low-code applications are still too often tested like many other (high-code) applications and sometimes even seen as a black box. That is a shame, because the capabilities provided by the low-code development platform can contribute to a (more) effective test strategy. As a tester, it's much easier to take a look under the hood, which enhances the dialogue with the developer. Too often we run into the problem that testers of low-code applications do not take advantage of these capabilities.
One of Valori's core values is ingenuity. “We are creative, come up with smart solutions and come up with inventive ideas. By deploying our solutions and ideas, we make our work more fun and better. In this way we create added value for the customer and for ourselves.”
Without this ingenuity we cannot guarantee our craftsmanship. That is why we are continuously looking for unique test solutions within Valori's low-code Tribe, specifically for low-code platforms.
Quality is a team responsibility
Quality is a responsibility of every discipline within the software development lifecycle (SDLC). Think, for example, of a clear, unambiguous, testable and implementable business wish. A developer is responsible for a qualitative and maintainable implementation. In addition, the testability is examined together with the tester. This should also be specified in such a way that the business understands at a glance what is being built and monitored. This collaboration is the foundation of a quality-conscious organization and also requires ingenuity. In the initial phase, the team may see this as unnecessary extra work. It only pays off over time. That's why it is important to continuously look for working methods that burden the primary responsibilities as little as possible and yet ensure the highest effectiveness of the team.
Low-code lowers barriers between disciplines
Low-code platforms such as OutSystems make quality easier to understand for all these disciplines. The implementation of the business wish can be traced through process flows and a mostly logical syntax. The underlying data model is also transparent to everyone. In general, no advanced knowledge of a programming language is required to understand these components. This opens the door to a dialogue between developers, testers and analysts and are all points of departure for a more effective low-code testing strategy. With the right dose of ingenuity, the tester will also start looking for ways to stimulate this dialogue.
Super fast super wrong
This dialog is necessary because low-code allows you to develop software at lightning speed. Within this way of development, however, 'development skills' are still important. It also allows you to do something super wrong super fast. You may not notice this immediately, but if the basics are not in order, you are guaranteed to suffer from this over time. So with skills, low-code means you no longer have to think about programming languages, but much more about the ability to keep a business wish manageable in the application. What do you need to implement this wish as effectively and maintainably as possible? Think of the proper dividing of software into maintainable pieces of code, being able to distinguish between generic and specific actions and embedding good testability in the architecture. These are not things a low-code platform forces you to do, but they are certainly things a developer should take into account.
Tech First, Test Second
Before you can discuss with a developer at such a level as a tester, it is necessary that you have knowledge of the relevant low-code platform. At Valori, we believe that in-depth knowledge of the software stack in which you develop makes you a better tester. We 'speak' the language of the software development teams. For example, our OutSystems consultants are certified OutSystems developers and use the same toolsets as the developers. However: We come to test and have knowledge of everything in the field of software testing and test tools. We call this "Tech First, Test Second".
New wine in new bottles
With this knowledge we can also use the low-code platform for the testing process. For example, are there smart ways to create test data? Or can we test specific business logic, without being dependent on all kinds of other factors? These kinds of solutions are a combination of ingenuity and craftsmanship and make testing low-code applications really different from testing non-low-code applications.
Would you like to know how we can take the quality of your low-code application to the next level with our craftsmanship and ingenuity? Please contact me. I would be happy to discuss it with you.
About the author
Brian van den Brink is Chapter Lead OutSystems at Valori. He is convinced that in-depth knowledge of a Low-Code platform is essential to be a good Low-Code testing professional. This knowledge enables you to create unique test solutions. Brian regularly speaks and blogs about Low-Code in general and OutSystems in particular.