Types of Software Testing: Complete List with Examples

No single test can tell a team whether a product is ready to release.

A feature may return the correct result but respond too slowly under load. A payment may work in Chrome but fail on Safari. An application may meet its functional requirements while remaining inaccessible to keyboard users or vulnerable to an authorization bypass.

That is why software testing includes multiple test types, each answering a different question about quality.

The distinction matters as teams try to expand coverage without delaying delivery. In TestRail’s 2025 industry report, 35% of respondents named increasing test coverage as their top QA priority, while 20% prioritized reducing production defects and 13% focused primarily on automating more tests.

Types of software testing at a glance

There is no single official list containing every testing type. Terms overlap, and teams sometimes use different names for similar activities.

For example, one test can simultaneously be:

• Functional

• Automated

• Black-box

• Regression

• API-level

• Positive

The table below covers the most widely used software testing types and explains what each one checks.

How software testing types are classified

Software testing types can be grouped in several ways.

By testing objective

• Functional testing checks what the application does.

• Non-functional testing checks how well it works.

By testing level

• Unit

• Integration

• System

• Acceptance

By execution method

• Manual

• Automated

By knowledge of the system

• Black-box

• White-box

• Grey-box

By relationship to change

• Smoke

• Sanity

• Confirmation

• Regression

These classifications are not mutually exclusive. An automated API regression test, for example, can also be functional and black-box.

Understanding this overlap is more useful than trying to assign every test to one exclusive category.

Functional testing types

Functional testing verifies whether a product’s features behave according to requirements and business rules.

It answers questions such as:

• Can users sign in?

• Is an order total calculated correctly?

• Can an administrator change a user’s role?

• Does a refund update the payment and order status?

• Is the correct error displayed for invalid input?

Our complete guide to functional testing covers its process, techniques, and test-case design in more detail.

Unit testing

Unit testing checks the smallest practical pieces of code, such as functions, methods, and classes.

Developers usually write unit tests while implementing the code. Dependencies are often mocked or replaced so that failures can be isolated.

Example: An eCommerce platform has a function that calculates a discount. Unit tests can verify that it:

• Applies the correct percentage.

• Does not accept an expired promotion.

• Respects the maximum discount.

• Handles rounding correctly.

• Rejects an invalid customer category.

Unit tests are fast and suitable for checking many combinations. They should form the foundation of the test suite.

Integration testing

Integration testing checks whether two or more components communicate correctly.

It can validate:

• API contracts

• Database operations

• Message queues

• Data transformations

• Authentication between services

• Error handling across component boundaries

Example: After a customer pays for an order, the payment service should send the correct status to the order service. Integration testing verifies the request, response, and resulting order state.

Common integration approaches include:

• Big bang integration

• Top-down integration

• Bottom-up integration

• Hybrid or sandwich integration

• Contract testing

• Service integration testing

System testing

System testing evaluates the complete integrated application against its specified requirements.

It may include both functional and non-functional checks. The system is normally tested in an environment representing production, although selected external dependencies may be mocked or virtualized.

Example: A team tests a complete banking application, including authentication, transfers, transaction history, notifications, and account settings.

User acceptance testing

User acceptance testing determines whether the product supports real business processes and is ready for release.

Unlike system testing, UAT is usually performed or approved by business users, product owners, clients, or domain specialists.

Example: An accounting team checks whether a new invoice-approval process follows the organization’s financial rules and provides the information required for daily work.

The full user acceptance testing guide explains UAT planning, roles, entry criteria, and examples.

Smoke testing

Smoke testing is a short, broad check of the application’s most critical functions.

Its purpose is to determine whether the build is stable enough for more detailed testing.

A smoke suite might verify that:

• The application opens.

• Users can sign in.

• The main dashboard loads.

• A basic transaction can be completed.

• Critical APIs respond.

• The database connection works.

If smoke testing fails, running the complete regression suite usually provides little value.

Sanity testing

Sanity testing is a focused check performed after a small change or fix.

Example: A team changes the password-reset workflow. Sanity testing confirms that users can request a reset link, open it, create a new password, and sign in.

Smoke testing asks whether the build is generally testable. Sanity testing asks whether a particular changed area behaves reasonably.

Regression testing

Regression testing reruns previously passed tests to determine whether a change has broken existing behavior.

It should be considered after:

• Adding a feature

• Fixing a defect

• Updating a dependency

• Refactoring code

• Changing infrastructure

• Modifying an integration

• Releasing a new application version

A focused regression suite may cover affected modules, while a broader suite can run before a major release. Our guide to regression testing explains corrective, selective, partial, progressive, and complete regression.

Confirmation testing

Confirmation testing, also called retesting, verifies that a specific defect has been fixed.

The tester repeats the steps that originally exposed the problem, using the same data and conditions where possible.

Confirmation testing and regression testing are related but not interchangeable:

• Confirmation testing checks the fix itself.

• Regression testing checks whether the fix affected other functionality.

End-to-end testing

End-to-end testing validates a complete user journey across the application and its connected systems.

Example: An online purchase test may cover authentication, cart, discount, payment provider, order creation, inventory update, and confirmation email.

E2E tests provide broad business confidence but are slower and more difficult to diagnose than unit or integration tests. They should focus on critical workflows instead of attempting exhaustive coverage. See our complete guide to end-to-end (E2E) testing.

API testing

API testing validates application programming interfaces without relying on the graphical interface.

It commonly checks:

• Status codes

• Response bodies

• Request validation

• Authentication

• Authorization

• Error handling

• Schema and contract compliance

• Data persistence

• Idempotency

• Response time

API tests are usually faster and more stable than UI tests, making them suitable for functional coverage and regression automation.

Non-functional testing types

Non-functional testing evaluates the characteristics that determine how well the product works.

A functionally correct application can still fail if it is slow, insecure, confusing, inaccessible, or incompatible with users’ devices.

Performance testing

Performance testing measures application behavior under defined conditions.

Common metrics include:

• Response time

• Throughput

• Error rate

• Concurrent users

• CPU and memory consumption

• Database latency

• Queue processing time

• Network utilization

A proper performance test begins with measurable objectives. “The application should be fast” is not a useful requirement. “The checkout API should maintain a P95 response time below 800 milliseconds at 2,000 concurrent users” is testable.

Our guide to web application performance testing covers metrics, bottlenecks, environments, and test execution.

Load, stress, spike, soak, and volume testing

These terms describe different performance questions.

The detailed guide to stress testing in software explains how stress, load, spike, soak, and volume testing differ.

Security testing

Security testing identifies vulnerabilities and verifies controls protecting systems and information.

It can include:

• Vulnerability scanning

• Penetration testing

• Authentication testing

• Authorization testing

• API security testing

• Dependency scanning

• Static application security testing

• Dynamic application security testing

• Security configuration review

Security testing cannot be replaced by confirming that a feature works normally. Teams must intentionally test misuse, privilege escalation, data exposure, and malicious inputs.

The risk is measurable: Verizon’s 2025 DBIR analyzed more than 22,000 security incidents and 12,195 confirmed breaches, finding that credential abuse caused 22% of known initial access and vulnerability exploitation caused another 20%.

Usability testing

Usability testing evaluates whether representative users can complete tasks effectively and understand the interface.

It examines:

• Navigation

• Labels and instructions

• Onboarding

• Forms

• Error messages

• Information architecture

• Gestures and mobile interactions

• User effort

• Task completion

Usability testing is not the same as asking whether users like the design. It observes whether they can achieve specific goals and where they encounter friction.

For mobile-specific methods and metrics, see our guide to mobile app usability testing.

Accessibility testing

Accessibility testing checks whether people with visual, auditory, cognitive, speech, or motor disabilities can use the product.

Testing may include:

• Keyboard navigation

• Screen-reader behavior

• Focus order

• Text contrast

• Alternative text

• Form labels

• Zoom and reflow

• Captions and transcripts

• Error identification

• Semantic structure

Automated scanners are useful, but they detect only part of the problem. Manual keyboard and assistive-technology testing remains necessary.

The scale of the issue is substantial. WebAIM’s 2025 analysis of one million home pages found detectable WCAG failures on 94.8% of them, with an average of 51 automatically detected accessibility errors per page.

Compatibility testing

Compatibility testing verifies whether the application works across its supported environments.

The test matrix may include:

• Browsers and versions

• Operating systems

• Mobile devices

• Screen resolutions

• Hardware

• Network conditions

• Database versions

• Integrated software

• Backward and forward compatibility

Testing every possible combination is rarely feasible. Teams should prioritize configurations using production analytics, customer value, technical risk, and support commitments.

Our complete guide to compatibility testing includes a sample device–OS–browser matrix.

Reliability and recovery testing

Reliability testing evaluates whether the system performs consistently for a defined period.

Recovery testing checks whether it can restore normal operation after:

• Service failure

• Database interruption

• Network outage

• Hardware failure

• Process crash

• Dependency failure

• Data corruption

Tests should verify more than whether the application starts again. They should measure data integrity, recovery time, queued operations, duplicate processing, and user impact.

Localization testing

Localization testing verifies that a product has been adapted correctly for a specific language, region, and culture.

It covers:

• Translation

• Date and time formats

• Currency

• Decimal separators

• Phone and address formats

• Text expansion

• Right-to-left layouts

• Local payment methods

• Regional business rules

Localization testing is different from internationalization testing, which evaluates whether the underlying software can support multiple locales without redesign.

Manual vs automated testing

Manual and automated testing are execution approaches, not competing quality strategies.

Automation has not removed the need for manual testing. SmartBear’s 2026 survey found that although 87% of participating organizations had automated at least 21% of application testing, 92% still performed manual testing.

Use automation for stable tests that run frequently. Keep exploratory, usability, and rapidly changing scenarios manual until automation has a clear return.

Our manual vs automated testing comparison provides a decision framework and cost considerations.

Black-box, white-box, and grey-box testing

These methods are distinguished by how much the tester knows about the internal implementation.

Black-box testing

The tester interacts with the product through its public interfaces without relying on source-code knowledge.

Common black-box techniques include:

• Equivalence partitioning

• Boundary value analysis

• Decision tables

• State-transition testing

• Use-case testing

White-box testing

White-box testing examines internal logic and structure.

Coverage may be measured through:

• Statement coverage

• Branch coverage

• Condition coverage

• Path coverage

• Loop testing

• Data-flow coverage

It is commonly used in unit and component testing.

Grey-box testing

Grey-box testing combines external behavior testing with partial knowledge of the architecture, database, or integrations.

For example, a tester may submit a transaction through the public API and use database knowledge to verify that the correct records and relationships were created.

Additional software testing types

Exploratory testing

Exploratory testing combines learning, test design, and execution.

Instead of following only predefined cases, the tester investigates risks, observes behavior, and adapts the next test based on what has been discovered.

It is especially useful for:

• New functionality

• Unclear requirements

• Complex workflows

• Usability issues

• Unusual combinations

• Areas with repeated production defects

Positive and negative testing

Positive testing uses valid inputs and expected user behavior.

Negative testing uses invalid, unexpected, incomplete, or unauthorized input.

A money-transfer feature, for example, should be tested with:

• Valid amount and account

• Amount above the balance

• Zero or negative amount

• Invalid destination account

• Expired session

• Duplicate request

• Insufficient permissions

Static and dynamic testing

Static testing examines artifacts without executing the software.

Examples include:

• Requirement review

• Design review

• Code review

• Static code analysis

• Test-case review

Dynamic testing evaluates the running application.

Starting testing with static reviews can prevent unclear requirements and design problems from becoming code defects.

Alpha and beta testing

Alpha testing is performed internally before the product is released to external users.

Beta testing provides a near-final product to a selected external audience. It helps identify environment-specific problems, unmet expectations, and usage patterns that internal teams may not anticipate.

How to choose the right software testing types

A product does not need every testing type with equal depth. The correct mix depends on risk.

Start with six questions:

Match risks to testing types

Use several levels for the same feature

Consider a SaaS subscription upgrade.

A balanced approach can include:

• Unit tests: Pricing and tax calculations

• API tests: Subscription-update endpoint

• Integration tests: Billing service and payment provider

• Smoke test: Existing customer can open the billing area

• E2E test: Customer upgrades and receives the correct entitlement

• Regression tests: Existing subscription and cancellation flows

• Performance test: Billing service during renewal periods

• Security test: Customer cannot modify another organization’s subscription

• Compatibility test: Upgrade works on supported browsers

• UAT: Finance and product teams approve the workflow

Trying to cover all these risks through one UI test would make failures slow and difficult to diagnose.

Consider the test environment and data

A theoretically ideal test provides little value if the team cannot run it reliably.

Capgemini’s World Quality Report 2025–26 found that 60% of organizations struggle with secure, scalable test data, while synthetic-data adoption increased from 14% in 2024 to an average of 25% in 2025.

When selecting a testing type, confirm that the team has:

• A suitable environment

• Representative and compliant data

• Observable expected results

• Access to required dependencies

• Enough time in the delivery pipeline

• An owner for failures and maintenance

Document the selected scope

A test strategy should state:

• Risks being covered

• Selected testing types

• Responsible roles

• Test environments

• Required data

• Entry and exit criteria

• Automation scope

• Execution schedule

• Quality metrics

• Accepted residual risks

Use a structured software test plan to connect testing activities with release decisions. Individual scenarios can then follow consistent test case templates and examples.

Recommended testing mix by product stage

Early MVP

Prioritize:

• Unit testing

• Critical functional testing

• API testing

• Exploratory testing

• Basic security checks

• Smoke testing

• UAT

Avoid building a large UI automation suite while workflows are still changing weekly.

Growing product

Add:

• Automated regression

• Integration and contract testing

• Critical E2E automation

• Performance baselines

• Compatibility matrix

• Accessibility testing

• CI/CD quality gates

At this stage, the objective is to scale coverage without making every release depend on manual regression.

Mature or regulated product

Expand into:

• Risk-based regression

• Continuous security testing

• Performance and resilience testing

• Recovery and failover testing

• Compliance validation

• Production monitoring

• Traceability

• Broader device and localization coverage

Regulated products may also require documented evidence, approval workflows, controlled test data, and auditable results.

Build a testing portfolio, not a checklist

A complete QA strategy is not one that uses the largest number of testing terms. It is one that applies the right test at the level where it provides the fastest and clearest feedback.

Use unit tests for logic, integration tests for boundaries, E2E tests for critical journeys, regression tests for change protection, and non-functional testing for the qualities that determine whether users can trust and comfortably use the product.

The resulting testing portfolio should reflect the product’s actual risks, architecture, users, release process, and regulatory environment.

If you need help selecting and implementing the right mix, DeviQA’s quality engineering services cover functional, automated, performance, security, compatibility, and continuous testing across the software development lifecycle.

Build QA that holds up as you grow

Schedule a call

Frequently asked questions

What are the main types of software testing?

The two broadest groups are functional and non-functional testing.

Functional testing checks whether features work correctly. Non-functional testing evaluates qualities such as performance, security, usability, accessibility, reliability, and compatibility.

Testing is also classified by level, execution method, system knowledge, release stage, and relationship to code changes.

What are the four levels of software testing?

The four commonly recognized levels are:

They move from individual code components toward the complete product and its business requirements.

Is regression testing a functional test?

Regression testing is a change-related testing type. A regression suite can contain functional and non-functional tests.

For example, it may verify existing business features, API performance, security rules, and browser compatibility after a release.

Is API testing functional or non-functional?

API testing can be both.

Functional API testing verifies requests, responses, rules, and data changes. Non-functional API testing can evaluate performance, security, reliability, and scalability.

Can every software test be automated?

No. Automation works best for stable, repeatable, high-value checks.

Exploratory testing, early usability evaluation, and scenarios requiring human judgment often remain manual. Even automated suites require people to design scenarios, review results, investigate failures, and maintain the test code.

Which testing type should be performed first?

Testing should begin with static analysis and unit testing as early as possible. Integration and functional tests follow as components become available.

Smoke, system, E2E, non-functional, and acceptance testing are added as the product becomes sufficiently integrated. The exact order depends on architecture and risk.

About the author

Anastasiia Sokolinska

Chief Operating Officer

Anastasiia Sokolinska is the Chief Operating Officer at DeviQA, responsible for operational strategy, delivery performance, and scaling QA services for complex software products.