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.