Codeless test automation is a phrase that’s a little mired and comes with a certain amount of baggage. I mean, did so-called “codeless tools” such as recorders help testers speed up delivery through their object recognition or perform simple actions? Undoubtedly! But did they need to be used in conjunction with code to be effective? Yes, if you ship your product with a built-in IDE, you can’t really call it codeless. The tools I am referring to are plentiful and were great, but they were of their time. Two forces, one a technological advancement and the other a market requirement, have changed the face of test automation for the better. Let’s dig a little deeper into the two.
Since Hewlett first turned to Packard in their garage and said “we need faster feedback between the build and test stage” (and probably before), testing as quickly and early as possible has been of paramount importance. Whether it’s agile, CI/CD, shift-left, TestOps, post-agile, post-mature-agile, or post-mature-agile-with-a-beard, we are talking about shipping better quality products faster. This is, of course, an oversimplification, but the point is that the software market is driving methodology adoptions because of its need for speed. Being first to market and consistently and continually offering users high-quality new features is the driving force behind how software is delivered. And with the growing complexity and continued demand, this post-waterfall trend is only set to continue. Plus, many have characterized QA as a poor relation of software development. This trend, therefore, puts increased pressure on QA teams, and they have to find methodologies and tools that can help them keep pace with the market demands.
We can see how the market's demand for feature-rich software delivered at break-neck speed and recent technological advancements have provided a gap in the market for a new generation of test automation tools. Gartner calls it test hyperautomation. I see it as:
market need + technological ability = truly codeless test automation that works
We have a situation where QA no longer needs be the poor relation. Test automation tools have caught up with the needs of the market in terms of their abilities.
The advancement of technology, driven by market forces, is nothing new. From time immemorial, those who embrace these advancements and cleverly evolve their relationship with them come out on top. And it is an evolution of QAs relationship with new test automation tools that is important. For these teams are still driven by the market force that wants better quality products, faster. If QAs can adopt methodologies, processes, and tools that can do a lot of the grunt work, they will be best equipped to meet the market demand. Let’s have a look at an example of this: If QAs can create tests that work without code ten times faster and these tests maintain themselves, their time is freed up. Time that can be spent looking for bugs is now spent performing complex exploratory tests that require both human and technology working in perfect harmony. Those who do not embrace and adapt their relationship to new technologies will not shine as bright. But in the end, we are all just lumps of carbon trying to make the best with what we got. I am just asserting that what we got just got better.