You make a valid point, Agile itself does not make automation cumbersome. We were trying to say that exclusively.

I think it is true that a coded approach to automation makes is cumbersome, creating a code maintenance burden, and if that is the case it surely does become a software developer problem. So, a coded approach to automation makes it the domain or software developers and excludes persons without these skills from automating testing.

Hence the argument, that automation which is not based on code is quicker and less costly to build and maintain, and supports a wider population of persons who otherwise are forced into a manual approach to testing.

Key to making a non-coded approach successful is to have a solution which is easy to learn, but still powerful, is able to adapt to application changes and can minimise the impact from changes in other areas such as data. These tenets have been the keystone of our design philosophy and the success of our customers.

1. People funding automation doesn’t understand what it takes to be successful. They are typically sold on fancyful presentataions that hide complexities.
2. Many doing or managing automation – do not understand “Testing” at all. Missing connection and its importance makes automation tough as you do not understand how these are connected.
3. Automation is a software development job (regardless of however asy and scriptless a tool vendor might claim to make it).

Not surprising that you are taking this position being a tool vendor. I don’t agree with the viewpoint that automation is cumbersome because – applications (that in agile world) change quick and automation can’t keep pace with it.

If we look at broad spectrum of apps — not all work in agile… not all change that fast .. if you are showing one part of the picture alone …

A picture that puts your tool as solution. that is fine .. but show what else is there that makes automation combursome

Shrini