What Is QA Testing? Types, Process and Tools

QA testing (quality assurance testing) is the planned work of checking whether software meets its requirements and works for the people who use it, before release. A QA tester reviews requirements, designs and runs manual or automated tests, reports defects with evidence, retests fixes, and tells the team what risk is left. The result is an informed release decision, not a promise of zero bugs.

Qodex can run part of this loop: describe a flow in a sentence, and it drives the real app, shows a screenshot of what broke, and saves the run as Playwright you own. See Qodex UI testing.

What is QA testing?

QA testing is the everyday name for software testing done inside a quality process. Testing finds defects and evaluates work products. It includes static work, such as reviewing a requirement or reading code, and dynamic work, such as running the software and comparing actual results with expected ones. It checks the build against the written requirements and against what users need, which are two different questions. Source: ISTQB Certified Tester Foundation Level syllabus v4.0.1, read 23 October 2026.

The phrase joins two things that are not the same. The ISTQB syllabus calls QA "a process-oriented, preventive approach" and testing "a product-oriented, corrective approach", and names testing as "a major form of quality control". A team can have an excellent process and still ship a broken checkout page.

Source for the QA and testing columns: the same syllabus, section 1.2.2, read 23 October 2026. It names testing as one form of QC; the others it lists are formal methods, simulation and prototyping. It also says QA "is the responsibility of everyone on a project". For a longer comparison, see QA vs QC.

A QA test, in casual use, means a single check: an input, a set of conditions, and an expected result. Written down with its steps, data and preconditions, that check is a test case. For the mechanics, see writing test cases in software testing.

Two limits shape the whole job. "Testing shows the presence, not the absence of defects," and "Exhaustive testing is impossible" except in trivial cases. A green suite is evidence, not proof. That is why testers spend their time choosing what to test rather than trying to test everything.

Types of QA testing

QA testing types are sorted two ways at once. A test level says how much of the system is under test, from one component to the whole product. A test type says which quality you are checking, such as function, speed or security. The ISTQB syllabus describes five levels and four types, and says the four types can be applied at every level. Source: ISTQB CTFL syllabus v4.0.1, section 2.2, read 23 October 2026.

Test levels

The syllabus lists the forms of acceptance testing as user acceptance testing (UAT), operational, contractual and regulatory acceptance testing, alpha testing and beta testing. Alpha and beta testing are covered, together with gamma testing, in alpha, beta and gamma testing. Unit testing has its own guide: unit testing with examples. So does system testing.

Test types

• Functional testing checks what the system should do: completeness, correctness and appropriateness of its functions. See functional vs regression testing.

• Non-functional testing checks how well it behaves. The syllabus uses the ISO/IEC 25010 list: performance efficiency, compatibility, usability, reliability, security, maintainability, portability and safety. Performance, security and usability testing all sit here. See performance testing, security testing and usability testing.

• Black-box testing derives tests from the specification, without looking at the internal structure.

• White-box testing derives tests from the code, architecture or data flows, and aims to cover that structure.

Testing after a change

Two more names come up in QA plans. Confirmation testing, also called retesting, checks that a defect was fixed. Regression testing checks that the change broke nothing else, in the same component, other components or connected systems. The syllabus calls regression testing "a strong candidate for automation" because the suite is run many times and generally grows with each release. See retesting vs regression testing.

Manual and automated testing are not types in this scheme. They are ways to run any of the above, covered further down. Smoke, sanity, exploratory and end-to-end testing are other names you will meet. The full list lives in types of software testing.

The QA testing process, step by step

The ISTQB syllabus describes seven groups of test activities: planning, monitoring and control, analysis, design, implementation, execution, and completion. They look sequential on a page, but the syllabus says they can run iteratively or in parallel, tailored to the project. Take one small feature, a login flow with an email and password form, and follow it through all seven.

1. Test planning. Define the objectives and pick an approach that fits the constraints. For the login flow: confirm that valid users get in, invalid ones do not, lockout works after repeated failures, and the reset link expires. The approach is automated API checks for the auth endpoint plus a short manual pass on the form. Setting up an automation QA process covers the groundwork if this is your first suite.

2. Test monitoring and control. Monitoring compares actual progress against the plan. Control is what you do when they diverge. Partway through, the password reset email is not arriving in the test environment, so that slice is parked and the lockout cases move up. This is the decision about where the remaining hours go.

3. Test analysis. This answers "what to test?" by reading the test basis, the acceptance criteria and the API contract, and pulling out testable conditions. Login conditions include valid credentials, wrong password, unknown email, empty fields, locked account, expired reset token, case handling on the email, and a session cookie with the right flags. Each is prioritized by risk.

4. Test design. This answers "how to test?" by turning conditions into cases with concrete inputs and expected results, and by specifying data and environment. Wrong password becomes: a known user, a wrong string, the failure status your API contract specifies, a generic error message, no session cookie. The generic message matters, because a specific one can tell an attacker the email exists.

5. Test implementation. Build or acquire everything the run needs. Seed accounts for each required state: active, locked, unverified, deleted. Write the API checks, arrange the cases into a suite, and verify the environment points at the right build. For a wider flow than one endpoint, see end-to-end testing.

6. Test execution. Run the suite against the build, compare actual results with expected ones, log them, and analyze anomalies before reporting. The locked-account case returns the ordinary wrong-password status instead of the locked status your contract defines. That is one anomaly, one root cause to check, one defect report with the request and response attached.

7. Test completion. At the release milestone, open defects become tickets rather than disappearing, reusable testware is archived or handed over, and the team writes down what it learned. For login, the reset-email gap is now a filed limitation of the test environment, with an owner.

Each AI draft in that last column still needs a tester to check it. Does the risk list match the business? Do the assertions check correct behaviour, not current behaviour? Was a real defect dismissed as flaky?

Manual versus automated QA testing

The question is not which is better. It is which check belongs in which bucket, and the answer follows from how stable and how repeated the check is.

Automation earns its keep on repetitive regression work. It gives consistent execution, wider coverage in the time available, and fast feedback on every change. The costs are real too. Automated tests need maintaining as the product moves, and they tie you to a tool. A suite that only runs scripts also loses the human judgment that spots what nobody thought to assert. Source: ISTQB CTFL syllabus v4.0.1, read 23 October 2026.

A workable rule: automate checks that are stable, repeated and cheap to judge as pass or fail. API contracts, core user journeys, calculations, and the regression set around anything that has broken before. Keep human-led anything that needs a judgment call: exploratory testing of a new feature, usability, visual sense, accessibility review, and any flow whose expected result is still being argued about.

The sequencing matters as much as the split. A flow that changes every sprint is expensive to automate and cheap to test by hand. Wait until it settles, then automate it. For the full trade-off, see manual testing vs automation testing.

Who does QA testing: tester, SDET and QA lead

Three roles carry the day-to-day testing work, and developers test their own components too.

QA tester or QA analyst. The US labor data calls the job Software Quality Assurance Analyst and Tester. O*NET lists designing test plans, scenarios, scripts and procedures, and documenting defects "using a bug tracking system" and reporting them to developers. Source: O*NET 15-1253.00, read 23 October 2026. Day to day, that is the seven-step loop above: read the change, rank the risk, design cases, run them, report with evidence, retest.

QA automation engineer or SDET. An SDET (Software Development Engineer in Test) is, in TestGuild's definition, "a software engineer whose main job is building quality into the product with code": automation frameworks, testability work, and tests wired into CI/CD. Source: TestGuild, What is an SDET?, read 23 October 2026. See what an SDET is and how the role compares with QA.

QA lead or test manager. Owns the test strategy, the plan and the team, and reports release risk to engineering and product. See the QA lead job description.

Developers test too. In the syllabus example of independent testing, developers run component and component integration tests, a test team runs system tests, and business representatives run acceptance tests.

Skills a QA tester needs

The ISTQB syllabus lists the generic skills relevant for testers. Testing knowledge comes first, so technique makes the work effective. Then thoroughness, carefulness, curiosity, attention to detail and being methodical, which is how hard-to-find defects surface. Then communication and active listening, analytical thinking, critical thinking and creativity. Last, technical knowledge, so tools make the work efficient, and domain knowledge, so you can talk to the people who will use the thing. Source: the same syllabus, read 23 October 2026.

Communication sits high on that list for a practical reason. How a defect is reported decides whether it gets fixed or argued about.

Does a QA tester need to code? It depends on the role. Manual, exploratory and requirements-focused testing is real work and needs no code. But coding widens the job fast. You can write and repair automated checks, read the application code to work out where a bug lives, query the database to confirm a state, and script your own test data. A practical starting point is one scripting language, SQL, and enough HTTP to read an API response.

Domain knowledge pays off in defects. A tester who understands how settlement works at a payments company finds defects that tooling alone does not surface.

QA testing tools and how to choose them

Pick tools by the job they do, not by a popularity list. The ISTQB syllabus groups tool support by activity: test management, static analysis, test design and data preparation, test execution and coverage, non-functional testing, DevOps, and collaboration.

• Test and defect management. Where cases, runs and defects live, and how they trace back to requirements. This can be the issue tracker the team already uses.

• Browser and UI testing. Playwright Test is an end-to-end framework for web apps that bundles a test runner, assertions, isolation and parallelization. It supports Chromium, WebKit and Firefox, and its install page lists Node.js 22.x, 24.x or 26.x. Source: Playwright installation docs, read 23 October 2026.

• Browser automation, the older stack. Selenium is "an umbrella project for a range of tools and libraries". Its WebDriver "uses browser automation APIs provided by browser vendors to control the browser and run tests". Source: Selenium overview, read 23 October 2026.

• API testing. Postman runs JavaScript post-response scripts after a request, where you write and validate API tests, and its docs name contract, unit, end-to-end and load testing as "some of the most common approaches to API testing". Source: Postman test script docs, read 23 October 2026. For what to check on an endpoint, see API testing.

• Performance, security and accessibility. Non-functional work needs its own tools, because a functional suite will pass while the page takes far too long to load.

• CI and delivery. Whatever runs the suite on every change. A suite nobody runs automatically decays.

Choose in this order: what you are testing, which job you are short on, what your team can already maintain, which environments you must cover, and how it fits your pipeline. If budget is the constraint, free software testing tools covers the open-source end.

Where AI fits in QA testing

Generative AI can assist across the testing process: analyzing requirements, designing tests, writing automation and reporting results. The ISTQB generative AI syllabus also names the risks to manage: hallucinations, bias, security, privacy and environmental impact. Source: ISTQB Testing with Generative AI, syllabus v1.1, read 23 October 2026.

Where it helps today: drafting test conditions from a requirement, generating a first pass of test data, and writing boilerplate automation. It also groups a wall of failures into likely causes, proposes a repair when a selector or a contract moved, and drafts the run summary. For what agentic AI adds to this, and where it stops, see AI QA.

The failure mode worth naming is the quiet one. A model asked to write tests for existing code can assert what the code does today, which locks in the bug you already have. It may not notice that the requirement itself was wrong. Accountability does not transfer to the model.

One vendor survey gives a sense of the current pull. PractiTest's State of Testing reports 76.8% AI adoption among its respondents, with 70% using AI for test case creation and 19.9% for risk identification. Those are PractiTest's figures from its own respondents, not an industry census. PractiTest's own reading: teams are "simply building a faster factory". Source: PractiTest State of Testing, read 23 October 2026.

Using AI to help you test is not the same as testing an AI system. The second is its own discipline, with its own ISTQB syllabus. Source: ISTQB Certified Tester AI Testing, syllabus v2.0, read 23 October 2026.

QA testing best practices

• Start from risk. Since exhaustive testing is impossible, first ask what hurts most if it breaks. Order the work by that, not by the order features were built.

• Test early, on requirements. Review an acceptance criterion while the ambiguity can still be removed, and a defect goes away before code exists. Static work is testing.

• Trace cases to requirements. If nobody can say which requirement a case covers, nobody can say what is uncovered.

• Use production-like environments and data. A bug that appears in one environment only can be a configuration difference.

• Keep both hands. Automated regression for the stable and repeated, human sessions for the new and uncertain.

• Maintain testware like code. Review it, delete what is dead, and treat a flaky test as a defect in the suite.

• Report evidence, not verdicts. What was covered, what was not, what is still open, and what risk shipping carries today.

• Fit the delivery method. Agile and waterfall methodologies covers where the activities land in each.

Conclusion

QA testing is an operating model, not a list of test types. You decide what is worth testing based on risk, pick the levels and types that cover it, design the checks, build the data and the environment, run them, and report evidence. Automation and AI change who drafts the work and how fast it runs. They do not change who is accountable for what ships.

Frequently Asked Questions

What does QA stand for in software testing?

QA stands for quality assurance. In software it means the process work that prevents defects, and in everyday use "QA testing" also covers the testing that finds them.

What is QA testing in simple terms?

QA testing is checking software against what it is supposed to do, before users find the gaps. It covers reviewing requirements, designing checks, running them, reporting defects with evidence and confirming fixes.

What are the types of QA testing?

By level: component (unit), component integration, system, system integration and acceptance testing. By type: functional, non-functional (performance, security, usability and others), black-box and white-box. After a change: confirmation testing and regression testing. Source: ISTQB CTFL syllabus v4.0.1, read 23 October 2026.

What are the seven steps in the QA testing process?

Planning, monitoring and control, analysis, design, implementation, execution, and completion. They are groups of activities that can run iteratively or in parallel, tailored to the project.

Is QA testing manual or automated?

Both, on different work. Automate stable, repeated checks that are cheap to judge, such as API contracts and core regression paths. Keep exploratory testing, usability, and anything still under discussion in human hands.

Is QA testing a hard job?

It is detailed work more than hard work. The skills ISTQB lists are thoroughness, curiosity, communication and critical thinking, plus technical and domain knowledge. The harder part is judgment: choosing what to test when you cannot test everything.

How do I become a QA tester?

Learn the fundamentals (levels, types, the test process and test case design), then practise on a real application and file defect reports with evidence. Add one automation tool and basic SQL. The ISTQB Foundation Level qualification "is aimed at anyone involved in software testing" (CTFL syllabus v4.0.1, read 23 October 2026). O*NET places the role in Job Zone Four and notes that "most of these occupations require a four-year bachelor's degree, but some do not" (read 23 October 2026).

What is the difference between QA and software testing?

QA is process-oriented and preventive, aimed at how software gets built so fewer defects appear. Testing is product-oriented and corrective, aimed at the thing you built. The phrase QA testing covers both.

Can AI replace QA testers?

Not on the parts that decide quality. A model can draft cases quickly. It may miss that the requirement was wrong, it cannot judge whether the risk ranking matches the business, and it cannot take responsibility for a release.