Use ego (lite) with Codex or Claude Code to turn a plain-English test brief into real test automation. Your Agent opens your app in a real browser, follows the flow you specify, records what happened, and gives you a clear result you can review — without taking over the tabs you are using.
Trusted by developers from
Use this four-step test automation process for a local, staging, or production-safe web app you are authorized to test. The Agent works in a separate browser Space, so you can watch a run, take over when a human decision is required, and keep your normal tabs clear.
Download ego (lite), then choose the browser context you want to use. For tests with real side effects, point the Agent at localhost, a test account, or a staging environment — the same safety boundary you would use for a manual check.
Tell the Agent which URL to open, the user journey to follow, the data or account it may use, and what success looks like. A precise brief can cover a login flow, form validation, cart, checkout sandbox, search, dashboard, or any other repeatable browser task.
What should it test?
The Agent opens the app in its own ego (lite) Space and performs the test automation steps in a real browser. You can inspect the rendered page, console state, and progress while the test runs, without losing the tabs you were already using.
Ask for a concise report with the route tested, steps completed, expected versus actual result, screenshots or source references where useful, and a clear failure point. After a fix, send the same test automation prompt again to verify the path rather than relying on memory.
ego (lite) gives your coding Agent a real, visible browser for software automated testing. Instead of a black-box test runner, you get separate Spaces, an observable test path, and an outcome that tells you what actually happened on the page.
Every browser step adds to the time between your test brief and the result. In the task shown here, ego (lite) finished in 81.8 seconds, compared with 282.9 seconds for an agent browser. Actual time varies by website, workflow, and network conditions.
Use a separate Space for each feature, account role, viewport, or regression scenario. Test automation stays organized instead of mixing state across a pile of browser tabs, and you can return to the exact Space where a run stopped.
Open any Space to see the current page and the step the Agent is trying to complete. If a workflow reaches MFA, a payment confirmation, a destructive action, or another decision that should stay human, take over the browser and decide what happens next.
Reuse a browser context you choose for roles or test accounts that need a signed-in flow, rather than handing credentials to a test-automation service. Your app's access controls, MFA, rate limits, and permission checks remain in effect; ego (lite) does not bypass them.
ego (lite) helps an Agent execute the test procedure you define in a browser context you authorize. It can inspect a web flow and report its outcome, but it does not make an unsafe test safe, infer a product requirement you did not state, or bypass your app's access controls.
Repeatable web application paths you authorize it to open and inspect.
Unsafe, irreversible, private, or ambiguous actions remain under your control.
Start with one safe user journey, state the expected result, and let Codex or Claude Code execute it in an observable ego (lite) browser Space. You get a test result you can inspect, rerun after a fix, and turn into a more reliable release habit.
Try the test automation workflowTest automation in software testing is the use of software to repeat a defined test procedure and compare the observed result with an expected result. For a web app, that can mean opening a page, completing a form, checking validation, signing in with a test account, or confirming that a checkout sandbox loads. The useful part is not simply clicking faster: the test must state what it checked and report what actually happened.
An automatic test is a repeatable check run by software instead of being performed entirely by hand. In browser testing, it starts from a known state, takes a defined action, checks an expected result, and records whether the check passed, failed, or could not continue. A single automatic test is usually one part of a wider test automation process.
Give Codex or Claude Code a clear test brief, a safe URL, and the expected outcome. The Agent opens the app in a separate ego (lite) Space, carries out the browser steps, and returns a report of completed checks, visible errors, and any point where it was blocked. You can inspect the Space or take over at any time.
Software automated testing can cover repeatable checks at different levels, from small code-level tests to browser-level user flows. This ego (lite) workflow focuses on the browser layer: rendered pages, navigation, forms, authenticated test flows, visible client errors, and network failures. It complements rather than replaces unit, integration, security, performance, or accessibility testing that needs a dedicated method.
The need for automation in software testing grows when the same important paths must be checked after many changes, across account roles, or before every release. Automation reduces repetitive setup and makes the result more consistent, while people keep ownership of unclear requirements, exploratory judgment, and any step with real-world consequences. Start with stable, high-value paths rather than trying to automate every click at once.
An autotest check is one explicit condition an automated test evaluates. A useful definition names the starting state, action, expected result, and evidence to retain. For example: “Using the staging buyer account, add the first item to the cart; the cart count becomes 1 and the checkout page loads without a console error.” Clear checks make automated test execution reviewable and repeatable.
You do not need to write a test framework to begin, but you do need a clear scenario. Start with one stable user path, safe test data, and a sentence that says what should happen. Then add the URL, numbered actions, expected results, and a rule to stop before any real charge, message, deletion, or account change. This is a practical foundation for test automation development.
An automation tester defines the useful checks, prepares safe test data, reviews failures, and decides what should run next. An AI Agent can carry out the browser procedure, collect evidence, and help investigate a failure, but it does not replace the person who understands the product requirement and release risk. The strongest workflow keeps those roles explicit.
Not quite. An automated test evaluates a specific expected result, such as whether a form blocks an invalid email address. Automation assessments are a broader review of what is worth automating, whether the scenario is stable, what data it needs, and whether its side effects are safe. Use that assessment before adding a workflow to your recurring test automation set.
Yes, when you use a browser context and test account you are authorized to use. Prefer a staging environment and isolated test data for logged-in flows. The Agent can work with the session the browser is allowed to use, but it does not bypass MFA, permissions, CAPTCHA, rate limits, or other access controls. If a human-only step appears, inspect or take over the Space yourself.
An Agent can run the browser test, inspect the evidence, and help investigate or change code when you authorize that work. Keep the test and verification explicit: after a proposed fix, rerun the same scenario and compare the new result. For production systems, review code changes and use your normal test, review, and deployment controls before shipping.
A test automation framework runs scripted checks you write and maintain in code, usually inside a CI pipeline. With ego (lite), you describe the scenario in plain English and a coding Agent performs the steps in a real, visible browser, so you can create or change a check without editing a test script. The two approaches complement each other: keep coded suites for fast, deterministic CI runs, and use an Agent-driven run when you want a quick, observable check of a user journey or a one-off investigation.
Yes, for browser-level checks. Save the test automation prompt for a critical path — sign-in, search, checkout sandbox, or a core dashboard view — and send the same prompt again after each change as a smoke or regression check. Because the brief, the steps, and the expected results are written down, each rerun tests the same path the same way, and the report shows exactly where a regression appeared.
Do not automate a path that can create an irreversible real-world effect unless you have a safe fixture, sandbox, or explicit approval step. Avoid using a production customer account for orders, billing, messages, deletion, permission changes, or sensitive data. Also keep exploratory product judgment separate from a pass/fail procedure: an Agent can gather evidence, but a vague requirement still needs a human decision.