At least for testing, and traditional automation (aka code) the bar is knowing what you're doing AND knowing the product enough to be able to test it effectively.
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.
Completely agree that testing should be more accessible to product managers and designers, and love the concept. Consider the simple example of a web form with multiple `input` elements - if I use your product to click on each input and configure a QA procedure, how does the system unambiguously identify each input given that the page layout may change in the future?
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?
It identifies things visually, and optionally with OCR as well. If it moves likely no issue. Changing shape or size too much, as well as not matching OCR can cause failures - as expected. If it is an expected update and the test needs updating, we smartly suggest updates to the target if we can find one. Alternatively we have a crowd-based service to help write abs maintain your tests; itβs usually used by teams needing high leverage when managing a lot of tests.
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.