Manual QA knowledge needs an execution engine
Enterprise test automation, without an automation team
Enterprise applications are the ones that defeat no-code tools: a second factor at the door, fields that rewrite what you type, dropdowns that are not dropdowns, and journeys that run for forty steps. Here is the mechanism for each, rather than a reassurance.
One thing we do not offer
AtwalLabs does not support SSO for signing in to AtwalLabs itself. An account is a password plus a mandatory authenticator app — every account, no exception, from its first second. The SSO on this page is the one in front of YOUR application, which is a sign-in the engine drives like any other.
Six obstacles, and what actually handles them
The application is behind a sign-in with a one-time code
The login path recognises a one-time-code prompt — an OTP input or the text that accompanies one — and records what it found in login-diagnostics-step-N.json. You are told the run stopped at the second factor, rather than getting "element not found" at step 3.
Fields reformat what you type — dates, policy numbers, card numbers
A masked field is typed as KEYSTROKES rather than pasted, because a mask plugin only sees keystrokes. If the mask rejects some characters the engine detects the partial value instead of assuming the fill worked, and a mask that reformats or extends the value is left alone rather than re-filled.
Dropdowns are not <select> elements
Element resolution tries select and combobox roles BEFORE text inputs, so "Select Coverage from Policy Type" finds the dropdown rather than a text box beside it. A control it is not confident about is refused, not clicked.
A journey is forty steps across six screens
A case can continue the previous case’s browser session, so the pack signs in once and each case starts where the last one finished. Values read on one screen can be asserted on a later one, which is how continuity gets checked rather than assumed.
The application is not reachable from the public internet
There is a Dockerfile in the repository and a self-hosted deployment is supported, so the engine runs inside your network with your own database and your own artefact store.
Our data must never be visible to another customer
Every query on an organisation-scoped table carries the organisation id, and a request for another organisation’s record answers 404 rather than 403 — so a probe cannot even confirm that the record exists. Run evidence is stamped with its owning organisation when the directory is created, and served only to that organisation.
What an auditor gets
Every run writes its own directory, and this is the listing rather than a description of one. It is the same evidence whether a run passed or failed.
- progress.log— every step, every guard, every navigation, timestamped to the millisecond
- summary.json— per-step status and the resolution strategy that chose each element
- recording.webm— video of the session
- console.txt— the browser's own console output
- network-failures.json— requests that failed during the run
- step-N.png— a screenshot per step
Exported as a Word report, so a release gate can hold a document rather than a link into a tool an auditor has no account for. What is guaranteed, and where the data sits, is written down in Guarantees.
The regression side of this is on running the BAU pack every release, and the team side on who does what. Talk to us through Contact.
The same product, from another angle
- Automate manual test casesThe test case you already wrote, run as it is written — with a step log and evidence.
- From a spreadsheetUpload the sheet you already maintain. Two columns, one row per case.
- For manual testersYou already know how to test. This is the execution engine for that knowledge.
- Playwright without the codePlaywright executes it. You never open a test file.
- Regression suitesRe-run the BAU suite on every release and compare it against the last one.