QA (quality assurance) testing is the structured work of checking that software does what it should, handles mistakes gracefully and stays secure before real customers use it. Skipping it rarely saves money: a bug caught during development takes minutes to fix, while the same bug found by customers brings support time, data clean-up, lost sales and an emergency release.
Think of QA as the difference between finding a leak during a plumbing inspection and finding it when the ceiling comes down.
What does QA testing actually involve?
QA is a process across the whole project, not a final check on the last Friday. It starts with reviewing requirements for gaps and contradictions, continues with developers writing automated tests alongside their code, and ends with people using the software the way customers will.
A QA tester's job is to think like every kind of user at once: the careful one, the impatient one who double-clicks every button, the one on a slow phone connection, and the one deliberately trying to break things. They write test cases (step-by-step scenarios with an expected result), run them, log anything that fails, and re-test once it is fixed.
What types of software testing are there?
Different tests catch different problems. A healthy project uses several layers rather than relying on one.
| Test type | What it checks | Who usually does it | When |
|---|---|---|---|
| Unit tests | Small pieces of code work in isolation, such as a tax calculation | Developers, automated | While coding |
| Integration tests | Parts work together: app and database, app and payment gateway | Developers, automated | Every code change |
| End-to-end tests | Full user journeys, such as sign up, book, pay, receive email | QA, often automated | Before each release |
| Regression tests | New changes haven't broken old features | QA, ideally automated | Before each release |
| Exploratory testing | Unscripted attempts to find odd behaviour | Experienced QA tester | Throughout |
| Performance tests | Speed under realistic or heavy load | Developers or QA | Before launch and big events |
| Security testing | Common vulnerabilities, access rules, login protection | Developers; specialists for sensitive apps | Before launch, periodically |
| Accessibility checks | Usable with keyboards, screen readers, good contrast | Designers and QA | Design and pre-launch |
| User acceptance testing (UAT) | It works for your real business process | You and your team | Before sign-off |
Small projects do not need every layer at full depth. A simple internal tool might lean on unit tests, a short end-to-end suite and a day of UAT. A customer-facing payment platform needs all of them.
Why does a bug cost more the later it is found?
Because the later it is found, the more has been built on top of it, and the more people it has touched.
Follow one mistake, say a discount that is applied twice in certain conditions, through the life of a project:
- In the requirements: someone spots the ambiguous rule while reviewing the spec. Fix: rewrite a sentence.
- During development: a unit test fails. Fix: a few minutes of the developer's time, while the code is fresh in their mind.
- In staging, before release: QA catches it. Fix: a developer has to re-learn the code, fix it, and QA re-tests.
- In production: customers have been undercharged for weeks. Now you need the fix, an emergency release, an investigation into which orders were affected, accounting corrections, and perhaps awkward emails to customers.
The code change might be identical at every stage; everything around it is what gets expensive. And some costs never appear on an invoice: the customer who quietly stopped trusting your checkout, or the staff hours lost working around a broken report.
What does skipping QA look like in real life?
It usually looks fine at first. That is the trap.
A small example from our own site: during an SEO review of grww.tech we found canonical tags, the hint that tells Google which address is the "official" version of a page, pointing at an old domain. Nothing looked broken to a visitor. The pages loaded, the design was intact. But search engines were being told the real pages lived somewhere else. A simple automated check on page metadata would have caught it on the day it was introduced.
Common patterns we see when projects skimp on QA:
- Features that work only on the developer's laptop, then fail on older phones or different browsers.
- Forms that accept rubbish, so the database fills with malformed phone numbers and duplicate customers.
- Silent failures, such as notification emails that stopped sending weeks ago without anyone noticing.
- Fear of change. Without automated regression tests, every update risks breaking something, so updates get postponed, and the software slowly accumulates technical debt.
Should testing be manual or automated?
Both. Automate what repeats; keep humans for judgement.
Automated tests are best for logic that must never break (prices, permissions, calculations, integrations) and for checks run on every release. They cost time to write but pay back every time they run. Manual testing is better for usability, visual layout, confusing wording and the strange things only a curious human would try.
A practical rule: if you would check it before every release, automate it. If you'd only notice it by looking, keep a person on it.
What should you test yourself before signing off?
User acceptance testing (UAT) is your part of QA. No one knows your business processes better than your team. Set aside real time for it; a rushed hour on launch eve is not UAT.
- List your real scenarios. "New customer books, pays a deposit, reschedules, then cancels" is better than "test bookings."
- Use realistic data. Long names, international phone numbers, odd addresses, large files.
- Involve the actual users, not just the manager who wrote the brief.
- Test on the devices your staff and customers really use.
- Record issues clearly: what you did, what you expected, what happened, and a screenshot.
- Re-test the fixes, then sign off in writing.
This works best when testing is built into each delivery cycle rather than saved for the end; our comparison of agile vs waterfall for business software explains why.
How do you know if your project is skimping on QA?
Ask your developer or agency these questions. Vague answers are a warning.
- Is testing a visible line in the quote, or just "included"?
- Do you write automated tests, and roughly what do they cover?
- Is there a staging environment that mirrors the live one?
- Who tests apart from the developer who wrote the code?
- How are bugs tracked, prioritised and confirmed as fixed?
- What is the warranty for defects after launch?
QA quality also shapes your running costs: well-tested software is cheaper to update, which is a big part of budgeting for maintenance after launch. To see where testing sits in the wider project, read how custom software gets built, from discovery to launch.
Frequently asked questions
Can developers test their own code?
They should test it, through unit tests and their own checks, but they should not be the only testers. People naturally test the paths they built and miss the ones they never imagined. A second pair of eyes catches different problems.
Does QA make a project take longer?
It adds time during the build but usually shortens the project overall. Bugs found early are quick to fix, whereas bugs found late cause rework, delayed launches and emergency releases.
Will thorough testing guarantee zero bugs?
No. Testing reduces risk; it cannot prove the absence of every defect. That is why good projects also include monitoring, error alerts and a post-launch warranty period.
Is QA worth it for a small internal tool?
Yes, scaled to the risk. A small tool may need only a modest set of automated tests and a focused round of user testing. The point is to match testing effort to the damage a bug could do.
What is regression testing?
Regression testing re-checks existing features after a change, to make sure nothing that used to work has broken. Automating it is one of the best investments in a long-lived system.
Who is responsible for UAT?
You are, with support from your developer. The agency should provide a staging environment, test scenarios and a way to log issues, but only your team can confirm the software fits how your business actually works.
Quality you can sign off with confidence
Testing is cheapest when it is planned from the first week rather than squeezed in at the end. If you'd like a fixed-price project with QA and user acceptance testing built into the schedule, let's talk about what you're building. Our services page explains how we run projects from discovery to launch.