Frequently asked
questions

Klarent is fore ai's autonomous AI-powered testing platform. It tests web and mobile applications the way a human QA engineer would - only faster, smarter, and without ongoing maintenance. You describe what to test in plain English, and Klarent's AI agents generate, execute, and self-heal tests automatically. Teams typically cut testing effort by up to 90% and ship 3–5× faster.

Klarent is built for enterprise engineering and QA teams across finance, insurance, travel, retail, media, and SaaS, covering a wide range of QA automation use cases. Because tests are created from plain-language prompts, even non-developers and non-QA professionals can create and run reliable tests - no scripting background required.

Teams using Klarent typically reduce manual testing effort by up to 90% and accelerate release cycles by 3–5×. Because test creation requires no code, QA coverage expands across teams that previously lacked the engineering capacity to automate.

Klarent uses an annual license model that scales with your usage - specifically the number of generated tests and test runs. Contact the fore ai team to discuss a plan that fits your team size and testing volume.

Yes. You can explore Klarent for free at app.klarent.ai, or request a live demo with the fore ai team to see the platform applied to your specific applications and workflows. The demo includes a walkthrough of test creation, execution, and self-healing.

Klarent integrates with GitHub, GitLab, Bitbucket, Jenkins, Azure DevOps, Jira, Linear, Slack, and Microsoft Teams - covering the full CI/CD, test management, and collaboration workflow. Custom API integrations are also supported.

Klarent covers the full spectrum of browser-based applications - customer portals and self-service platforms, complex transactional flows (banking, e-commerce, and insurance application testing), internal enterprise tools (CRM, ERP, HR systems), multi-system workflows with API and data dependencies, and responsive cross-browser interfaces.

Klarent runs tests across Chrome, Firefox, Safari, and Edge in parallel, covering desktop, mobile, and tablet viewports. A single test suite validates your application's behavior and visual consistency across all major browser engines and screen sizes.

Klarent's self-healing automation detects UI or logic changes and automatically adapts locators and test logic - no manual intervention needed. When a heal is available, it is flagged in the run dashboard and can be applied in one click.

Yes. Klarent's autonomous capabilities include visual validation and accessibility checks alongside standard functional testing. Regressions in layout, styling, or accessibility compliance are caught automatically.

Absolutely. Klarent connects to GitHub, GitLab, Bitbucket, Jenkins, and Azure DevOps, triggering continuous integration testing on every pull request or commit. You can enforce quality gates and receive real-time feedback through Slack or Microsoft Teams.

Klarent can generate end-to-end tests, regression suites, cross-browser compatibility checks, API and data validation flows, and modular reusable test cases.

Automated accessibility testing checks a web application against accessibility rules, such as WCAG success criteria, as part of a test run instead of a manual audit. In Klarent, those checks run inside the end-to-end tests you already have, so every journey is checked on every build.

Klarent maps findings to WCAG 2.1 and 2.2 success criteria at levels A, AA and AAA. Automation covers the rule-based criteria at each level, such as colour contrast, missing labels and ARIA usage. Criteria that depend on human judgement still need a manual review.

No. Automation catches rule-based issues early and on every release, but some criteria, such as whether alt text is meaningful or how a flow works with a screen reader, need a manual or assistive technology review. Automated checks shrink that manual work and keep it focused.

No. Accessibility checks are turned on inside your existing end-to-end tests, so there is no second suite to write or maintain.

Failures are categorised and triaged instead of being dumped as a raw list, and each one is mapped to a severity and a WCAG criterion, so the team sees the blocking issues first.

Yes. Checks run on every journey, on every build, and can run on every pull request. You can gate merges on new critical violations only, so existing issues do not block every change.

Accessibility checks run on web journeys, including mobile and tablet viewports. Native iOS and Android apps are tested through Klarent mobile app testing.

Every run records which checks passed and failed, mapped to WCAG criteria, and trend reporting shows accessibility results release over release. That history can be shared as audit evidence.

Cross-browser testing checks that a web application works the same way in every browser your users open. Browsers use different rendering engines, so a journey that passes in Chrome can still break in Safari or Firefox. Browser compatibility testing catches those differences before users do.

Klarent runs tests on Chrome (Chromium), Firefox, Safari and Edge, across desktop, tablet and mobile viewports. Each test suite can be configured with its own set of browsers and viewports.

No. You write the test once in plain English, and the same test definition runs across every browser in the matrix. There are no per-browser copies to maintain.

Every combination runs in parallel, in its own isolated environment, with no cap on concurrency. Adding browsers to the matrix adds coverage without adding much wall-clock time, so a full-matrix run takes about as long as the slowest single run.

Cross-browser testing checks functional behaviour: that clicks, forms, navigation and outcomes work in every browser. Visual regression testing checks appearance, comparing each page against a known-good baseline. Most teams need both.

Tests run on tablet and mobile viewports alongside desktop. Testing on real mobile devices and native apps is covered by Klarent mobile app testing.

Yes. Trigger suites from your CI/CD pipeline on every pull request. A common approach is to run your top browsers on each PR and the full matrix on every release.

Where behaviour legitimately differs between browsers, the test can assert on the expected difference for that browser instead of treating it as a failure.

End-to-end testing checks a complete user journey through your application, the way a real user would, from the first page to the business outcome. Signing up, completing a purchase or submitting an application are typical end-to-end tests, and checkout is where most ecommerce test automation starts.

Functional testing checks that one feature works as specified. End-to-end testing checks that a whole journey works across many features, pages and systems. Both are automated in Klarent the same way, from plain-English instructions.

Setting up a test typically takes under five minutes. You describe the journey in plain English, and the AI agent generates the executable test step by step, verifying each step against your live application as it goes.

Every run starts in a fresh, isolated environment, each step is verified against the live app when the test is generated, and self-healing proposes fixes when the UI changes instead of letting the test fail on a moved element.

Yes. Tests are written as plain-English instructions, so manual testers, product owners and business teams can author them without scripting.

Any environment your team can reach. The same test can run against staging, pre-production or production by overriding the URL at trigger time, from the Klarent UI or from your CI/CD pipeline.

Variables and secrets hold the data a journey needs, like accounts, products or card details, and can be overridden per run. Reusable modules and browser states handle shared setup such as logging in, so long journeys do not repeat the same steps.

Yes. Journeys can continue beyond your own application, for example into an email inbox, an SMS code or a third-party system, which is common in test automation for travel booking, so the whole flow is tested end to end.

You describe the flow in plain English, or start from an input like a user story or PRD. The AI agent opens your app and builds the test one step at a time: it reads the current state of the page, writes the next step and the code to run it, executes that code, and checks a screenshot against the expected outcome before moving on. It repeats until the instructions are fulfilled.

Every step is executed and verified against the live application while the test is being generated, so a step is only kept once it actually works. If a step fails, the agent reworks and re-runs it. A human then reviews the finished test before it joins the suite.

Yes, and that is by design. Generated tests and suggested scenarios are reviewed and accepted before they enter the suite, so engineering keeps control of what runs.

Plain-English instructions, user stories and Jira tickets, PRDs and spec sheets, Figma links, website URLs, existing tests, and recorded walkthroughs of the app.

Yes. Manual QA engineers, business analysts and product owners can write tests as plain English test steps, with no scripting or locators involved. Review and approval keep quality control with engineering.

Yes. Edit the instruction on any step, and the agent regenerates the test from that point, leaving earlier steps untouched. You can also correct a test while it is still generating.

Record and playback captures raw clicks tied to the exact page structure it was recorded on, so recordings break when the UI changes. Klarent produces named, readable steps with assertions, verifies each one against the live app, and self-heals when the UI changes.

Yes. The agent generates each step against the application's current state rather than a fixed script, and reworks steps that fail. Browser states, reusable modules, variables and secrets handle logins, shared setup and data-driven flows.

Automated regression testing reruns your existing tests after every change to check that features which worked before still work. Instead of testers repeating the same checks by hand each release, the regression suite runs automatically from CI, on a schedule, or on demand.

A common pattern is a small smoke suite on every pull request, the regression suite nightly and on every deploy to staging, and the full suite on every release candidate.

Tests run in parallel with no cap on concurrency, so a full run takes roughly as long as the slowest test rather than the sum of all of them. As an example, ten tests that would take around 100 minutes by hand finish in 2 to 3 minutes.

Most breaks come from the UI changing, not the feature: renamed elements, new IDs or moved locators. Self-healing repairs those steps against the latest application flow, so the test keeps passing without a manual rewrite.

Start with revenue and conversion paths, then the areas changed in the last two releases, then integration points and workflows that have broken before. Leave one-off checks and fast-changing prototypes to exploratory testing.

Every run starts in a fresh, isolated environment, which removes a common source of flakiness. Failure triage separates real regressions from flaky tests and environment noise, and each failure comes with screenshots and traces so it can be diagnosed quickly.

Much less of it. Automation takes over the repeated checks every release needs, which frees testers for exploratory testing and judgement calls that automation does not cover well.

Smoke testing is a small, fast check that a build is not broken in its most critical paths, usually run on every pull request. Regression testing is broader, checking that everything which worked before still works, and usually runs nightly or before a release.

Lightning generates dynamic, deeply nested markup with identifiers that change between page loads, releases and customisations. Selenium tests depend on those selectors, so they break constantly, and asynchronous loading makes them act before the page is ready.

Klarent tests through the browser, the way a user does, so it needs a user login for the org or sandbox you want to test. Credentials are stored as secrets, encrypted at rest and masked in logs and screenshots.

Yes. Custom objects, custom fields and Lightning Web Components are tested through the UI like any other part of the org, without hand-built selectors.

Salesforce ships three seasonal releases a year: Spring, Summer and Winter. Run your suite against a preview sandbox before the release reaches production. Where the release changes the UI, self-healing repairs the affected steps so the suite keeps running.

Yes. Admins and business users describe processes in plain English, and the AI agent builds the executable test. Engineering reviews and approves tests before they join the suite.

Yes. A single test can follow a process from Salesforce into an ERP, a billing system or a custom web app, so the whole journey is tested the way it actually runs.

Yes. Point tests at any sandbox by setting or overriding the URL, so the same suite can run against a developer sandbox, a preview sandbox or production.

Klarent tests through the user interface. Apex logic is covered by the behaviour it produces in the UI, such as records created, fields updated or validation errors shown, while Apex unit tests stay part of your Salesforce development process.

Enterprise application testing checks that packaged business systems like SAP and Oracle, and the custom apps around them, support the business processes that run on them. It focuses on end-to-end business process testing, such as order to cash or procure to pay, rather than individual screens.

Klarent tests SAP through its browser-based interfaces, including SAP Fiori apps and S/4HANA web screens, the same way a user works with them.

Yes. Klarent tests the browser-based pages of Oracle Fusion Cloud and Oracle E-Business Suite, including processes that continue into other systems.

Yes. A single test can follow a process from SAP into a CRM, an Oracle system or a custom web app, so cross-system workflows are tested the way they actually run.

Run the suites for the affected processes against the updated system. Where the update changes the UI, self-healing proposes fixes and shows the diff for review, so the suite keeps running instead of breaking with every release cycle.

Yes. Business users describe the process in plain English, and the AI agent builds the executable test. Engineering reviews and approves tests before they join the suite.

Credentials and sensitive values are stored as secrets, encrypted at rest and masked in run logs and screenshots. Klarent can be deployed in the cloud, a private cloud or on-premises, so data can stay inside your network.

It depends on how many processes and systems are in scope. A practical approach is to start with one end-to-end business process as a proof of value, then expand to the processes that carry the most financial and compliance risk.

Klarent tests native, hybrid, and cross-platform mobile apps on both iOS and Android. Supported frameworks include Swift, Kotlin, Flutter, React Native, and Java.

Getting started takes three steps: upload your APK or IPA file, describe what to test in plain English, then run across multiple real devices in parallel and receive results with screenshots, logs, and video recordings.

No. Klarent abstracts away the complexity of Appium and Selenium entirely. Tests are described in plain-English prompts - no scripting, no XPath selectors, no driver configuration.

Each failure comes with rich diagnostic context: screenshots at the point of failure, full execution logs, and network traces.

Yes. Klarent supports cloud and on-premises deployment. Tests execute inside your environment, so no application data or internal traffic leaves your network.

Klarent's self-healing AI automatically adapts locators and test logic when UI elements move, change label, or are restructured. Tests remain stable across releases without any manual rework.

Upload an APK or AAB (or connect your CI pipeline), describe the flow you want to test in plain English, and Klarent's AI agent generates the executable test. From there it runs across your chosen emulators or real devices, in parallel, and reports back with full run evidence.

No. Klarent runs entirely in the cloud - upload your build or pull it from your pipeline, and Klarent handles execution. There's nothing to install locally.

Use emulators for fast, parallel feedback on every commit, and real devices to catch OEM- and hardware-specific issues before a release.

Klarent covers a broad matrix of Android API levels and OEM devices out of the box, and you can pin a specific matrix per suite or release so coverage matches what your users are actually running.

Yes. Upload either format directly, or pull the build straight from your CI/CD pipeline.

Espresso and Appium require you to write and maintain scripts by hand, and locators break every time the UI changes. Klarent generates tests from plain-English descriptions and self-heals locators automatically, so there is no scripting and far less maintenance.

Klarent's self-healing locators detect the change - a moved button, a renamed label, a restructured screen - and adapt the test automatically, so it keeps passing without manual rework.

Yes. Trigger Klarent from Jenkins, GitHub Actions, GitLab CI, Azure DevOps, Bitrise, or Fastlane, and gate a release build on a critical-path suite.

Yes. Alongside native Android (Kotlin, Java), Klarent supports cross-platform builds like React Native and Flutter, as well as mobile web in Chrome on Android.

Minutes. Upload an APK or AAB, describe your first flow in plain English, and run it - no framework setup or driver configuration required.

Upload an IPA (or connect your CI pipeline), describe the flow you want to test in plain English, and Klarent's AI agent generates the executable test. From there it runs across your chosen simulators or real devices, in parallel, and reports back with full run evidence.

No. Klarent runs entirely in the cloud - upload your build or pull it from your pipeline, and Klarent handles execution. There's nothing to install locally, and no Mac or Xcode required on your end.

Klarent covers the current and recent iOS releases out of the box, and you can pin a specific version matrix per suite or release so coverage matches what your users are actually running.

Use simulators for fast, parallel feedback on every commit, and real devices to catch hardware and sensor-specific issues - Face ID, camera, GPS - before a release.

An IPA file. Upload it directly, or pull it straight from your CI/CD pipeline.

Yes. Point Klarent at your TestFlight build to validate the exact artifact your beta testers and App Store reviewers will see.

XCUITest requires you to write and maintain Swift scripts by hand, and locators break every time the UI changes. Klarent generates tests from plain-English descriptions and self-heals locators automatically, so there's no scripting and far less maintenance.

Klarent's self-healing locators detect layout and behavior changes from the new OS release and adapt the test automatically, so your suite keeps passing without manual rework.

Yes. Klarent tests iPhone and iPad form factors from the same suite, including orientation changes and split-view behavior.

Yes. Trigger Klarent from Jenkins, GitHub Actions, GitLab CI, Azure DevOps, Bitrise, or Fastlane, and gate a release build on a critical-path suite.

Upload your Flutter iOS and Android builds (or connect your CI pipeline), describe the flow in plain English, and Klarent identifies widgets visually - the way a user sees them - rather than relying on widget keys. One test runs on both platforms and reports back with full run evidence.

No. Klarent identifies widgets visually and by intent, so your app team does not need to add or maintain widget keys or semantic labels for automation to work.

No. Klarent tests are described in plain English, not Dart. There is no Flutter integration test code for QA to own or maintain.

Flutter integration tests live in Dart and are typically written and owned by app developers. Klarent tests are authored in plain English, identify widgets visually instead of by key, and self-heal automatically when the app changes.

You do not need it. Klarent replaces the Appium Flutter driver entirely, so there is no second toolchain to install, configure or maintain alongside your test suite.

Klarent supports current and recent stable Flutter SDK releases, and self-healing locators keep tests passing through SDK upgrades.

Yes. Klarent runs a single Flutter test across iOS and Android from the same codebase, and reports results per platform.

Klarent identifies custom-painted and animated widgets the way a user would - visually and by intent - so flows that standard element locators miss are still testable.

Upload your iOS and Android builds (or connect your CI pipeline), describe the journey once in plain English, and Klarent runs the same test on both platforms - including any WebView screens in the flow - and reports results per platform.

No. Klarent identifies elements by intent, not by hard-coded testID or accessibility-label props, so there is nothing extra for your developers to add or maintain.

Yes. Klarent authors one test from a single description and executes it on both platforms, with per-platform assertions available for the moments where iOS and Android genuinely diverge.

Both. Klarent supports bare React Native and Expo apps, including development and release builds, whether you build with EAS or your existing CI/CD pipeline.

Klarent detects and switches between native and WebView context automatically inside a single flow, so a test can move from a native screen into an embedded checkout or web content without extra setup.

Detox requires JavaScript/TypeScript test code and testID attributes that your developers maintain. Klarent tests are described in plain English, identify elements by intent, and self-heal automatically through React Native and dependency upgrades.

Klarent's self-healing locators detect the changes an upgrade introduces to the element tree and adapt the test automatically, so it keeps passing without manual rework.

Yes. Klarent tests native module and bridge behavior, including camera, storage, biometrics and permission prompts, alongside standard React Native UI flows.

Not because of technical limitations - because of maintenance. Locator failures from app updates, device and OS upgrades, and flaky environmental failures pile up until teams cut scope just to fit a release window.

Self-healing execution repairs broken steps mid-run, so a locator change or UI update does not take the whole suite down. There is no manual patching between releases.

Both are supported. Selective execution targets only the scenarios touched by recent code changes for fast feedback, while full parallel runs cover the entire suite inside the release window when you need complete coverage.

Automatic failure triage separates genuine regressions from environmental noise - timing issues, network conditions, device-specific quirks - before anyone has to investigate manually.

Revenue-critical workflows like authentication, transactions and payments, the core of financial application testing; scenarios that need real hardware or system permissions; and screens changed in the last two releases, where regressions are most likely.

Yes. Trigger the full regression suite from your CI/CD pipeline on every release build, and gate a release on a critical-path suite passing.

Yes. Trend analytics track coverage and pass-rate progression release over release, so a slow decline in suite health shows up before it becomes a real problem.

Running the relevant mobile test suite automatically against every pull request, the same way web teams have tested every PR for years, so bugs are caught before merge instead of at the release-candidate stage.

Yes. Klarent triggers from your existing pipeline on every PR, commit, or scheduled build, and runs a suite scoped to the change so feedback stays fast.

Minutes, not hours. Selective execution runs only the scenarios relevant to the change, and devices execute in parallel, so PR feedback lands inside a few-minute window.

Yes. Define a critical-path suite and Klarent gates the merge on it - a failing critical test blocks the PR until it is resolved.

Jenkins, GitHub Actions, GitLab CI, Azure DevOps, CircleCI, Bitrise, and Fastlane, with results posted back to Slack, Microsoft Teams, or Jira.

Pull the build straight from your pipeline, upload it directly, or push it through the API - whichever fits how your signing and provisioning already works.

PR checks run a selective, critical-path suite for fast feedback. Nightly or release runs can cover the full regression suite for complete coverage before a release.

Yes. Concurrent PRs run in parallel without test data or device collisions between them, so one long-running PR does not block the next.

Running your mobile tests on physical iOS and Android devices hosted in the cloud, instead of only on emulators or simulators, so results reflect what a real user's hardware actually does.

Emulators are fast and cheap for everyday functional checks. Real devices catch what emulators approximate - touch and gesture behavior, camera and biometric flows, battery and thermal state, and OEM firmware quirks. Klarent runs the same test on either, so you are not choosing once and living with it.

A broad matrix of current and recent iOS and Android devices and OS versions is available out of the box, and you can pin a specific matrix per suite or release.

Yes. Klarent supports cloud, on-premise, and hybrid device pools, including dedicated private pools for teams that cannot share hardware.

Runs execute across your device and OS matrix in parallel, with a clean device state reset between runs, so parallelism does not come at the cost of reliability.

Yes. Every device gets a clean state reset between runs, and enterprise controls - SSO, role-based access and audit trails - are available for regulated environments.

Yes. Real device execution covers camera capture, Face ID, fingerprint and other hardware-dependent flows that emulators cannot fully replicate.

Yes. Klarent can simulate slow networks, drops and interruptions to validate how the app behaves and recovers under real-world conditions.

Yes. Tests are authored once and run on either target - there is no separate test code to maintain for emulators versus real devices.

Traditional test management tools store and track tests written by humans. Klarent autonomously creates and maintains those tests, eliminating up to 90% of the manual work that conventional tools assume your team will handle.

Yes. Klarent's test management platform gives you projects to separate applications or teams, test suites to group related tests, and folders and subfolders that mirror your team's workflow - a structure that scales cleanly for SaaS application testing where every tenant needs its own isolated suite.

Yes. Klarent's scheduled execution feature lets you plan test runs on any cadence - daily, nightly, or custom. Upcoming runs are visible in a unified dashboard.

Results update in real time with analytics covering coverage trends, test stability, flaky test identification, and regression history, the kind of audit trail that matters most for insurance application testing where every failed check needs a record. Failure alerts are pushed to Slack or Microsoft Teams. Jira and Linear integrations automatically create tickets from failing tests.

Yes. Klarent supports enterprise role management (RBAC) and Single Sign-On (SSO), with granular access controls and full audit logs.

Yes. Klarent's latest activities feed gives you a live view of recent updates, test executions, and healing events across your entire testing workspace, useful for banking application testing teams that need a single place to see everything running at once.

Variables are local parameters scoped to a single test - useful for URLs, usernames, or dynamic inputs. Secrets are global, encrypted parameters available to every test in a project, designed for passwords, API keys, and other sensitive credentials that must never appear in logs or test output.

Type @ in any test step field to bring up a list of available variables, secrets, and assets from your test data management platform, including the fare codes and dates that shift constantly in test automation for travel booking. Select the one you want and Klarent inserts the reference automatically. The actual value is injected at run time.

No. Secret values are encrypted at rest and masked in all test output, run logs, and screenshots. Only the secret name is shown in step definitions and results.

Klarent supports any file type as an asset - images (PNG, JPG, WebP), documents (PDF), data files (CSV, JSON), and more, the same file types a checkout flow needs for ecommerce test automation. Uploaded assets are available to all tests in the project and referenced with the @ symbol in any file upload step.

All tests run inside your own environment using multi-layer encryption, granular RBAC, and complete audit logs. No customer data leaves your network. Klarent is certified under ISO 27001 and SOC 2, and complies with GDPR.

Klarent is ISO 27001 certified and SOC 2 compliant. These certifications cover data handling, access controls, availability, and security operations. Details are available at the fore ai Trust Center.

Yes. Klarent supports both cloud and on-premises deployment based on your infrastructure and compliance requirements.

Klarent is an AI test automation company. We build an AI-powered software testing platform that lets enterprise teams automate the entire testing lifecycle with autonomous AI agents, across web, iOS, and Android applications.

Yes. fore ai is the company's former name, and Klarent is the name we use today for both the company and the platform. You may still see fore ai on our LinkedIn page, in older articles, and in some official documents.

Klarent was founded in 2023 by Asheem Panakkat (Co-Founder & CEO) and Momchil Ivanov (Co-Founder & CTO). Both are former Google engineers: Asheem spent 12 years at Google leading engineering teams on products like Google Shopping and Google Maps, and Momchil spent nearly eight years there as a Staff Software Engineer focused on information retrieval.

Klarent is headquartered in Zurich, Switzerland, at Hardturmstrasse 161, 8005 Zürich.

Yes. Klarent is SOC 2 compliant and ISO 27001 certified, and complies with GDPR. Data is encrypted in transit and at rest, and Klarent can be deployed in the cloud, a private cloud, or on-premises. Full details are available in the Klarent Trust Center.

Script-based tools need engineers to write and maintain test code, and those scripts break whenever the UI changes. With Klarent, you describe what to test in plain English, and a team of AI agents explores your app, plans the test, writes it, and verifies the result. When the UI changes, tests self-heal instead of failing, so there is no suite of scripts to maintain.