Quality Assurance Testing: Fewer Surprises at Launch
QA testing, short for quality assurance, is how we check your website or web application works properly before it goes live. We try it the way real people will: on their phones, in their browsers, doing what they'll actually do. Most teams find out about a problem when a customer tells them. We'd rather you heard it from us first.
Why Testing Matters
A bug found after launch costs more than one found before it
By then it has reached customers, the campaign is live and the team has moved on to the next thing. Fixing it means pulling people off other work, re-testing around the change and explaining what happened to stakeholders. The same fix at the start is a quick conversation. That's why we bring testers in before the build, not after.
Your visitors aren't using your developers' devices
They arrive on phones, tablets and browsers you didn't plan for, some of them years old. If nobody knows which ones matter, you find out through complaints, lost enquiries or a stalled checkout. We work out which browsers and devices your audience actually uses and test those first.
Testing starts before the first line of code
By the time a build is finished, the cheapest fixes are behind you. We read the requirements before development starts and point out anything unclear or that contradicts something else. Then we write test cases alongside the build and test each feature on a staging site (a private copy of your site) as it lands, so launch day isn't the first time anyone sees the whole thing working.
Things to check before launch
Checking a site before launch isn't exotic, but it's the first thing to get skipped when the deadline gets close. Start with what your users do most, then work outwards.
Key journeys work
Forms, search, login and checkout work from start to finish.
Content and tracking are right
Links, images and analytics all behave as they should.
It works for everyone
It runs on your audience's main browsers and devices, and passes accessibility checks.
The owners have signed off
The people who own the product have checked it against what they asked for.
Smoke, regression and UAT: what's the difference?
Functional testing
Checking each feature does what it’s meant to: the form submits, the search finds things, the login lets the right people in.
Smoke
testingA quick check that the most important things work, run on every release. If it fails, there's no point testing further.
Regression testing
Re-testing what already worked after a change. It's why a site can break after an update: something moved and nobody re-checked.
User acceptance testing (UAT)
The people who'll own the product check it against what they asked for. QA checks that it works; UAT checks it's the right thing. You need both.
Most products need manual and automated testing
Manual testing is a person following test cases and exploring where a script wouldn't think to look. It suits new features, visual detail and accessibility. Automated tests re-run the same checks quickly, which suits things that must never break, like login or checkout. On Galvins, automated tests ran as developers made changes, while our test team covered feature, regression and smoke testing. Most growing products need both. A small site with few releases can often manage with manual alone.
Accessibility and WCAG: checked by people and tools
Accessibility problems affect real users and create risk for your organisation. In Australia the usual benchmark is WCAG, and Keep Able was built to WCAG 2.1 AA. We check keyboard use, screen readers, colour contrast and clear form errors. Scanners find some of it; a person has to check the rest.
See how we tested Keep Able.
Why Testing Matters
Galvins Plumbing Supplies
On Galvins, a trade and retail ecommerce platform, our test team worked through every release. For anything involving money, like invoices, we check what's on screen against the database.
What we found: While testing an unrelated fix, we found that when a trade order couldn't be passed to the ERP system, a gap in the code crashed the whole ordering service and left the order stuck at "processing". One failed order could take ordering down for everyone using it. We found it in QA, and it was fixed in a later release.
Rhodes Pastoral
On Rhodes Pastoral, a web app that lets field staff fill in forms offline on shared iPads, we tested the offline release on a real iPad.
What we found: Tapping "Discard and Logout" threw away unsynced forms with no second confirmation, so one wrong tap would have wiped a worker's queued forms. We caught it on staging, and it was fixed before release.
Keep Able
A resource hub for the aged care secto.r, built on Payload CMS. We tested it release by release, from the homepage redesign to the podcast player, with accessibility checks and UAT before go-live.
What we found: On the homepage carousel, an editor could switch on a slide's button and leave its label empty, and the site would still show a button with no label. It's a small thing, but exactly what a visitor notices and an editor can't explain. We found it on staging and it was fixed before it reached the live site.