Low-code/no-code test automation solutions are a hot topic in the software testing world. There are thousands of automation frameworks out there, which begs the questions: should we be talking about low- or even no-code automation solutions? If you’ve been in the software testing arena long enough, you’ll remember the world of business process testing using components, so this is hardly a new debate.
Inspired Testing invited TestGuild founder Joe Colantonio, and Test Automation Architect and creator of klassi-js Larry Goddard to debate this issue. The conversation was moderated by Inspired Testing Head of Consulting and Architecture, Jehan Coetzee.
You shouldn't base your entire automation strategy on low- or no-code. Instead, these tools should be seen as another arrow in your quiver of test automation approaches and applied only to solve a specific problem. – Jehan Coetzee, Head of Consulting and Architecture
The Great Debate: No code vs Low code vs Scripted Automation
The webinar covers the following:
- What is no code?
- Is that different than low code and in what way?
- Are they all not scripted, or are we looking purely from a user perspective?
- Who are these users?
- Do these solutions allow for a shorter path to “Hybrid Testers”?
- Do we need to choose one or the other or is there a place for all 3 types in a project?
- What is the impact on the “normal” tester out there? Does it change the role of automation engineers? Or even make them obsolete?
- Where do we start? Does it require a change in strategy?
The impact of low-code/no-code test automation on test professionals
Test automation engineers may feel uncomfortable with the rise of low-code/no-code solutions. Too often, business decisions are based on the bottom line, and the thought of replacing (expensive) human effort with automated solutions may be all too tempting. Inspired Testing Head of Consulting and Architecture cautions against this: ‘There is a big move to use AI and low-code/no-code tools to see if the “human intelligence” can be removed in a time- and cost-cutting attempt. As testers, our intelligence is what we bring to the table, it is what enables us to think differently. We should be putting the human intelligence back in testing, instead of an increasing reliance on Artificial Intelligence.’
