Manual and Exploratory Testing Services for Websites and Mobile Apps
Manual and exploratory testing is structured human investigation of a product, where a tester forms hypotheses about how the software might fail and then tries to make it fail, instead of executing a fixed script. It is the part of quality assurance that automation has not absorbed, and the part that AI-assisted development has made more necessary rather than less.
Mixcore Studio has been building and testing software for over eight years, with a team of around twenty and more than 320 projects delivered. Our manual practice is deliberately narrow. We do not sell people to re-run regression scripts by hand, because that work belongs in Playwright and Appium. We sell charter-based exploratory sessions, accessibility testing against real assistive technology, and human review of AI-driven features, all of which produce findings an automated suite structurally cannot.
Why manual testing matters more in 2026, not less
Script authoring is being commoditised, and that is a good thing. Playwright is now the default browser-automation runtime by an order of magnitude, with 80,091,572 weekly downloads in the npm registry for the week of 3 to 9 August 2026 against 2,045,892 for selenium-webdriver, and it ships first-party Test Agents that explore an application, generate test files and repair failing ones. Anyone still charging for hand-written selector maintenance is selling a shrinking product.
Judgement did not get commoditised. DORA's State of AI-assisted Software Development 2025 found AI adoption positively related to delivery throughput and product performance, but with a persisting negative relationship to delivery stability. Teams ship more and break more, which pushes the bottleneck downstream into verification. Stack Overflow's 2025 Developer Survey found that only 3.1% of 33,244 respondents highly trust the accuracy of AI output while 45.7% distrust it, and that the top frustration, affecting 66% of developers, is AI solutions that are almost right but not quite. Almost-right code is exactly the category a green test suite misses, because the assertions were written from the same incomplete understanding as the code.
What a charter-based exploratory session actually looks like
Exploratory testing is often described loosely as clicking around. Run properly it is session-based test management, and every session is documented and reviewable.
- Charter — a one-line mission with a named risk, for example exploring checkout with expired and near-expiry payment methods to find state-inconsistency defects. Vague charters produce vague findings.
- Time-boxed session — normally 60 to 90 minutes on one charter, so the work is estimable and comparable between sessions.
- Session sheet — areas covered, defects found, open questions, and the split of time between testing, setup and bug investigation. That split is what tells you whether the environment is costing you more than the testing.
- Reproducible defect report — every finding ships with exact steps, environment, build identifier and, where possible, a Playwright trace or screen recording, so a developer does not have to rediscover it.
- Debrief — a short review that updates the risk model and decides the next charters, rather than filing the notes and moving on.
- Promotion to automation — findings that represent recurring regression risk get written as standard Playwright or Appium tests you own and run in your own CI, not held inside a vendor platform.
Risk drives the order. Charters are prioritised by where a defect would be most expensive, typically money movement, authentication and session state, data destruction, and anything a developer changed under time pressure.
Accessibility testing a scanner cannot do
Automated accessibility tooling is necessary and insufficient. Deque's coverage study, measured across more than 13,000 pages and nearly 300,000 issues from first-time audits, puts axe-core at 57.38% of accessibility issues detected by volume. That is a far better number than the 20% to 30% often quoted, but it still leaves close to half the issues to a human.
The remainder are judgement calls. Whether alternative text is meaningful, whether focus order matches visual order, whether an error is announced when it appears, whether a custom component behaves the way its ARIA role promises. Those need a keyboard and a screen reader, which in practice means NVDA and JAWS on Windows, VoiceOver on macOS and iOS, and TalkBack on Android.
The commercial stakes changed. The European Accessibility Act, Directive (EU) 2019/882, has had enforcement powers active since 28 June 2025, making 2026 the first full year of national supervision, and it reaches consumer-facing digital services sold into any member state regardless of where the business is based. The technical baseline is also moving. EN 301 549 v3.2.1 cites WCAG 2.1 AA today, draft v4.1.0 went to public comment in November 2025 and reached final draft in June 2026, and the next version adopts WCAG 2.2 Level A and AA once it is published and cited in the EU Official Journal. Six success criteria enter scope with it.
- Consistent Help — level A.
- Redundant Entry — level A.
- Focus Not Obscured, Minimum — level AA.
- Dragging Movements — level AA.
- Target Size, Minimum — level AA, 24 by 24 CSS pixels.
- Accessible Authentication, Minimum — level AA.
Two things follow. Scoping new work to WCAG 2.1 AA now means building to a standard that is about to be replaced, and accessibility overlay widgets do not produce EN 301 549 conformance and do not survive a complaint-triggered investigation. The wider picture is not improving on its own either. WebAIM Million 2026 found detected WCAG failures on 95.9% of top one million home pages, up from 94.8% in 2025, with an average of 56.1 errors per page, up 10.1% year on year.
Human review of AI and LLM features
If your product ships an LLM or agent feature, the automated layer is an eval suite with score thresholds wired into CI, using tools such as promptfoo, DeepEval or RAGAS, alongside adversarial red-teaming mapped to the OWASP Top 10 for LLM Applications 2025 and the OWASP Top 10 for Agentic Applications 2026 published on 9 December 2025. That layer is the regression floor. It is not the ceiling.
The 2026 evidence on LLM-as-a-judge is unambiguous about the gap. Catching One in Five, arXiv 2606.10315, studied a deployed food-and-beverage ordering agent and found the automated judge caught 2 of 9 problem patterns in one batch, 22%, and flagged zero issues in a second batch where human reviewers confirmed 23 distinct defects. In that study 113 of 114 rounds describing relevant defects were mislabelled as brand voice and never reached the operational failure gate. Turn-local issues were caught; cross-turn state issues such as cart hallucination and confirmation-gate lockout were missed. The authors' conclusion is that for production multi-turn agents, automated judging is a regression floor, not a substitute for human review.
Norman, Rivera and Hughes, arXiv 2606.19544, evaluated 21 judges from nine providers across roughly 541,000 judgments and found exact-match agreement overstates discriminative ability by 33 to 41 percentage points against chance-corrected Cohen's kappa, with two production-deployed judges combining test-retest reliability above 0.95 with position bias above 0.10. A judge can be highly self-consistent and systematically wrong at the same time, which is why we run a named human sampling rate over graded conversations, probe multi-turn state deliberately, and treat judge scores as a signal rather than a verdict.
Where manual testing meets your automated suite
Self-healing locators are useful and oversold. Vendors report high repair rates for UI-change-induced failures, but healing fails entirely on redesigns that rebuild information architecture, because there is no fingerprint left to match. More importantly, locator and DOM change is only one cause of flakiness among several. The larger causes are asynchronous wait and synchronisation problems, concurrency and race conditions, test-data drift and environment variability, none of which selector healing addresses.
There is also a real risk buyers are right to raise. A healer that rewrites a broken selector can quietly mask a genuine regression. So healing gets a written policy: what the agent may change, what must escalate to a person, and a rule that healed tests are reviewed in the pull request like any other code. Alongside that we report a measured flake rate and operate a quarantine policy, moving persistently flaky tests out of the release-blocking path using tooling such as Trunk Flaky Tests, Datadog Test Optimization or BuildPulse, then fixing the underlying cause instead of adding retries.
When manual testing is the wrong choice
It is worth being direct about the limits, because buying manual effort for the wrong job wastes money and slows releases.
- Regression re-execution — paying people to re-run the same steps every release is the clearest waste in QA. Automate it in Playwright or Appium and keep the humans for new risk.
- Anything that must gate a merge — manual testing cannot run on every commit. If you need a blocking signal at commit speed, you need a suite, not a session.
- Load and performance — humans cannot generate load or measure Core Web Vitals reliably. That is code-first tooling such as Grafana k6, whose v2.2.0 landed on 10 August 2026 with a browser module that captures Web Vitals alongside protocol load.
- Wide browser and device matrices — combinatorial coverage belongs on a device cloud such as BrowserStack, Sauce Labs or AWS Device Farm, with manual attention reserved for the two or three configurations where real users actually are.
- Auditable coverage evidence — session sheets record what was investigated, not a coverage matrix. If a customer or regulator wants repeatable proof that a specific path passes each release, build the automation first.
- Teams without domain context — exploratory quality is bounded by how well the tester understands the domain. Adding headcount without that understanding produces shallow reports, so this work does not scale linearly with people.
Measurement deserves the same honesty. METR's randomised controlled trial published on 10 July 2025 found 16 experienced open-source developers working across 246 real issues took 19% longer to complete tasks when using AI tools, after expecting a 24% speed-up beforehand and still believing afterwards that they had been sped up by 20%. Self-assessment of productivity is unreliable in both directions, which is why an engagement should be judged on escaped-defect rate, change failure rate, mean time to restore and field Core Web Vitals rather than session counts or a total bug tally.
Everything we produce is yours. Charters, session sheets, defect reports, accessibility findings and any tests promoted to automation are standard artefacts and standard Playwright or Appium code in your repository, running in your CI, and they keep working after the engagement ends.
Our expertise
- Charter-based exploratory sessions
- Risk-based test prioritisation
- Accessibility and assistive technology
- Real-device manual coverage
- Human review of AI features
- Reproducible defect reporting
Frequently asked questions
Is manual testing still worth paying for when AI can generate tests?
Yes, but for different work than in 2021. Playwright's Test Agents and similar tooling have absorbed script writing and much of script maintenance, so paying humans to author or re-run regression steps is no longer good value. What remains human is exploratory investigation, accessibility judgement, domain reasoning and review of AI-generated behaviour. DORA's State of AI-assisted Software Development 2025 found AI adoption raises delivery throughput while delivery stability worsens, which moves the bottleneck into exactly that verification work.
What is the difference between exploratory testing and manual test-case execution?
Test-case execution follows steps somebody wrote earlier and checks the expected result. Exploratory testing designs, runs and interprets tests at the same time, guided by a written charter and a time box, so the tester can follow an anomaly the moment it appears. Execution of fixed steps is the part worth automating; the investigation is the part worth a person. We document exploratory work as session sheets so it stays reviewable rather than anecdotal.
Can an automated accessibility scan satisfy the European Accessibility Act?
No. Deque's coverage study, across more than 13,000 pages and nearly 300,000 issues, measures axe-core at 57.38% of accessibility issues by volume, so a scan alone leaves close to half undetected. Conformance evidence needs manual keyboard testing and screen-reader testing with NVDA, JAWS, VoiceOver and TalkBack. Overlay widgets do not produce EN 301 549 conformance. Note also that the baseline is moving to WCAG 2.2 AA when the next version of EN 301 549, in final draft since June 2026, is cited in the Official Journal.
How do you test an AI or LLM feature that answers differently every time?
With an eval suite rather than string assertions. Score thresholds run as CI gates using promptfoo, DeepEval or RAGAS, with groundedness and faithfulness metrics and adversarial red-teaming mapped to the OWASP Top 10 for LLM Applications 2025 and the Top 10 for Agentic Applications 2026. On top of that sits a named human sampling rate, because the 2026 research is clear that LLM judges miss cross-turn state defects. In one deployed agent studied in arXiv 2606.10315 the judge caught 2 of 9 problem patterns and flagged zero issues in a batch where humans confirmed 23 defects.
Who owns the tests and reports after the engagement ends?
You do. Session sheets, defect reports and accessibility findings are plain documents, and anything promoted from an exploratory finding into automation is standard Playwright or Appium code committed to your repository and run in your CI. Nothing is held inside a vendor platform that stops working when the contract does, which matters in a market where testing vendors are being acquired and repositioned.
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