The benefit of using code is that you have to know what you are doing. Having experienced what happens when people build data driven systems out of building blocks, with out a thorough understanding of what they are doing (brittle, failing is strange ways under load, general unreliability and low quality) I am suspicious
We remove the code requirement, making testing accessible to more folks - i.e. product managers and product designers who have great knowledge of the product, but don't want to or can't code. Also, this doesn't tend to exclude developers either. Currently our user base is roughly 1/3rd engineers, 1/3rd product managers/designers, and 1/3 QA folks.
The current code-based testing frameworks force me to add an unambiguous marker to the `input` element, like an attribute or ID, which also makes it easy to query from the DOM during the QA process. How does this QA product handle breaking changes to the UI, and how robust could you expect it to be to code changes?
Code is more upfront effort but more control and thus less fragility but more maintainable over time (if done right).
I imagine there are some/many situations where throwing many people at a problem is the “best” way and this would suit that quite well I guess.
Of course, until automation gets to be as clever of humans, any test automation approach is going to have some flavor of brittleness.