What is QA testing?

What is QA testing?

QA testing is the testing that a quality assurance (QA) team does when it runs or examines software to find defects before users do. Quality assurance, also called software quality assurance (SQA), is a set of activities that aims to prevent defects by improving how a team builds and tests software. Many teams use "QA" for both.

The International Software Testing Qualifications Board (ISTQB) defines quality assurance as activities that give confidence that quality requirements will be met. Its Foundation Level syllabus keeps testing and QA apart. It calls testing a form of quality control, which checks the product so that defects can be fixed. QA improves the process so that fewer defects are made.

In job listings, "QA testing" usually means the work of a QA engineer who tests each release. That work uses the same levels and types as any other software testing.

How does QA testing work?

QA testing on one release usually runs in seven steps:

1. A QA lead writes a test plan with the scope and the exit criteria for release.
2. A tester designs test cases from the requirements, each with steps and an expected result.
3. The team prepares test data and an environment close to production.
4. Testers run the test cases by hand or as automated checks in a continuous integration and delivery (CI/CD) pipeline.
5. Testers log each failure as a defect report with the steps, the expected result, and the actual result.
6. Developers fix the defects, and testers rerun the failed test cases.
7. The QA lead checks the results against the exit criteria, e.g. no severe defect left open. The lead then signs off or recommends holding the release, and the team decides whether to wait or accept the open risks.

Quality assurance sets how the team works before any test runs, e.g. a rule that a second developer does a code review of each change. Test results flow back two ways, as fixes to the product and as changes to the process.

What is an example of QA work?

Here is an illustrative example. Acme Co. sells furniture online, and one QA engineer tests each release of its web store. A developer asks a coding agent to "Let customers edit their delivery address during checkout." The work runs in six steps:

1. The QA engineer writes a test case from the request, with 2 items in the cart and the address "12 Elm Street".
2. The agent writes the code and some tests of its own. The tests pass, and the change merges.
3. On the release candidate, the QA engineer's test case fails. The address saved, but the cart emptied.
4. The QA engineer files the defect report below.
5. The developer has the agent fix the checkout session code. The QA engineer runs the test case again, and it passes.
6. The release review finds that the agent's tests checked only the address. The team adds a rule that each checkout change needs a test of the cart items.

Title:    Cart empties after a delivery address change
Steps:    1. Add 2 items to the cart and start checkout
          2. Change the address to "12 Elm Street" and save
Expected: The review page shows 2 items
Actual:   The review page shows 0 items

Steps 1 and 3 to 5 are testing, a form of quality control, because they designed a check, found one defect in the product, and confirmed its fix. Step 6 is quality assurance, because it changes how the next checkout change gets built. This example is simplified. A real QA process would also track where defects come from across releases.

What does a QA engineer do?

A QA engineer is the team member whose main job is quality. The work usually includes these tasks:

• Planning. The QA engineer decides what to test from the requirements and the risks.
• Testing. The QA engineer runs test cases and exploratory testing sessions.
• Automation. The QA engineer builds and maintains test automation for checks that repeat on each change.
• Reporting. The QA engineer files defects with exact steps and checks each fix.
• Process work. The QA engineer suggests process changes when a kind of defect keeps coming back.

Before a large release, a QA engineer may run a bug bash with people from across the team. A QA engineer's checks ask whether the software matches its specification and whether it meets users' needs, the two questions behind verification and validation.

Developers find many defects in their own code, and testers who did not write it tend to find other kinds. The ISTQB syllabus therefore recommends several levels of independence for most projects.

What changes when a coding agent writes the code?

A coding agent can produce changes faster than a person can test them by hand. DORA's 2025 research, a survey of nearly 5,000 technology professionals, found that AI adoption went with higher delivery throughput but still with lower delivery stability. In the same DORA research, 30% of respondents had little or no trust in AI-generated code. DORA adds that without strong controls, e.g. automated testing, more change volume leads to instability.

The agent usually writes its own tests too. When an agent tries to check its own code, it works from the same prompt and context, so its tests tend to miss what its code missed. In vibe coding, the running app can go untested.

The practical adjustment is to move QA effort from repeating scripted checks by hand to deciding what a change must show before anyone calls it "done." In the Acme example, the QA engineer's test case, written from the request before the agent started, found the empty cart. Keep such checks in files the agent does not edit.

What are the limits of QA testing?

QA testing gives evidence about a release, not proof that it works. Its main limits are:

• Testing samples the software. Testers choose which inputs and paths to try, so a defect can sit in a case nobody picked. No findings is not the same as complete coverage.
• A good process can still build the wrong thing. Software can pass each planned check and still miss what its users need.
• A separate QA stage can become a queue. The ISTQB syllabus warns that independent testers can be seen as a bottleneck and that developers can lose a sense of responsibility for quality.
• Testing at the end finds defects late. A defect found on a release candidate sends the change back to the developer. Starting checks while the code is being written is called shift-left testing.

How is testing different from quality assurance and quality control?

Testing is a form of quality control (QC), and quality assurance works on the process around both. The ISTQB defines quality control as activities that evaluate the quality of a component or system. The three differ in what they act on:

The syllabus names other forms of QC, e.g. simulation, and says QA is the responsibility of everyone on a project.

Who checks the software when agents write most of the code?

Someone other than the author still needs to run the software and compare what it does with what was asked. That can be a person who did not write the change, e.g. a QA engineer, or a separate testing agent. A small team without a QA engineer can follow the steps to test an app before real users arrive.

RunStory considers your prompts and code changes to decide what to test. A testing agent uses your software in a separate environment, tries relevant workflows, and checks the results while you keep working. RunStory is in private alpha for CLIs and web apps, and your team keeps the final release decision.

Join the RunStory alpha →

FAQs

Is QA only about finding bugs?

QA is not only about finding bugs. Quality assurance aims to prevent defects by improving how a team builds and tests software. Testing finds defects already in a build, and QA uses patterns in those defects to change the process.

Is AI changing how teams do QA?

AI is changing QA by raising the number of changes a team produces. When a coding agent writes the code and its tests, teams can move QA effort from repeating scripted checks by hand to deciding what a change must show.

What does QA sign-off mean?

QA sign-off is a QA lead's confirmation that a release met the exit criteria in the test plan, e.g. no severe defect left open. When the criteria are not met, the QA lead recommends holding the release, and the team decides whether to wait or accept the open risks.

Should developers test their own code?

Developers should test their own code, and someone who did not write it should test it too. The author finds many defects, and an independent tester tends to find other kinds. A coding agent's own tests need the same second check.