Mobile App Testing Services in 2026: Devices, Store Rules and Cost
This guide explains what mobile app testing services cover, how to size a device matrix from United States traffic data, and what Apple and Google check before a rel…
Web Application Testing Services: Functional, Cross-Browser, Usability
Vervali tests web applications for SaaS products, portals and ecommerce: functional and regression testing, cross-browser and responsive checks on real devices, usability and accessibility testing, API and integration testing, and UAT support, with automation where it pays. Delivered in US hours from an ISO/IEC 17025 accredited lab.
150+ clients
450+ projects
275+ engineers
15+ years
ISO/IEC 17025:2017Accredited testing laboratory
CMMI Maturity Level 3The process is written down and repeats
ISO 9001:2015Quality management
ISO/IEC 27001Information security
What We Test in a Web Application
Six things break in a web application. Each block is the failure a real user would report, not the QA term. Functional plus usability plus cross-browser belong in one engagement. Cross-browser is one failure class. The work is wider.
Functional Testing
The button does nothing, the form saves the wrong field, the role cannot see what it should. A product owner hears "it does not work." That is functional testing: the feature against the requirement, or against the behaviour we agreed when there was no spec.
Regression Testing
Last month's login or checkout broke after this month's release. Support hears it first. The pack has to grow with the product and retire paths that no longer ship, or you pay to retest a museum.
Browser and Device Behaviour
It works on the developer's Chrome and dies on Safari, or on a phone width nobody on the team uses. The customer never files a "cross-browser" ticket. They leave.
Usability Testing
A new user cannot complete the task you care about, even though every field validates. Time on task blows out. That is not a bug in Jira until someone watches a session. Usability testing is that watch, with numbers attached.
Accessibility Testing
A keyboard user cannot reach submit. A screen-reader user never hears the error. In US retail and public-sector work that is also legal exposure. The method lives on accessibility testing. On this page it is the add-on on the same flows.
Speed Testing
The page is correct and still too slow to finish. Users bounce. Load and response time are a performance testing add-on, quoted against the concurrency you actually get, not a generic spike.
Need a web app that holds up in the browsers your users actually use? Talk to the web QA lead, or start with a free one-flow test on staging.
Talk to QAFunctional and Regression
What is covered, and how the regression pack is built and kept alive, which is the part clients underestimate. The pack is an asset. If nobody owns growth and retirement, it becomes a cost.
What Functional Covers
The journeys that make money or create risk: sign-up, login, the core task, payments if you take them, admin roles, and the failure cases. If there is no written requirement, we reconstruct intended behaviour from the product owner, last release notes and the current build, then test against that. You sign the expected result before execution, so a fail is a product decision.
How the Regression Pack Lives
The pack is the set of paths users still take, not every closed ticket. It grows when a new journey ships. It retires when a path is removed or no longer used. The product owner signs that list. A tester does not keep a favourite case alive on their own. That sign-off is what stops the suite becoming a museum you still pay to run.
When a Manual Pack Should Become Automated
A path moves to automation when it is stable, runs often, and is cheaper to keep alive than to re-execute by hand. Login, checkout and the journeys that still make money after last month's release are the usual candidates. A checkout experiment whose fields change every sprint stays manual. The split arrives before the quote. Tooling and payback sit on automation testing services, not here.
Cross-Browser and Responsive
The matrix, not a claim of "all browsers." Testing everything is how a budget disappears. We cut the set from your own analytics, then name what runs on real hardware and what runs in emulation.
Default Browser Set
Chrome, Microsoft Edge, Firefox and Safari. Versions: current and the previous major release, unless your analytics say a third version still produces sessions. Viewport widths start from the widths that already generate traffic for you. A typical cut is a phone width, a tablet width and a desktop width. Extra widths are added only when the data justifies them.
Chrome · Edge · Firefox · Safari Current and previous major Phone, tablet, desktop widthsReal Hardware and Emulation
Safari on macOS, and the phones that appear in your top sessions, run on real hardware. That is where rendering, input and viewport behaviour actually differ. Chromium and Firefox also run in a controlled desktop environment. Emulation widens the viewport set. It does not replace the hardware pass on the browsers that make money. If a device is not in the lab, we say so in the design before we quote, rather than promising a matrix we cannot run.
Usability Testing
This is the section that opens usability testing services, a market Vervali has not had a page for. The offer we run as standard is unmoderated. Moderated sessions are a different scope. Who recruits the participants is the hidden cost, and it is named up front.
Unmoderated
More participants, less depth, faster. Real people complete your tasks on a panel you approve. There is no facilitator in the room. You get volume and a ranked list of where people stall. This is the default on a web testing engagement when you need evidence this month, not a research programme.
Moderated
A facilitator, typically five to eight participants, set tasks, and a recording. Deeper, slower, and priced as its own scope. We do not bury recruitment inside a web-test quote. You supply the users, or recruitment is a line item. If you do not want that cost, stay on unmoderated.
What You Receive
Task success rates, time on task, a System Usability Scale score, session recordings, and a ranked list of what to fix. Not a slide of quotes. The numbers are what a product owner can take into a sprint. Recruitment stays visible: you supply participants, or we run unmoderated work on a panel you approve.
Accessibility and Performance Add-Ons
Two short blocks that route rather than sell. Each adds coverage on the same flows already in the web test. Each is quoted after that scope is fixed, not as a silent percentage on the web-test price.
Accessibility Testing
A WCAG pass on the same journeys, with keyboard and a screen reader, not a full-site audit. That audit, VPAT support and the legal deadlines sit on accessibility testing. On this page it is an add-on quote once we know how many templates those flows use.
Performance Testing
A load profile on the same journeys, against the concurrency you actually see. The method sits on performance testing. On this page it is an add-on quote from that profile, not a generic spike tacked onto functional work.
How an Engagement Runs
The same five steps as application testing, kept short here. What we read, what we design, how we execute, what you receive, and who is on the call at release.
-
01
What We Read
Tickets, Figma, old cases, analytics. When there is no specification, we walk the paths that make money or create risk, write them down, and send them back for a yes.
-
02
What We Design
A coverage model, the browser matrix, and the manual against automated split. Nobody runs anything until that design is signed off.
-
03
How We Execute
Cadence follows your release train. Defects land in your Jira with reproduction, environment and evidence. A blocker escalates the same day, in US hours.
-
04
What You Receive, and When
A short status: what ran, what failed, what is blocking release. Daily in a live cycle, otherwise at an agreed cadence. Leadership gets a release-risk view, not a 40-page PDF.
-
05
Who Is on the Call at Release
A named tester on the go-live call in US hours. Smoke on the production-like build, then a watch on the first hours after release.
Start to First Report
A named tester is usually assigned within a week of NDA and staging access. First execution and the first written report typically land inside two weeks. The free one-flow test on staging is the fastest first look.
Case Studies
Sector and country only. Each is what was wrong, what we did, and what changed.
India · major airline · booking and check-in
Before: coverage on the booking and check-in platform was too thin for the release pace, so customers were reporting issues testing had not seen. Vervali built a functional and regression suite around the paths that sell seats and get passengers to the gate. After two release cycles: 85% test coverage, and 70% fewer customer-reported issues.
85% test coverage 70% fewer customer-reported issues Two release cyclesUAE · SME finance platform · web and mobile
Before: testing time was eating the sprint, and users were paying for it in a clumsy web and mobile experience. Vervali put automation on the repeatable finance journeys and kept exploratory and UAT support in human hands. After: 98% user satisfaction, and 40% less testing time.
98% user satisfaction 40% less testing time Web and mobileUAE · Dubai government · border-security and immigration
Before: regression took days and still missed coverage. Vervali expanded automated regression across the products in scope and cut the manual remainder to what still needed a person. After: coverage from 70% to 80%, regression from days to hours, and manual regression effort more than halved.
Coverage 70% to 80% Regression in hours Manual effort more than halvedFrequently Asked Questions
It proves a SaaS product, portal or store will work for the people who use it: features against the requirement, last month's paths after this month's release, browsers and viewports that generate sessions, whether a new user can complete a task, and whether the same flows hold up with a keyboard. Defects in those paths are lost sign-ups and support load, not tickets.
Work is scoped to the product, the browsers and the depth you need, then quoted before we start. Clutch lists Vervali at $25 to $49 per hour. A one-flow staging test is free. A release project is a fixed price. A retainer is billed monthly. Extra devices, accessibility and load are named in the estimate so they are not a surprise after kickoff.
No. Functional testing checks the build against the requirement, or against the behaviour we agreed when there was no spec. UAT is the business confirming the product is fit to use. Vervali does the functional work and supports UAT: scripts, sitting with users, turning what they report into tickets a developer can act on. We do not replace the business owner on a go-live call.
The four types people mean are unit, integration, system and acceptance. Unit stays with your developers. Integration and system testing are the core of a Vervali web engagement. Acceptance is UAT, which we support rather than own. Smoke and regression sit inside that work. They are not a separate fourth family.
Vervali runs regression on every build in scope, against the pack of paths users still take. The pack grows with the product. Old paths that no longer ship are retired, and the product owner signs that list. Automation takes over a path once it is stable and cheaper to keep alive than to re-run by hand. We run it before release, not as a museum after go-live.
Chrome, Edge, Firefox and Safari, current and previous major version, unless your analytics say otherwise. Viewport widths and phones come from your own session data. Safari and the top phones run on real hardware. Extra viewports can run in emulation. You are not paying to certify browsers your customers do not use.
Yes, as unmoderated sessions: real people complete your tasks, and you receive success rates, time on task, a System Usability Scale score, recordings and a ranked list of what to fix. Moderated sessions with a facilitator are a different scope. Participant recruitment is the hidden cost. You supply users, or we run unmoderated work on a panel you approve.
A named tester is usually assigned within a week of NDA and staging access. The free one-flow test on staging is the fastest first look. A full first cycle and written report typically land inside two weeks. The longer process write-up sits on the application testing page. This page keeps the same five steps, shorter.
Email Us
Call Us
