Use Case in Software Testing: How to Turn One Into Test Cases
Every path through a use case becomes at least one test case. A worked bank-transfer example shows the test table, and ISTQB's 2023 and 2025 syllabus changes explain…
Web Application Testing Services: Functional, Cross-Browser, Usability
Vervali tests web applications for SaaS products, portals and ecommerce: functional testing 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
The feature works, last month still works, it holds in the browsers people use, and a new user can finish the task. One engagement, not three vendors.
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?
Functional and Regression
The money paths work this release, and they still work after the next one. The pack grows and retires with the product, not as a museum you keep paying for.
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
Chrome, Edge, Firefox and Safari on the widths that already convert. Safari and the phones that make money run on real hardware, not a resized desktop.
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
A new user can finish the task you care about. You get success rates and a ranked list of where they stall, not a slide of quotes.
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
WCAG on the same journeys, and load against the concurrency you actually see. Quoted after the web scope is fixed, not folded into it.
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
You sign the coverage, defects land in your tracker, and a named tester is on the go-live call. First report inside two weeks.
-
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
Airline, finance and government work where coverage went up and customer issues, testing time or regression time went down.
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
