Don’t Test Me

Key Points

• Innovation requires change and businesses need abilities to respond quickly
• Most application and automation changes are brittle and require an SDLC every time a change is made
• Allowing businesses to configure rules outside of integration technology increases their responsiveness and velocity

Low-code platforms cause testable events

Low-code platforms create testable events whenever changes are made. This is a problem. These platforms have focused on developing code and app construction instead of maintaining apps and lowering the total cost of ownership. Therefore, changing code or modifying apps built with low-code platforms involves a lot of IT resources like developers, testers, dev environments, and integration environments.

Most platforms are extensible and allow integrations, but the process is brittle since the business logic and integration methods are coupled together. If you have ever seen a step in the process that included “paste your code here”, then you understand what we mean.

To make this process smoother, what’s needed is something akin to Excel or WordPress that allows building blocks without coding the wiring or integrations and business logic together. This would avoid having a testable event triggered every time you make a change as with certain other platforms. Understanding how these platforms differ from others is an important consideration when it comes to choosing the right way to automate processes across different systems and teams.

What is a testable event?

When it comes to the software development lifecycle (SDLC) we move through the stages of requirements, writing code, and testing. This can be broken down into two main categories; functional testing and non-functional testing. Functional testing ensures that the applications do what they are supposed to whereas non-functional testing looks at more technical aspects such as scalability, performance, and reliability.

However, some events are not considered part of SDLC and thus are not testable. For example, if you decide to make changes in an Excel spreadsheet by changing formulas or charts this would not require a full SDLC process as this simply utilizes the existing building blocks of Excel rather than asking Microsoft to rewrite Excel for you.

Therefore, when it comes to testing, there is a third category after functional testing and non-functional testing–business-level changes. Decoupling business-level logic enables the business to own rules and logic changes without having to go through a lengthy SDLC process requiring IT resources every time an edit is made.

You won’t keep up if you have to test every time

You won’t get ahead if you have to constantly test every new change. Businesses need to find a way to make changes and automate tasks without triggering a huge testing cycle. Otherwise, they’ll be stuck with a never-ending backlog of items.

The problem is rarely related to the programmers’ code; it’s connected to all of the other steps in the SDLC (Software Development Life Cycle). So finding ways to deploy quickly and cost-effectively is key. Separating those changes that do require an SDLC from those that don’t will help immensely.

Using modern technology like ‘stubbing’ and ‘mocking’ can help avoid wasting time setting up data environments. The idea is to let business people control the logic, and only test the changes they’ve made–without needing to know how it got to the database. This shift in mindset can make a big difference in speeding up processes while still being able to ensure quality.

The biggest fear when making traditional changes is having to create multiple expensive environments for different teams — developers, build environment, UAT (User Acceptance Testing), users, security, etc. With modern technology and this new mindset, businesses can move forward quickly without sacrificing quality or accuracy.

Your automation contributes to your technical debt

Your automation efforts can contribute to technical debt if you are using traditional automation platforms which are essentially a thin veneer over VBScript, JavaScript, or code generators. These changes require coding and testing, however, it is possible to achieve the same velocity with a different architecture pattern.

For instance, using natural language processing between the configuration of building blocks and the programming logic can alleviate many problems associated with change. This layer allows you to invoke backend systems in much the same way as an Excel function is called – without actually needing to call any programming logic.

Having this kind of high-velocity change in automation projects allows businesses to keep up with their needs and avoid having to pull down previously created automation that they cannot maintain due to a lack of the ability to test. By distinguishing between the integration technology and the business layer technology, it is possible to avoid triggering a full SDLC to test changes.

This approach can help reduce technical debt and increase business velocity.

Change without the long-tail

Businesses need to find ways to make changes and automate tasks quickly and cost-effectively without triggering a huge testing cycle. By using modern technology such as natural language processing between the configuration of building blocks and the programming logic it is possible to invoke backend systems in much the same way as an Excel function is called – without needing to call any programming logic. This helps reduce technical debt and increase business velocity by separating automation change management from functional testing.