Automation Testing Services for Website and Mobile App Development
Automation testing is the practice of encoding a product's expected behaviour as executable checks that run on every change, so regressions are caught by a machine rather than by a customer. Mixcore Studio builds and maintains those suites for web and mobile products, in Playwright, Appium and k6, as portable code that lives in your repository and runs in your CI rather than inside a vendor's cloud.
We have shipped production software for more than 8 years across web, mobile and enterprise systems, and automation is engineering work: locators, fixtures, test data, parallelism, CI economics and reporting. The tooling has changed sharply in the last two years, so the sections below are specific about what we now use, what we have stopped using, and where automation is the wrong answer.
The 2026 automation stack, and what we build with it
Playwright is no longer one option among several. It is the default browser-automation runtime by roughly an order of magnitude. npm registry download figures for the week of 3 to 9 August 2026 record 80,091,572 weekly downloads for playwright and 52,792,524 for @playwright/test, against 11,502,491 for puppeteer, 7,360,936 for cypress, 3,142,779 for webdriverio, 2,045,892 for selenium-webdriver and 215,701 for testcafe. We start greenfield suites on Playwright, currently 1.62.1 released 30 July 2026, unless there is a concrete reason not to. Cypress is still actively shipping, 15.20.1 on 10 August 2026, and remains a reasonable choice where a team already knows it well.
Selenium still has a place where language-binding breadth or an existing enterprise estate demands it, and it is actively developed, with 4.47 released on 10 August 2026 and a Selenium 5 charter published. But the transport layer has moved. Those release notes record that the .NET, Python and Ruby bindings now prevent CDP access with Firefox, completing a removal the Java binding made earlier, and reinforcing WebDriver BiDi as the cross-browser standard. Suites built on Chrome DevTools Protocol hooks, on Protractor, or on brittle XPath strings with no test IDs are migration debt, and we scope that migration honestly rather than pretending it is free.
- Web end-to-end — Playwright suites built on role and accessibility-tree locators such as getByRole and ARIA snapshots, rather than CSS or XPath strings. These survive redesigns better and are far easier for AI tooling to read and repair.
- Mobile — Appium 3.6.0 for cross-platform native and hybrid apps, Maestro for fast declarative UI flows, run against real-device clouds such as BrowserStack, Sauce Labs or AWS Device Farm, with a per-release device-minute budget agreed in advance.
- API and contract — consumer-driven contract tests with Pact (pact-js 17.1.2), or bi-directional contract testing where each consumer publishes the subset of an OpenAPI specification it actually uses, so a provider change breaks a check instead of a customer.
- Performance — Grafana k6, now on v2.2.0 released 10 August 2026, whose browser module captures Web Vitals in the same run as protocol-level load, so front-end and back-end degradation are visible together. Core Web Vitals remain LCP, INP and CLS. Any report still quoting First Input Delay is stale; FID was replaced by INP in March 2024.
- Visual regression — structure and DOM-aware diffing, or Playwright's own toHaveScreenshot() and toMatchAriaSnapshot(), chosen per project. We avoid naive pixel diffing as a default because anti-aliasing, font rendering and CI-runner differences generate false positives faster than anyone will triage them.
- Accessibility — axe-core 4.13.0 assertions embedded directly in the Playwright suite rather than run as a separate quarterly audit, plus the manual testing automation cannot do.
AI can write the tests now, so the healing policy is the real question
DORA's State of AI-assisted Software Development 2025 found that 90% of respondents use AI at work and over 80% say it increased their productivity, while AI adoption showed a positive relationship with delivery throughput and product performance and a persisting negative relationship with delivery stability. More code arrives faster, and verification becomes the bottleneck. The Stack Overflow Developer Survey 2025 points the same way: only 3.1% of respondents highly trust the accuracy of AI output while 45.7% distrust it, and AI answers that are almost right but not quite is the top frustration, affecting 66% of developers.
Agentic test authoring has moved into the open-source frameworks themselves. Playwright ships first-party Test Agents: a planner that explores the application and produces a Markdown test plan, a generator that turns that plan into test files while verifying selectors against the live app, and a healer that runs the suite and repairs failures. They are installed with npx playwright init-agents and must be regenerated on every Playwright upgrade, and version 1.62 bundles the Playwright MCP server and CLI. WebdriverIO ships @wdio/mcp for the same purpose. Buying AI test generation as a separate product is a much harder case to make than it was in 2025.
The sharp question is not whether AI can write a test. It is what happens when a test breaks. A healer that quietly rewrites a selector can mask a genuine regression, so we agree a written policy before enabling one: it may repair locator drift and timing waits; it may not change assertions, expected values or navigation flow; every healed test arrives as a pull request with a visible diff and a human reviewer; and any heal that touches an assertion is escalated rather than merged.
Self-healing is also narrower than it is sold as. Healing addresses only failures caused by UI change, and it fails outright on redesigns that rebuild information architecture, because there is no prior fingerprint to match. Locator and DOM change is only one contributor to total flakiness in the first place. The larger causes are asynchronous waits and synchronisation, race conditions, test-data drift and environment variability, none of which a selector healer addresses. We also keep expectations grounded on AI tooling generally: a randomised controlled trial published by METR on 10 July 2025 found 16 experienced open-source developers working across 246 real issues took 19% longer with AI tools, after expecting a 24% speed-up and still believing afterwards they had been sped up by 20%.
A measured flake rate and a quarantine policy, not a test count
A test count and a coverage percentage tell a buyer nothing about whether CI can be trusted. A 2026 engagement should report a flake rate, the CI minutes those flaky tests waste, and what happens to them. Flaky-test management is now its own tooling category, with Trunk Flaky Tests, Datadog Test Optimization and BuildPulse competing on automatic detection, quarantine and CI-time accounting.
- Detection — per-test pass and fail history tracked across commits, so intermittent failures are identified instead of being retried into silence.
- Quarantine — a confirmed flaky test moves out of the release-blocking path automatically and onto a fix queue with a named owner and a deadline. Quarantine is a holding pen, not a bin.
- Test impact analysis — selecting the tests a change can actually affect, rather than running the full regression suite on every commit.
- Sharding and parallelism — tuned against cost per release, including real-device minutes, rather than price per test.
- Outcome metrics — escaped-defect rate, change failure rate, mean time to restore and field Core Web Vitals, in particular p75 INP. Chrome 151, stable since 28 July 2026, exposes the soft-navigation and interaction-contentful-paint performance entries as an origin trial, so per-navigation measurement of single-page-application route changes is becoming possible but is not yet on by default for all users.
Accessibility is now an EU procurement gate, and the technical bar is about to rise
The European Accessibility Act, Directive (EU) 2019/882, has had enforcement powers active since 28 June 2025, which makes 2026 the first full year of national supervision. It applies to consumer-facing digital services sold into any EU member state regardless of where the business is headquartered. Penalties are set by national law rather than EU-wide, and most authorities issue a remediation order before financial penalties.
The technical baseline is about to move. EN 301 549 v3.2.1, which maps to WCAG 2.1 AA, is the currently cited version. A version 4 draft is working through ETSI's approval process and is set to adopt WCAG 2.2 Level A and AA; the date it will be cited in the EU Official Journal is not yet fixed. Six success criteria enter scope: Consistent Help (A), Redundant Entry (A), Focus Not Obscured Minimum (AA), Dragging Movements (AA), Target Size Minimum at 24 by 24 CSS pixels (AA) and Accessible Authentication Minimum (AA). WCAG 4.1.1 Parsing is removed. Scoping a remediation today to WCAG 2.1 AA is scoping to a standard about to be replaced, so we test against 2.2 AA now.
Automation on its own does not reach conformance. Deque's coverage study, measured across more than 13,000 pages and nearly 300,000 issues from first-time audits, found that axe-core detects 57.38% of accessibility issues by volume. That is considerably better than the conventional 20 to 30% figure, which counts success criteria rather than actual issue volume, but it is not compliance. The remainder needs manual keyboard traversal, screen-reader passes and human judgement about meaning. Accessibility overlay widgets do not satisfy EN 301 549 and do not survive a complaint-triggered investigation.
The underlying problem is getting worse, not better. WebAIM Million 2026 found 95.9% of the top one million home pages had detected WCAG 2 failures, up from 94.8% in 2025, at an average of 56.1 errors per page, up 10.1% year on year. Low-contrast text appeared on 83.9% of pages, missing image alternative text on 53.1% and unlabelled form inputs on 51%. Pages using ARIA averaged 59.1 errors against 42 on pages without it, which is a useful reminder that adding ARIA is not the same as improving accessibility.
Testing AI and LLM features is a separate discipline
Deterministic string assertions and golden-output snapshots do not work on a model that can phrase the same correct answer three different ways. The 2026 practice is an evaluation suite with score thresholds wired into CI as a merge gate, using promptfoo 0.122.0, DeepEval 4.1.8, RAGAS or a comparable harness, with rubric-based grading and groundedness or faithfulness metrics instead of exact match. Adversarial red-teaming runs alongside it, mapped to the OWASP Top 10 for LLM Applications 2026, published on 3 August 2026, and the OWASP Top 10 for Agentic Applications 2026, published on 9 December 2025 with more than 100 contributors, covering agent goal hijack, tool misuse, memory and context poisoning, privilege abuse and cascading agent failure. That this has become strategic infrastructure rather than a niche was confirmed when OpenAI announced its acquisition of Promptfoo on 9 March 2026, with the project remaining open source.
We will not sell you an AI judge as the sole quality signal, because the published evidence does not support it. Norman, Rivera and Hughes (arXiv:2606.19544, June 2026) evaluated 21 judges from nine providers over 118 runs and approximately 541,000 individual judgments, and found that exact-match agreement overstates discriminative ability by 33 to 41 percentage points against chance-corrected Cohen's kappa on MT-Bench, that two production-deployed judges combined test-retest reliability above 0.95 with position bias above 0.10, and that judge rankings shifted by up to 14 positions across benchmarks. A separate 2026 study of a deployed food-and-beverage ordering agent (arXiv:2606.10315) found the automated judge caught 2 of 9 problem patterns in one batch and flagged nothing at all in a batch where human reviewers confirmed 23 distinct defects, missing cross-turn state failures such as cart hallucination entirely. Its authors conclude that for production multi-turn agents, automated judging is a regression floor and not a substitute for human review. We run judges at temperature 0, because same-verdict rates fall materially as temperature rises, and we pair every eval suite with a named human-review sampling rate.
When automation testing is the wrong choice
Automation pays back over repetition. There are several common situations where it is the wrong first move, and we would rather say so before an engagement than after.
- A user interface that is still changing shape — if the design will be rebuilt within a quarter, an end-to-end suite is written to be thrown away, and self-healing will not rescue it because a redesign leaves no fingerprint to match. Automate the API layer, and hold the UI suite until the design settles.
- A one-off migration or a feature that ships once — a checklist and a focused exploratory session cost less than a suite nobody will maintain.
- Chasing a coverage percentage — coverage measures execution, not verification. A suite at 90% coverage full of assertion-light tests is worse than a smaller honest one, because it manufactures confidence.
- Replacing exploratory testing — automated checks confirm what somebody already thought to specify. They do not find the defect nobody imagined. Script execution is the part AI is commoditising; charter-based exploratory sessions and risk-based domain testing are the parts that grow more valuable, and we staff both.
- Where the real problem is upstream — unstable environments, no test-data strategy or unclear requirements produce a flaky suite no matter which framework runs it. Fixing those first is cheaper than automating on top of them.
Every engagement ends with the suite in your repository, running in your CI, in standard Playwright, Appium or k6 code your own team can read and extend. If the relationship ends, the tests keep working. Given how much the tooling market is consolidating, with Promptfoo acquired by OpenAI and LambdaTest rebranded to TestMu AI in January 2026, portability is not a preference but a risk control.
Our expertise
- Playwright end-to-end suites
- Mobile app automation
- API and contract testing
- Performance and Web Vitals
- Accessibility conformance
- LLM evaluation and red teaming
Frequently asked questions
Which test automation framework should we use in 2026?
Playwright, for almost all new web work. npm registry figures for the week of 3 to 9 August 2026 show 80,091,572 weekly downloads for playwright against 7,360,936 for cypress and 2,045,892 for selenium-webdriver, so the ecosystem, documentation and AI tooling all concentrate there. Cypress remains defensible when a team already knows it, and Selenium when you need language bindings or enterprise browser breadth Playwright does not cover. Protractor and TestCafe are not sensible choices for a new project.
Do we own the test suite, or is it locked to your tooling?
You own it. Every engagement produces standard Playwright, Appium or k6 code in your repository, running in your CI, with no runtime dependency on any vendor account of ours. This matters more in 2026 than it used to, because the AI testing vendor market is consolidating: Promptfoo was acquired by OpenAI in March 2026 and LambdaTest rebranded to TestMu AI in January 2026. A suite that only runs inside one vendor's cloud is exposed to that vendor's roadmap.
How do you stop a self-healing test from hiding a real bug?
With a written policy rather than trust in the tool. The healer may repair locator drift and timing waits, but it may not change assertions, expected values or navigation flow. Every healed test arrives as a pull request with a visible diff and a human reviewer, and any heal touching an assertion is escalated rather than merged. It is worth knowing the limits too: self-healing only repairs failures caused by UI change, and locator change is only one of several contributors to total flakiness.
Does automated accessibility testing make us compliant with the European Accessibility Act?
No, and any supplier claiming otherwise is overselling. Deque's study across more than 13,000 pages and nearly 300,000 issues found axe-core detects 57.38% of accessibility issues by volume, which is a good automated baseline but not conformance. The remainder requires manual keyboard traversal, screen-reader testing and human judgement, documented in an accessibility conformance report. Overlay widgets do not satisfy EN 301 549 and do not survive a complaint-triggered investigation.
How do you test an AI feature that gives a different answer every time?
Not with string assertions. We build an evaluation suite with score thresholds wired into CI as a merge gate, using tools such as promptfoo, DeepEval or RAGAS, scoring groundedness, faithfulness and rubric-based quality rather than exact match, plus adversarial red-teaming mapped to the OWASP Top 10 for LLM Applications 2026 and the OWASP Top 10 for Agentic Applications 2026. We run judges at temperature 0 and always pair them with a named human-review sampling rate, because 2026 research shows automated judges are a regression floor rather than a replacement for human review.
Contacts
We are always happy to talk with you.
Feel free to contact us in any suitable way
Request a quote
Let's discuss your project!
Please, provide us with a brief description of what you
already have and what you are going to achieve.
Mail us contact@brainiacminds.com