TLDR
- A quality assurance test verifies that software behaves as expected.
- Quality assurance, quality control and testing are three different practices.
- The 4 levels are unit, integration, system and acceptance testing.
- A test is classified by its level, code visibility and the nature of the check.
- Find every type of testing in the summary table.
On a software project, saying quality assurance testing does not always point to the same practice. A quality assurance test can refer to nearly 30 different practices depending on what is being verified, which level is involved, and what information the tester can access. When a developer says "the tests pass" and a project manager says "the application has been tested," they are not necessarily talking about the same checks.
To tell them apart, we will classify software tests along three axes: their level, code visibility, and the nature of what they verify. A summary table then lets you compare the main types of tests at a glance.
Quality assurance, quality control, testing: three different things
Quality assurance (QA) acts on the process to prevent defects. Quality control (QC) evaluates the delivered product, while software testing verifies its behavior.
Quality assurance is therefore not about testing: it organizes the practices that limit how often defects appear.
Where testing sits in the development cycle
Testing runs throughout the software development life cycle (SDLC): requirements define expected behavior, design prepares the architecture, development produces the code, testing verifies that it works, deployment makes it available, and maintenance supports its evolution.
The shift-left principle means testing as early as possible in that cycle. The earlier a defect is found, the less time and resource its fix consumes, because it has not yet affected the later phases.
Testing serves five goals:
- verify conformance to requirements;
- detect defects before users do;
- protect the software as it evolves;
- provide results to support a go-live decision;
- document the application's expected behavior.
Testing contributes to software quality without guaranteeing the complete absence of bugs. Testing shows the presence of defects, never their absence: this is the first of the seven software testing principles defined by the ISTQB, which we return to in the FAQ.
Organizing the cycle this way also lets you audit your quality setup and identify the checks to reinforce before a defect reaches production.
Tests are classified along three independent axes: level, code visibility, and the nature of what is verified. The same test therefore belongs to all three classifications.
The 4 levels of testing
The 4 levels of testing correspond to the scope of software being verified, from an isolated component up to business validation of the complete application.
1. Unit testing
Unit tests verify a function, a method or a class in isolation. They are usually written by developers during development. A unit test might, for example, verify that a function calculates VAT correctly across several amounts and rates.
2. Integration testing
Integration tests check the exchanges between several components or services. They verify that elements which work separately communicate correctly once combined. A scenario might test an application's call to a payment API and how it handles the response.
3. System testing
System tests evaluate the complete application in an environment representative of real use. They verify the behavior of the system as a whole, with its components, interfaces and dependencies, before it is made available to users.
4. Acceptance testing
Acceptance tests, or UAT (User Acceptance Testing), verify that the software meets business needs and the defined acceptance criteria. This validation is carried out by the user, the client or their representatives before delivery is authorized.
The test pyramid
The test pyramid recommends a broad base of fast unit tests, supplemented by integration tests, then a smaller number of end-to-end tests. The higher a test sits in the pyramid, the wider its scope and, generally, the more expensive it is to run.
The anti-pattern is the inverted pyramid: many fragile E2E tests and few unit tests. The suite then becomes slower to run and heavier to maintain.
White-box, black-box, grey-box
Levels tell you at what scale you are testing; white-box, black-box and grey-box tell you with what information the test is carried out.
In white-box testing, code coverage measures which lines or branches are exercised. Other techniques examine the internal structure directly: path testing, loop testing, data flow testing and control flow testing. They serve to verify different execution paths through the source code.
Black-box testing is the standard mode for functional tests and E2E tests: the result is verified without regard to the implementation. Grey-box sits between the two, with partial knowledge of the architecture or the data.
A unit test is almost always white-box, while an acceptance test is almost always black-box.
Functional and non-functional testing
Functional tests answer one question: does the software do what it is supposed to do? Non-functional tests verify instead whether it does so properly, particularly in terms of performance, security, compatibility and accessibility.
Non-functional tests are often a blind spot in QA setups. A team can cover the expected features properly while neglecting performance, security or compatibility until the first production incident.
Specialized testing by context
- Mobile testing: combines emulators and real devices to cover many configurations and hardware-specific behavior.
- SaaS and multi-tenant testing: verifies in particular that one customer's data and actions stay isolated from those of other tenants.
- Data migration testing: checks data integrity after a migration or a recovery. Data conversion testing also verifies that values keep their format, meaning and relationships after transformation.
- API testing: verifies the API contract, its responses, its error codes and how versioning is handled.
Summary table of testing types
The same test can belong to several classifications. This table places the main types of tests by level, code visibility, nature and automation potential.
Manual or automated testing: how to choose
The difference between manual testing and automated testing lies in how they are executed. In the first case a tester performs the checks; in the second, a tool runs the same checks from scenarios defined in advance. The choice depends above all on the test's frequency, stability and cost of execution.
Automate repetitive, predictable tests
Regression testing comes first: the same checks must be replayed after every change to the software. The more repetitive, deterministic, frequent and expensive to redo by hand a test is, the more its automation makes sense.
Critical journeys run on every release follow the same logic. To go deeper on this choice, see how to move from manual testing to automation.
Keep humans where judgement is needed
Exploratory testing, and any assessment of usability or user experience, requires human interpretation. Automating a journey that changes every week, or a test run only once, also has little value: the time spent automating it risks exceeding the time saved.
Include maintenance in the calculation
An automated test is not free once it is written. Test scripts have to evolve with the application. A body of unstable tests, or flaky tests, ends up costing more than it returns in time and confidence.
One symptom comes up repeatedly in audits: tests disabled "temporarily" because they fail too often. When those exceptions accumulate, test automation no longer genuinely protects releases.
The automation rate is therefore not a goal in itself. 40% reliable tests beats 80% of tests you have to rerun three times before getting a usable result.
Testing in a CI/CD pipeline, and in Agile
In a CI/CD pipeline, continuous integration requires running each type of test at the moment its result is still useful. Unit tests and smoke tests run on every commit, integration tests on every merge, and regression tests before a release. Longer non-functional tests can run overnight.
This organization lets you put continuous testing in a pipeline in place without slowing the development cycle unnecessarily.
Quality gates that actually block the pipeline
Quality gates set the conditions required to continue a deployment on the continuous integration server: a code coverage threshold, critical tests passing, or the absence of a blocking defect.
That rule loses all value if teams can bypass it. A pipeline you can ignore does not protect production. Effective CI/CD integration must make a critical test failure a blocking condition.
Building testing into Agile work
In Agile, the Definition of Done includes the tests needed to consider a feature complete. Testing is therefore not an isolated phase at the end of a sprint: it accompanies the development and validation of every change.
Under continuous delivery, release frequency also puts a limit on how long the suite can take. If a team deploys three times a day, a regression run that takes six hours is no longer compatible with its delivery rhythm.
Building a test strategy
An effective test strategy is not about testing everything. It organizes checks according to project risk and sets out responsibilities, validation criteria and the indicators to track.
- Prioritize scope by risk. Start with the features whose failure would have the greatest business impact: payment, authentication, sensitive data, or revenue-generating journeys.
- Define acceptance criteria before development. Client requirements must produce observable, verifiable results. A criterion that cannot be tested is not a usable acceptance criterion.
- Assign an owner to each level. Developers take on unit tests, QA teams take system and acceptance tests, while review involves the whole team. Every level needs an identified owner.
- Organize defect management. For each issue, record its severity, its target resolution time and the requirement it relates to. Track the reopen rate too: poorly documented defect resolution increases the risk of seeing the same problem return.
- Track four indicators. Measure test coverage, defects escaped to production, regression run duration, and the share of unstable tests. This data tells you whether your quality setup still matches project risk.
A strategy also needs to be reassessed when the product, the team or the delivery rhythm changes. You can audit your quality setup to identify the checks that have become insufficient or too expensive.
Tools and frameworks: by category
Testing tools serve different functions. Rather than comparing brands, identify the category you need at each stage of your setup.
- Execution frameworks: test frameworks drive a browser or call an API in order to run scenarios in the target application environment. The choice depends on the type of test and on the software architecture. To go further, compare web automation frameworks.
- Test management and ALM: centralize test cases, runs, results and their traceability to requirements. A selection of QA testing tools helps identify the functions useful to your organization.
- AI automation platforms: generate and maintain tests in order to reduce the work spent on scripts. Thunders lets you create self-healing tests from expected behavior, without depending on fixed selectors.
- CI and orchestration: trigger test suites in the pipeline and apply validation rules before a delivery.
To scale automation, the best selection criterion is not the number of available features, but the cost of maintaining the tool and its tests over two years.
What testing actually delivers
The benefits of quality assurance testing are measured in project outcomes, not in the number of test cases executed. These indicators connect testing directly to the quality of the products you ship.
- Fewer defects escaping to production. Track the number of defects found by users after a release, and their severity. How that evolves tells you the real effectiveness of your testing before go-live.
- More frequent releases. A reliable test suite provides objective criteria for authorizing or blocking a delivery. The decision rests on results rather than on one person's assessment of risk.
- Lower cost of fixes. A defect found during development consumes fewer resources than an incident already in production, where you have to diagnose the problem, fix the software and manage the consequences.
- A factual basis for decisions. Test results document the state of the software, known defects and residual risk. Go-live trade-offs then rest on facts rather than on the opinion of whoever argues most convincingly.
- Evidence for demanding customers. In sectors with strict requirements, test reports, results and fix histories provide documented evidence during a customer questionnaire or an audit.
.jpg)
