QA testing (quality assurance testing) is the set of tests and procedures that checks whether software works as intended and meets users' needs, finding bugs and problems before a release reaches the public. It covers everything from small automated unit tests written by developers to manual exploratory sessions, performance and security testing.
This guide explains why QA testing matters, the types of testing and how they fit together in the test pyramid, when to test manually and when to automate, what shift-left testing means, how AI is changing testing in 2026, and which metrics show whether QA is working. It also looks at what a bug costs when it is found late, using the data from a well-known NIST study.
TL;DR / Key Takeaways
- QA testing checks that software works correctly, performs well, is secure and runs on the platforms users have, before it reaches them.
- The later a bug is found, the more it costs to fix: in NIST's illustrative example, a requirements error found after release costs thirty times more than one found at once.
- The test pyramid puts many fast unit tests at the base, fewer integration tests in the middle and few end-to-end tests at the top.
- Automate what repeats and must be checked on every change; keep manual testing for exploration, usability and new features.
- AI now helps generate tests and analyse failures, but people still decide what quality means and review what the tools produce.
Why is QA testing important in software development?
QA testing is important because it makes sure software works correctly and as intended before users rely on it. Bugs that reach production lead to a poor user experience and can damage a company's reputation. Finding them early also saves time and money, because a problem caught during development is far cheaper to fix than one found after release.
QA also confirms that the software meets the needs of users, not just the specification. A feature can pass every technical check and still be confusing, slow on a real device or broken in a browser nobody tested. Testing from the user's point of view catches those gaps.
The benefits add up across the product's life. Higher quality means fewer support requests, a better user experience, more satisfied customers who come back and recommend the product, and a competitive advantage over products that fail more often.
Finding bugs early is the cheapest way to fix them.
What does a bug cost when it is found late?
A bug costs more the later it is found, because fixing it means reworking everything built on top of it. In an illustrative example from a 2002 study for NIST, an error introduced during requirements and design costs 1X to fix at that stage, 5X during coding, 10X in system testing, 15X in beta testing and 30X after release.
The same NIST study, The Economic Impacts of Inadequate Infrastructure for Software Testing, estimated that inadequate software testing infrastructure cost the US economy $59.5 billion a year. It also estimated that feasible improvements in testing could reduce that cost by $22.2 billion, with software users bearing about 60 percent of the total and developers about 40 percent.
The figures are more than twenty years old and the multipliers are an example, not a universal law. The direction has not changed, though: every stage a defect survives adds rework, delays and, once it reaches users, support and reputational costs.
What are the main types of QA testing?
The main types of QA testing check different qualities of the software. Functional testing checks that features do what they should; performance testing checks speed and resource use; security testing checks protection against threats; compatibility testing checks different platforms and devices. Usability, accessibility and regression testing complete the picture.
- Functional testing: checks that each feature performs as expected, from a single function to a complete user journey.
- Performance testing: measures speed, response times and resource use, including behaviour under peak load.
- Security testing: checks that the software is protected from threats, from vulnerable dependencies to access control flaws.
- Compatibility testing: checks the software on different platforms, devices, browsers and operating systems.
- Regression testing: re-runs existing tests after every change to make sure nothing that worked before is broken.
- Usability and accessibility testing: checks that real people, including people with disabilities, can use the product easily.
These map onto the quality characteristics defined in ISO/IEC 25010, the international product quality model, which defines nine quality characteristics, from functional suitability and performance efficiency to compatibility and interaction capability. It is a useful checklist when deciding which kinds of testing a product needs.
What is the test pyramid?
The test pyramid is a model for balancing automated tests. It puts many small, fast unit tests at the base, a smaller number of integration tests in the middle and only a few slow end-to-end tests through the user interface at the top. The shape keeps the test suite fast, reliable and cheap to maintain.
Martin Fowler's Test Pyramid explains the reasoning. End-to-end tests are valuable because they test the product as users see it, but they are slow, break easily when the interface changes and are harder to debug. Unit tests are fast and precise, so most checks should live there.
The practical test pyramid by Ham Vocke adds two rules: write tests with different granularity, and the more high-level a test is, the fewer of them you should have. Teams that invert the pyramid, with mostly manual or UI tests, usually end up with slow releases and a suite nobody trusts.
Should you use manual or automated testing?
Use both, for different jobs. Automate the tests that repeat on every change, such as unit, regression, API and performance tests, so they run in the pipeline in minutes. Keep manual testing for exploratory work, usability, new features still changing and anything where human judgement is the point of the test.
| Manual testing | Automated testing | |
|---|---|---|
| Best for | Exploratory testing, usability, new or changing features, one-off checks | Regression, unit, API, performance and cross-browser checks on every change |
| Speed | Slow; depends on tester time | Fast once written; runs on every commit |
| Upfront cost | Low | Higher: tests must be written and maintained |
| Cost over time | Grows with every release | Falls per run as the suite is reused |
| Finds | Unexpected behaviour, confusing flows, visual problems | Regressions and known failure modes, reliably and repeatably |
| Risk | Human error and inconsistency | Brittle tests and false confidence if coverage is poor |
The return on test automation comes from repetition. A test that runs on every change for years pays back its cost many times; a test for a screen that will be redesigned next month may not. Start with the checks that are most repetitive and most costly to get wrong.
At WWG we use Katalon as our QA testing tool for automation. Its interface and automation features help us test functionality, performance, security and compatibility, and its reporting lets us act on issues quickly. Our automated testing and manual testing services cover both sides.
What is shift-left testing?
Shift-left testing means moving testing earlier in the development process, closer to when code and requirements are written, instead of leaving it to a separate phase before release. Developers write tests with their code, testers review requirements and designs, and automated checks run on every change in the CI/CD pipeline.
The logic follows directly from the cost of late bugs. If a defect found in system testing costs ten times more than one found during design, the cheapest place to test is as early as possible. Reviewing requirements for testability, and agreeing acceptance criteria before development, prevents many bugs from being written at all.
Code review is part of the same idea. A second pair of eyes on every change catches logic errors, security issues and missing tests before they reach the test environment, as we explain in the importance of code review.
How is AI changing QA testing in 2026?
AI is changing QA testing by speeding up the writing and maintenance of tests. AI assistants can draft unit and end-to-end tests from code or requirements, suggest edge cases, repair tests broken by small interface changes and help analyse why a pipeline failed. People still decide what quality means and must review everything the tools produce.
The main risk is false confidence. A tool can generate hundreds of tests that all pass but check very little, or that simply confirm the current behaviour, bugs included. Tests generated by AI need the same review as code generated by AI: do they test the right thing, and would they fail if the software were wrong?
AI also changes what needs testing. When part of the application code is written with AI assistance, regression suites, security scanning and code review become more important, not less. And when the product itself contains AI features, testing has to cover output quality, bias and failure modes that traditional pass-or-fail tests do not capture.
Which metrics show whether QA is working?
The most useful QA metrics show how many defects escape to production, how quickly they are fixed and how much the test suite can be trusted. Track the defect escape rate, the change fail rate of deployments, the time to fix defects, test coverage of critical paths and the share of flaky tests that fail at random.
- Defect escape rate: the share of defects found by users rather than by testing; the key outcome metric.
- Change fail rate: the share of deployments that need immediate intervention, one of the DORA metrics.
- Time to fix: how long it takes from finding a defect to releasing the fix.
- Coverage of critical paths: whether the journeys that matter most to users and revenue are tested automatically.
- Flaky test rate: the share of tests that pass and fail without code changes; a high rate means nobody trusts the suite.
Avoid measuring QA by the number of test cases or bugs logged. Both can grow while quality falls. For a team that needs dedicated testing capacity, our QA engineers work inside your team on these metrics, and our QA services cover strategy, automation and manual testing end to end.
To discuss how to make testing part of your delivery process, write to us at business@wwg.it.
Sources
- RTI for the National Institute of Standards and Technology (NIST), The Economic Impacts of Inadequate Infrastructure for Software Testing, Planning Report 02-3 (May 2002) — https://www.nist.gov/system/files/documents/director/planning/report02-3.pdf
- ISO 25000 portal, ISO/IEC 25010 product quality model — https://iso25000.com/index.php/en/iso-25000-standards/iso-25010
- Martin Fowler, Test Pyramid — https://martinfowler.com/bliki/TestPyramid.html
- Ham Vocke, The Practical Test Pyramid, martinfowler.com — https://martinfowler.com/articles/practical-test-pyramid.html
- DORA, DORA's software delivery performance metrics — https://dora.dev/guides/dora-metrics/
- Katalon — https://katalon.com/
FAQ
Frequently Asked Questions
Software testing is the activity of checking software for defects by running it. Quality assurance is broader: it covers the processes, standards and reviews that prevent defects in the first place, from clear requirements to code review and release checks. Testing is one of the most important QA activities, but QA also shapes how software is built.
QA should start at the beginning of the project, when requirements are written, not when the code is finished. Testers who review requirements and designs spot ambiguities and missing cases early, when they are cheapest to fix. From then on, automated tests run on every change and manual testing follows each feature as it is built.
Automate the tests that must run on every change and give the same answer each time: unit, integration, regression, API and key end-to-end journeys. Keep manual testing for exploration, usability and features that are still changing. The right share depends on the product, but most teams should aim for a suite that runs in minutes in the pipeline.
Yes, if quality is built into the way the team works. Developers write automated tests with their code, every change is reviewed by another person, and the pipeline blocks releases when tests fail. A small team still benefits from periodic exploratory testing by someone who did not build the feature, even if that person is not a full-time tester.
