Michael Pigott
Michael is a Market Research Analyst at G2 with a focus on technology research. Prior to G2, Michael worked at a B2B marketing services organization, where he assisted tech vendors with market assessments and competitive positioning. In his free time, Michael enjoys traveling, watching sports, and playing live shows as a drummer.
Last updated: August 7, 2026
What is QA testing?
QA testing is the process software teams use to detect, verify, and fix defects, errors, and performance issues in an application before it ships to users. It pairs structured test planning with manual and automated execution to confirm the software holds up against its functional, performance, and quality requirements, rather than just checking for individual bugs in isolation.
Some companies build QA testing into their in-house development process; others outsource it to dedicated testing and QA providers or lean on automation testing software to run test suites without manual effort on every release.
TL;DR: QA testing definition, process, and types
QA testing is the process of detecting, verifying, and fixing defects in software before release, using a repeatable cycle of planning, designing, executing, and tracking tests. It covers several types, from unit and integration testing up through regression, performance, and user acceptance testing, and it's distinct from quality control (QC), which inspects the finished product rather than the process that built it.
How does QA testing work?
QA testing runs as a six-step cycle: plan, design, execute, log and track defects, retest and verify, then report and sign off.
- Plan. The team maps out what's in scope, flags the biggest risks, lines up the environments needed, and sets the overall test strategy before writing a single test case.
- Design. Testers translate that plan into concrete test cases and scripts based on the software's requirements, then pull together whatever test data those cases will need.
- Execute. The team runs the planned tests, whether by hand or through automation testing tools like Selenium or Playwright, plus API testing tools like Postman to confirm back-end services respond the way they should.
- Log and track defects. Every defect gets logged with enough detail for a developer to act on it: how to trigger it, how severe it is, and screenshots or logs that back it up, typically inside a bug tracker like Jira.
- Retest and verify. Once a developer fixes a defect, testers confirm the fix actually holds and rerun the regression suite to make sure nothing else broke in the process.
- Report and sign off. The team pulls together a quality snapshot for stakeholders and makes the call on whether the release is ready to ship.
This cycle repeats continuously through the software development lifecycle rather than running once at the end, often wired directly into a team's continuous integration pipeline so tests fire automatically on every code change, which is what lets teams catch defects while they're still cheap to fix.
QA testing vs. quality control (QC)
QA testing and QC both aim to ship reliable software, but they operate at different points in the process and with a different orientation. QA testing is the ongoing, preventive work of planning and running tests throughout development; QC is the after-the-fact inspection of the finished product against requirements.
| PARAMETERS | QA testing | Quality control (QC) |
|---|---|---|
| Focus | The process used to build the software | The finished product itself |
| Timing | Continuous, throughout the development lifecycle | After development, before release |
| Approach | Proactive: sets standards and runs planned tests to prevent defects | Reactive: inspects output to catch defects that got through |
| Goal | Prevent defects from being introduced in the first place | Confirm the finished product meets requirements before it ships |
| Example activities | Test planning, test case design, automated and manual test execution, defect logging | Final inspection, acceptance testing, release sign-off |
Most teams need both: QA testing reduces how many defects reach QC, and QC acts as the last checkpoint before a release goes out.
What are the types of QA testing?
QA testing breaks down into six core types: unit, integration, system, regression, performance, and user acceptance testing.
- Unit testing: Isolates a single function or component and runs it on its own, catching problems there before they ripple into the rest of the system.
- Integration testing: Takes components that already passed on their own and checks whether they behave correctly once wired together.
- System testing: Puts the whole assembled application through its paces against the full set of requirements, the way a real user would encounter it, such as checking a mobile app across different devices and screen sizes.
- Regression testing: Reruns prior tests after a code change lands, to catch anything the update accidentally broke.
- Performance testing: Puts the software under load to see how response time, uptime, and capacity hold up as traffic or data volume climbs.
- User acceptance testing (UAT): The last checkpoint before release, where the people who'll actually use the software, not the testers, try it against their own real tasks and sign off that it's ready.
Which teams and industries rely on QA testing most?
QA testing carries the heaviest weight in regulated industries and in mobile-first or high-traffic consumer software, where a defect has outsized cost. Finance, healthcare, and government software all operate under regulatory requirements that make defects a compliance risk as well as a user experience one, so their QA processes tend to be the most formalized and audited. E-commerce, retail, and mobile app teams face a different pressure: cross-device and cross-browser fragmentation plus checkout-flow reliability, where even a minor bug can cost a sale directly. Within an engineering organization, QA testing is typically owned by a dedicated QA or test engineering team working alongside developers, though smaller teams often have developers handle it themselves.
Related resources:
Frequently asked questions about QA testing
Common questions about QA testing, answered.
Q1. What's the difference between QA testing and software testing?
QA testing and software testing overlap heavily and are often used interchangeably, but QA testing specifically means testing carried out within a formal QA process, with defined standards, test plans, and sign-off criteria. Software testing is the broader, more generic term for the activity of running tests against software, whether or not a formal QA framework wraps around it.
Q2. Is a QA tester different from QA testing?
Yes. QA testing is the activity: the process of planning, running, and tracking tests. A QA tester is the person or role that carries out that activity. The distinction matters mainly for job searches and org charts rather than the testing process itself.
Q3. What's the difference between manual and automated QA testing?
Manual testing has a real person clicking through the application themselves, which is what catches usability problems and edge cases a script wouldn't think to check. Automated testing hands that same test to a tool that reruns it exactly the same way every time, which is what makes it the better fit for regression and performance checks that need to happen constantly. Most teams mix both rather than choosing one exclusively.
Q4. What does QA testing software do?
QA testing software gives a team a place to write test cases, run them, and keep track of what broke. Test management tools like TestRail keep every test case and run in one organized place, automation frameworks like Playwright and Selenium handle the repetitive job of clicking through browsers and UI elements so a person doesn't have to, and bug trackers like Jira make sure a logged defect actually reaches the developer who can fix it.
Ready to compare tools directly? Check out the best test management tools for your use case.
