Great question, @froberts!
In my opinion, it depends on the application under test.
If the application is one built and maintained by an organization (such as a website), more flexibility may be required. I assume testers have access to all parts of the application. In that case, they can decide the types of testing and automation to apply. I might follow the testing pyramid an have lots of unit tests that explore business behavior.
Moving up the pyramid, some manual or automated tests can explore the UI as well as security, configuration, and connectivity. If the UI is complex, codeless automation products would make less sense to me.
If the application is provided by a vendor (as in my case), I may not need much flexibility. In this case, no one has access to the code of the application. The application has defined workflows that multiple clients use; we have only to configure the application for our specific use.
I would welcome a codeless automation product that allows our testing team to start “testing” immediately. There is not behavior to evaluate (behavior is already tested by the vendor) rather we need to confirm the configurations. Hopefully, those configurations exhibit some evidence through the UI which testers can confirm.
I’m at the start of this journey and today, I believe I will use a combination of codeless automation and other techniques for evaluation in my context.
The more I wrote about this, the more dimensions I started to consider (a good thing!). I hope this provides a peek into how I’m viewing this build vs buy decision.