Low-code speeds up development time, but what about testing time?

Low-code has been experiencing widespread adoption across the industry over the past several years, but testing apps created using low-code tools is unfortunately falling behind.

According to Raj Rao, chief strategy officer for Sauce Labs low-code solution AutonomIQ, often companies set up citizen development programs where employees with no technical background can use low-code or no-code tools to build applications. However, when it comes time to test those applications, a lot of testing tools use traditional code that citizen developers don’t necessarily understand.

For those companies, testing is a bottleneck because the citizen developers who write the application then can’t test them. This bottleneck results in a number of issues, such as test fatigue and test debt. 

Test fatigue sets in when users are required to perform a full battery of tests repeatedly in a manual fashion. This is when the users responsible for testing start to make mistakes or give up due to pre-defined test windows. The effects of this are that defects can start creeping into production. 

Test debt is exactly what it sounds like. Just like when you cannot pay your credit card bill, when you cannot test your applications, the problems that are not being found in the application continue to compound. 

Eliminating test debt requires first establishing a sound  test automation approach. Using this an organization can create a core regression test suite for functional regression and an end-to-end test automation suite for end-to-end business process regression testing.

Because these are automated tests they can be run as often as code is modified. These tests can also be run concurrently, reducing the time it takes to run these automated tests and also creating core regression test suites. According to Rao, using core functional regression tests and end-to-end regression tests are basic table stakes in an organization’s journey to higher quality. 

Rao explained that when getting started with test automation, it can seem like a daunting task, and a massive mountain that needs climbing. “You cannot climb it in one shot, you have to get to the base camp. And the first base camp should be like a core regression test suite, that can be achieved in a couple of weeks, because that gives them a significant relief,” he said. 

According to a blog post from Sauce Labs, in addition to reducing test debt, test automation can save employees time and also save companies money. According to the blog post, companies that transition to low-code test automation tend to see a 25% to 75% reduction in costs. 

“Manual testing takes a lot of effort,” said Rao. “And it is not a one time effort; it is a repeated effort, because you keep making changes to these business applications all the time. It is easy to make changes, but hard to successfully deploy, because deployment includes testing and validation.”

This is especially true when talking about building applications in a platform like Salesforce or Oracle, where the underlying platform gets regular updates. For example, Salesforce gets three major updates per year from Salesforce, and with every update comes a large set of new features that then need to be tested against. According to Rao, doing this testing manually can take several weeks to complete the full regression. 

Addressing these issues sooner rather than later can help companies stay on top of things. Rao referenced Gartner’s prediction that by 2023, the number of citizen developers in the enterprise will be four times greater than the number of professional developers. “This is a group that cannot be ignored. And we have to provide the right capabilities and tools and frameworks for them to be successful,” said Rao.

---

To learn more, register for the free SD Times virtual conference, Low-Code/No-Code Developer Day, which is taking place on April 13, 2022. Rao will be giving a presentation on low-code test automation and will expand on some of these points.

The post Low-code speeds up development time, but what about testing time? appeared first on SD Times.

from SD Times https://ift.tt/P8EXWgo