[hitchstory]

BTW, odd question - assume somebody built a low/less code test automation framework that didn't fail and was very effective but it also wasn't popular.

What could it do to stand out to you? What could it demonstrate in 15-20 seconds for you to think "OK this is different"?

[creesch]

1. Come without vendor lock in. 2. Format is human readable so it can actually be integrated in a proper development cycle (git, etc). 3. Doesn't make it a nightmare to do custom things where needed.

It is not impossible. Out the top of my head Robot Framework does fit those criteria. But I'd argue that Robot Framework isn't really low code, but rather a coded framework in a low code trench coat.

[hitchstory]

Thanks, that's very helpful.

1 and 2 make perfect sense and are easy do demonstrate but 3 seems to me to be incredibly difficult.

I haven't found an easy way to advertise convincingly to somebody who (quite reasonably) grants you a limited amount of attention that custom things won't be a nightmare. It's the kind of thing you only tend see when you get dug in the weeds and hence people will tend to make assumptions based upon surface details.

This is a problem I'm struggling with.

I think robot/cucumber could require less code if they were better abstractions (and would be more loved), but I find it hard to illustrate that an abstraction is going to be good or bad, particularly to people with limited attention and particularly to people who don't necessarily have the skills to recognize a good abstraction.

[marcosdumay]

> I haven't found an easy way to advertise convincingly to somebody who (quite reasonably) grants you a limited amount of attention that custom things won't be a nightmare.

I'd say, have a highly emphasized set of examples of the things people are most likely to want to customize.

You probably don't want to put the examples inline with your basic description, but link them there.

[hitchstory]

Thanks!