QA Testing: Process, Skills, Tools, and AI

QA testing is the planned work used to check whether software meets its requirements, works for real users, and carries an acceptable level of risk. A QA tester analyzes requirements, designs and runs manual or automated tests, records evidence, reports defects, retests fixes, and helps the team decide whether to release. QA testing covers more than executing scripts. It also covers planning, monitoring, analysis, and completion.

If you would rather have that loop run for you, Qodex runs API, UI, and security tests on every pull request and deploy, and returns each finding with the failing request, response, and screenshot. See Qodex.

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 against expected ones. It checks the build against the written requirements and against what users actually need, which are two different questions. Source: ISTQB Certified Tester Foundation Level v4.0.1 syllabus, read 19 September 2026.

QA and testing are not the same thing, even though the phrase joins them. The ISTQB syllabus calls QA "a process-oriented, preventive approach" aimed at improving how work gets done, while testing is product-oriented quality control that examines the thing you built. A team can have excellent process and still ship a broken checkout page.

A QA test, in casual use, usually 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. The case is the recipe; the run is the cooking. 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. Source: the same syllabus, read 19 September 2026.

Testing is also grouped in several ways at once, by level such as unit or system, by objective such as functional or performance, and by technique such as black box or white box. The full breakdown lives in types of software testing; this article is about the work and the process around it.

What does a QA tester do?

The job title in the US labor data is Software Quality Assurance Analyst and Tester. The listed tasks are concrete. O*NET names designing test plans, scenarios, scripts and procedures, and developing "testing programs that address areas such as database impacts, software scenarios, regression testing, negative testing, error or defect analyses". It also names documenting defects "using a bug tracking system" and reporting them to developers. Source: O*NET 15-1253.00, read 19 September 2026.

Day to day, that turns into a loop. A tester reads a new requirement or user story and asks what could go wrong with it, which is review work that needs no running software and catches ambiguity before any code exists. Then comes risk: which parts of this change could hurt the most users or the most money if they break. The answer decides where the testing hours go.

Next the tester designs cases against that risk, including the unhappy paths nobody writes down: expired cards, duplicate submissions, a network drop halfway through a payment. Then the environment and the data have to exist. A database seeded with the right account states, a test user with the right permissions, a build deployed somewhere stable enough to trust.

Execution follows, manually or through automation, and the tester logs what actually happened. A defect report without evidence tends to come straight back, so the record matters: the steps, the build, the request or the screenshot, the log line. When a fix lands, the tester retests it and then runs the regression set around it. Retesting confirms the one fix; regression testing confirms that nothing around it moved.

Finally, the tester feeds the release decision by stating what was covered, what was not, which defects are still open, and what risk the team carries if it ships today. The decision belongs to the team. The evidence belongs to the tester.

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 they are usually run iteratively or in parallel, and they are tailored to the project. Source: ISTQB CTFL v4.0.1 syllabus, read 19 September 2026. 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 not paperwork. It 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, verify the environment points at the right build. This is where automation is written rather than planned. 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, 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.

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, reporting that does not depend on someone remembering, 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 v4.0.1 syllabus, read 19 September 2026.

A workable rule: automate checks that are stable, repeated often, 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. The two also feed each other: exploratory sessions find the cases worth automating, and the automated suite frees the hours those sessions need. If you want to know whether the split is working, test automation metrics covers what to measure.

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 good 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: ISTQB CTFL v4.0.1 syllabus, read 19 September 2026.

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

On the technical side, O*NET lists programming and systems analysis among the skills for this occupation, alongside quality control analysis and critical thinking. Source: O*NET 15-1253.00, read 19 September 2026.

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

Does it need a degree? O*NET puts the occupation in Job Zone Four, Considerable Preparation Needed, and notes that most of these occupations require a four-year bachelor's degree, but some do not. Read that as the pattern in the data, not as an entry rule. Source: O*NET 15-1253.00, read 19 September 2026.

Domain knowledge is the most underrated of these. 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. Source: ISTQB CTFL v4.0.1 syllabus, read 19 September 2026.

• Test and defect management. Where cases, runs, and defects live, and how they trace back to requirements. Often this is whatever issue tracker the team already uses.

• Browser and UI testing. Playwright Test is an end-to-end framework for web apps with its own runner, assertions, test isolation, and parallel execution, across Chromium, WebKit, and Firefox. Its install page currently lists Node.js 22.x, 24.x, or 26.x. Source: Playwright installation docs, read 19 September 2026.

• Browser automation, the older stack. Selenium is a project rather than one tool. WebDriver controls a browser through the automation APIs the browser vendors provide, so tests drive the same application you ship. The IDE records actions as a starting point, and Grid distributes runs across machines and platforms. Source: Selenium overview, read 19 September 2026.

• API testing. Postman runs JavaScript after a response comes back, so you can assert on status, body, and headers, and its docs name contract testing, unit testing, end-to-end testing, and load testing as the most common approaches. Source: Postman test script docs, read 19 September 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 happily pass while the page takes far too long to load.

• CI and delivery. Whatever runs the suite on every change. A test 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. A tool your team cannot maintain is a liability whatever its feature list. If budget is the constraint, free software testing tools covers the open-source end.

How AI changes QA testing

Generative AI can assist across the testing process: analyzing requirements, designing tests, writing automation, reporting results, and improving the process itself. The same source is explicit that human review stays necessary, because these models hallucinate, carry bias, and raise security and privacy questions when you feed them your data. Source: ISTQB Testing with Generative AI, syllabus v1.1, read 19 September 2026.

Where it actually 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. Every one of those is a draft that needs a tester to approve it.

The failure mode worth naming is the quiet one. A model asked to write tests for existing code tends to assert what the code does today, which locks in the bug you already have, and it may never notice that the requirement itself was wrong. It can also produce test data that could never exist in production, or explain a red run as flakiness when it was a real defect. Accountability does not transfer to the model.

One vendor number gives a sense of the current pull. PractiTest's State of Testing survey reports 76.8% AI adoption among its respondents, with 70% using AI for test case creation and only 19.9% for risk identification. Those are PractiTest's figures from its own respondents, not an industry census, and the page does not expose its sample size. PractiTest draws the conclusion itself: rather than using AI to escape the "test factory", it says, teams are simply building a faster factory. Source: PractiTest 2026 State of Testing, read 19 September 2026.

One distinction keeps getting blurred. Using AI to help you test is not the same as testing an AI system. The second one is its own discipline, covering probabilistic behavior, non-determinism, training data, models, and quality characteristics that conventional software does not have. Source: ISTQB Certified Tester AI Testing, syllabus v2.0, read 19 September 2026.

QA testing best practices

None of these are new. They are what separates a QA function that catches things from one that files tickets after release.

• Start from risk. Since exhaustive testing is impossible, the first question to answer is 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 only appears in one environment is often a configuration difference, and chasing it twice is wasted time.

• 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 rather than background noise.

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

• Fit the delivery method. Testing in short iterations looks nothing like testing in a phased plan. 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, design the checks, build the data and the environment, run them, report evidence, and hand back a release decision the team can trust. 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 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. The goal is an informed release decision, not a promise of zero bugs.

What is a QA test?

A QA test is a single check: given this input and these conditions, the software should do this. Written down with its steps, data, and expected result, it becomes a test case, which is what gets reviewed, reused, and automated.

What does a QA tester do day to day?

Reads requirements and asks what could go wrong, ranks areas by risk, writes test cases and seeds test data. Then runs manual and automated tests, logs defects with evidence, retests fixes, and reports what is covered and what is still open. Source: O*NET 15-1253.00, read 19 September 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 often run iteratively or in parallel rather than in strict sequence, tailored to the project. Source: ISTQB CTFL v4.0.1 syllabus, read 19 September 2026.

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.

Does a QA tester need coding skills?

Not for every role. Manual, exploratory, and requirements-focused testing is real work and needs no code. Coding widens the job: you can write and repair automation, read the application to narrow down a bug, query the database, and generate test data. One scripting language, SQL, and basic HTTP is a common place to start.

Which tools do QA testers use?

One per job rather than one for everything. A test and defect management tool, a browser framework such as Playwright or Selenium, and an API tool such as Postman. Then separate tools for performance, security and accessibility, and a CI system to run the suite.

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. Source: ISTQB CTFL v4.0.1 syllabus, read 19 September 2026.

How is AI changing QA testing?

It is moving the drafting work. Models propose test conditions, generate test data and automation, group failures by cause, and suggest repairs after a UI or contract change. Human review stays necessary because of hallucination, bias, security, and privacy risks. Source: ISTQB Testing with Generative AI, syllabus v1.1, read 19 September 2026.

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. It also tends to assert what the code does rather than what it should do, which is the bug you were looking for.