QA testing types can be organized by test levels (unit, integration, system, acceptance), test purpose (functional versus non-functional), and execution approach (manual versus automated). Named types such as regression, smoke, sanity, performance, security, and end-to-end testing sit inside those groups. ISTQB organizes the levels and types, and ISO/IEC 25010 defines the quality characteristics non-functional tests check.
TL;DR:
- Run unit and component checks on every commit, integration tests on each merge, and reserve slower system and acceptance suites for nightly or before release.
- Automate fast, stable checks that recur; four or five positive answers to readiness questions support automation, while two or fewer favor manual testing.
- Set performance baselines once core flows exist, check security at every release candidate, and prioritize nonfunctional risks users would notice first.
- Test fresh installs, upgrades, and uninstalls; mirror production in staging and rehearse restores against recovery time and data loss targets.
Table of Contents
- A quick map of the testing landscape
- Test levels: from unit tests to acceptance
- Functional vs non-functional testing
- Testing techniques and approaches
- Manual testing vs automation
- Quick reference: named test types
- Our practitioner perspective on priorities and trade-offs
- Installation and deployment testing
- Recovery testing
- Why the best taxonomy is the one you actually use
- Where a QA partner speeds up your testing strategy
- FAQ
- Sources
A quick map of the testing landscape
Different ideas organize QA, and beginners often mix them up. Test levels describe where in the build you test, from a single function up to the whole product. Test types describe what quality you are checking: does a feature behave correctly, is it fast enough, is it safe? Every real test has both a level and a type. A login check run by a developer on one function is a unit-level functional test. A load run against the full system is a system-level performance test.
ISTQB classifies software testing along both dimensions: test levels and test types, with functional, non-functional, black-box, and white-box as the main type groups. ISO/IEC 25010 supplies the vocabulary for the non-functional side, so "test the quality" becomes a concrete list of characteristics.
Here is the map the rest of this article follows:
- Levels: unit/component, integration, system, acceptance
- Purpose: functional testing, non-functional testing (performance, security, usability, compatibility, reliability, maintainability)
- Techniques: black-box, white-box, gray-box, behavior-driven, exploratory, contract
- Execution: manual and automated
- Named types you will meet daily: regression, smoke, sanity, API, visual, end-to-end
Think of levels as rows and types as columns. A good test plan fills in the cells that matter for your risk, not every cell.
Test levels: from unit tests to acceptance
Software testing levels map to different responsibilities: unit tests verify individual modules, integration tests verify interactions, system tests validate the assembled product against requirements, and acceptance tests confirm stakeholder criteria. ISTQB documentation names five levels, splitting integration into component integration and system integration.
- Unit/component testing: Developers write these, usually with mocks standing in for dependencies. They run quickly on every commit. A framework such as Mocha handles JavaScript, and each language has equivalents.
- Integration testing: This level finds interface and interaction defects that unit tests cannot see. Research on interaction-based integration testing shows that unit-test artifacts can be reused to derive integration tests and verify component interactions without running the full system. Contract tests are another common strategy for services.
- System and end-to-end testing: Testers treat the assembled product as a black box in a production-like environment. They check complete user flows, configuration, and environment concerns.
- Acceptance testing (UAT): Stakeholders validate the product against agreed acceptance criteria. It often works as the final release gate.
Defects are cheapest to fix where they are introduced. A wrong calculation caught by a unit test is typically easier to fix. The same bug found in UAT means rework across code, tests, and schedule. That economics is the practical case for shifting tests left, toward earlier levels, wherever the tests can be fast and deterministic.
Pro Tip: Run unit and component tests on every commit, integration tests on every merge, and keep the slower system and acceptance suites for nightly or pre-release pipelines.
Functional vs non-functional testing
Functional testing asks whether the software does what the requirements or user stories say. Submit the form, get the confirmation. Apply a coupon, see the discount. TMAP describes functional testing as focused on the single quality characteristic of functional suitability, while non-functional testing spans many others.
Non-functional testing asks how well the product does it. ISO/IEC 25010:2023 defines a product quality model that gives testers concrete targets for this work. The areas learners meet most often:
- Performance efficiency: Load and stress tests with tools such as JMeter or k6 show how response time behaves as traffic grows.
- Security: Penetration testing and vulnerability scanning look for exploitable weaknesses. Our partners at ISMS Calculator explain penetration testing's role in compliance for teams working toward ISO 27001.
- Usability: Moderated sessions with real users show where flows confuse people.
- Compatibility: Checks across browsers, devices, and operating systems.
- Reliability: Soak tests and failure injection show whether the system stays up under stress.
- Maintainability: Static analysis and code review gauge how safely the code can change.
Non-functional areas are often under-tested, even though they cause many production failures, according to TMAP. A feature that works perfectly but takes too long to load can still fail the user.
Schedule non-functional tests earlier than feels natural. Performance baselines belong in the pipeline once core flows exist, and security checks belong at each release candidate at the latest.
Testing techniques and approaches
Techniques describe how you derive tests, and they cut across the levels above.
- Black-box testing: You test inputs and outputs with no view of the code. It is the default for system, acceptance, and most functional checks.
- White-box testing: You design tests from the code's structure, covering branches and paths. It underpins unit testing and static analysis.
- Gray-box testing: You use partial internal knowledge, such as the database schema or API logs, to aim external tests at likely weak spots.
- Behavior-driven development (BDD): Executable specifications written in plain language align developers, testers, and stakeholders. Research on BDD for microservice applications frames tests as a pyramid, with unit tests at the bottom and end-to-end tests at the top, and lists unit, integration, component, contract, and end-to-end tests as essential for microservice workflows.
- Exploratory testing: A skilled tester investigates without a script, learning the product while probing it. It finds odd, human-shaped bugs that scripted automation walks past.
- Contract testing: Consumer and provider agree on an interface, and tests verify both sides honor it. It keeps API and microservice integrations from breaking silently. Our API integration strategy guide covers the design side.
Match the technique to the goal. Use white-box for logic-heavy code, black-box for requirements, and exploratory sessions wherever the product is new or changing fast.
Manual testing vs automation
Start with a simple rule: automate fast, deterministic checks such as unit and API tests first, and keep exploratory and experience-focused testing manual. The test pyramid explains why. Many cheap unit tests form the base, fewer integration and API tests sit in the middle, and a thin layer of UI tests caps the top, because UI tests are slow and break easily.
Common anti-patterns cause automation pain:
- Flaky tests: Tests that pass and fail at random erode trust. Quarantine them fast, then fix timing and data causes.
- UI over-dependence: Pushing every check through the browser makes suites slow. Move logic checks down to the API level.
- Weak test data: Shared, mutable data makes results unpredictable. Create and clean data per test.
Before automating a test, ask:
- Will this test run many times, such as every build or every release?
- Is the expected result clear and stable?
- Can it run without human judgment?
- Is the feature stable enough that the script will not be rewritten next sprint?
- Does the time saved outweigh the cost of writing and maintaining it?
Four or five yeses mean automate. Two or fewer mean keep it manual for now.
Pro Tip: Automate your most repetitive regression path first. A small suite that runs on every build beats a large one nobody trusts.
Quick reference: named test types
Use these definitions as a runbook when drafting a test plan.
- Regression: Re-runs existing tests to confirm that new changes broke nothing. Run it before each release candidate. Our regression testing plan is a copyable starting point.
- Smoke: A shallow check that the build starts and core functions respond. Run it on every build.
- Sanity: A narrow check that one fix or feature works as intended. Run it after a targeted change.
- Performance: Measures speed, throughput, and stability under load. Run it before launches and traffic spikes.
- Security: Probes for vulnerabilities. Use our web app security checklist for testable controls.
- API: Verifies requests, responses, and error handling below the UI.
- Visual: Compares screens against approved baselines to catch layout drift.
- End-to-end: Walks a full user journey across systems. For mobile, see our smoke-run checklist and device matrix.
Commonly cited lists of testing types include all of these.
Our practitioner perspective on priorities and trade-offs
We start every engagement with risk, not coverage targets. Ask which flows would hurt the business most if they failed, and test those first at the cheapest effective level. From there, pilot a small automation suite in CI, protect the core flows with regression checks, and add non-functional tests where the risk is high. The ISTQB Test Analyst certification recommends risk-based testing for the same reason. Our QA and testing services put this approach into practice.
Installation and deployment testing
A build that passes every functional test can still fail the moment a customer tries to install or release it. Installation and deployment testing verifies that the software gets onto its target environment cleanly and runs correctly once it is there.
For installable software and mobile apps, that means testing fresh installs, upgrades from earlier versions, and uninstalls. Does the installer handle missing dependencies? Does an upgrade keep user data and settings? Does uninstalling leave junk behind? For web and cloud products, the focus moves to the deployment pipeline: configuration files, environment variables, database migrations, secrets, and infrastructure scripts.
A practical approach is to deploy to a staging environment that mirrors production as closely as possible, then run a smoke suite against it. Teams that deploy often add automated checks for rollbacks, so a failed release can be reversed quickly. Blue-green and canary releases support this by exposing a new version to a small share of traffic first.
Typical defects found here include wrong permissions, hard-coded paths, missing migration steps, and configuration that works on a developer laptop only. These bugs are invisible to unit tests because they live in the environment, not in the code. That is why installation and deployment testing belongs near the end of the pipeline, right before acceptance, and why it should be repeatable. Treat deployment scripts as code, version them, and test them like code.
Recovery testing
Recovery testing checks how well a system returns to a healthy state after a failure. It sits under the reliability characteristic in ISO/IEC 25010 and answers a blunt question: when something breaks, how fast and how completely does the product come back?
Testers force failures on purpose. They kill a server process, cut the network mid-transaction, fill the disk, crash the database, or power off a node. Then they observe. Does the application restart on its own? Are in-flight transactions rolled back or lost? Does data written before the crash survive? How long does recovery take, and does the user see a clear message instead of a blank screen?
Backup and restore belong here too. A backup that has never been restored is only a hope. Run restore drills against realistic data volumes and measure the result against your recovery time and recovery point targets. For distributed systems and microservices, test failover between instances and regions, and confirm that retries and circuit breakers behave as designed.
Run recovery tests before launch and after major infrastructure changes, ideally in a staging environment that mirrors production. Teams with mature pipelines schedule regular failure drills so recovery stays a practiced skill rather than a surprise. The payoff shows during real incidents: a team that has already seen the failure in a test restores service calmly and quickly.
Why the best taxonomy is the one you actually use
Learners often memorize the full list of test types and walk away thinking quality means covering all of them. I think that gets the priority backwards. The taxonomy from ISTQB and ISO/IEC 25010 is a menu for decisions, not a checklist to complete.
The conventional advice, "automate everything," falls short in the same way. Automation is a tool for repetition, and a young product with changing screens will punish you for scripting too early. Meanwhile, the advice rarely mentions that many teams over-invest in functional checks and leave performance, recovery, and security for after launch, which is exactly where production failures cluster.
If you are starting out, do this in order. First, write unit and API tests for the logic that makes money. Second, add a smoke test to every build so a broken build is caught in minutes. Third, pick the one or two non-functional characteristics your users would notice first, such as speed or data safety, and test them before release. Everything else can wait until risk justifies it. A small plan that runs on every commit beats an exhaustive plan that lives in a document.
— Dmitry
Where a QA partner speeds up your testing strategy
Knowing the types is one thing. Running them every sprint is another. We help teams turn the strategy above into a working pipeline, which pays off most for complex integrations, compliance-heavy products, and teams scaling faster than their test coverage.
- QA support for assessing your current coverage
- QA support for your core regression path
- QA support for releases and non-functional testing
Tell us what you ship and where it hurts, and we will propose a first step. Start with our software testing and quality assurance services, or contact us to discuss your testing needs.
FAQ
How many types of tests are there?
There is no single fixed count. ISTQB groups test types into four main categories: functional, non-functional, black-box, and white-box. Named varieties such as regression, smoke, sanity, and API testing are applied within them.
What are the levels of testing?
ISTQB describes five levels: component (unit), component integration, system, system integration, and acceptance. Many teams simplify this to four by merging the two integration levels. Each level checks a wider scope than the one before it.
What is the difference between functional and non-functional testing?
Functional testing checks that features behave as the requirements describe. Non-functional testing checks quality attributes such as performance, security, usability, and reliability. A product needs both to feel finished to users.
When should you choose manual testing over automation?
Choose manual testing for exploratory work, usability checks, and features that are still changing. Automate fast, repeatable checks such as unit, API, and core regression tests. A test that runs rarely or has unclear expected results usually stays manual.