What Test Executor is
Test Executor runs functional tests against a web application from test cases written in ordinary language. A step reads like an instruction you would give a colleague:
Click the 'Add to Cart' button on the 'Roaster's Choice Box' panel.There is no locator to maintain, no page-object model, and no programming language to learn. At run time an AI looks at the rendered page — the actual pixels and the live DOM — decides which control the step means, and interacts with it.
Who it is for
Functional QA analysts. If you can describe a test to another tester, you can automate it here. Traditional automation frameworks require an engineer to translate that description into code; Test Executor removes that translation step, which is usually where automation programs stall.
What makes it different
| Traditional automation | Test Executor |
|---|---|
| Selectors written and maintained by hand | Elements identified from the screen at run time |
| A UI change breaks the script | The engine adapts, and tells you what drifted |
| Requires an automation engineer | Requires someone who understands the application |
| A failure means "something broke" | Failures are classified: app defect, test defect, environment or data |
A note on expectations
The engine is genuinely good at finding controls, but it is not magic. Clear, specific steps produce far better results than vague ones. This guide shows you what "clear" looks like, and the product warns you when a step is ambiguous.