25 Types of Software Testing Explained: The Complete Guide (2026)

Part 1: Functional Testing Types — Does the App Do What It Should?

Functional testing validates that software features work according to their requirements. It answers the question: “Does this feature do what it is supposed to do?” These are the most commonly used testing types in QA.

1. Unit Testing

What it is: Testing individual components or functions of the code in isolation — the smallest testable pieces of an application.

When to use it: During development. Developers write unit tests alongside the code they build.

Real example: Testing a function that calculates a discount percentage — verifying it returns 10 for a 10% discount, 0 for no discount, and handles negative inputs correctly.

Tools: Jest (JavaScript), JUnit (Java), PyTest (Python), NUnit (.NET)

2. Integration Testing

What it is: Testing how multiple components or services work together — verifying that the interfaces between modules behave correctly.

When to use it: After unit testing, when combining individual components into larger parts of the system.

Real example: Testing that your checkout module correctly communicates with the payment gateway API — the request is sent correctly, the response is handled properly, and the order status updates accordingly.

Tools: Postman, REST Assured, Playwright, TestContainers

3. System Testing

What it is: End-to-end testing of the complete, integrated application to verify that the whole system works as specified.

When to use it: After integration testing, before user acceptance testing. Typically run by a dedicated QA team.

Real example: Testing the complete user journey on an e-commerce app — from browsing products, adding to cart, applying a discount code, checking out, receiving an email confirmation, and tracking the order.

4. Functional Testing

What it is: Verifying that each feature of the software works according to the documented requirements. Black-box in nature — the tester does not need to know the internal code.

When to use it: Throughout development and before every release. The backbone of most manual QA work.

Real example: Testing a login feature: valid credentials log in successfully, invalid password shows an error message, locked account shows the correct lockout message, forgot password link works.

5. Regression Testing

What it is: Re-testing previously working functionality after code changes to ensure nothing has broken. One of the most important and most frequently performed types of testing.

When to use it: After every bug fix, new feature addition, or code refactoring. In Agile teams, every sprint.

Real example: After adding a new “Guest Checkout” feature to an e-commerce site, running regression tests on the existing registered user checkout flow to confirm it still works correctly.

Tools: Playwright, Selenium (automated regression), Jira (defect tracking)

6. Smoke Testing

What it is: A quick, shallow test of the most critical features of a new build — the “is this stable enough to test?” check. Also called build verification testing.

When to use it: Immediately after a new build is deployed, before investing time in deeper testing. If smoke tests fail, the build is rejected and sent back for fixes.

Real example: On a banking app, smoke tests would verify: can users log in? Can they see their balance? Can they initiate a transfer? If any of these fail, the build is not ready for testing.

7. Sanity Testing

What it is: A narrow, focused test on a specific area after a bug fix or small change — confirming the fix works without testing the entire application.

When to use it: After a developer fixes a specific bug. Faster than full regression testing.

Real example: A developer fixes a bug where applying a 100% discount code crashes the checkout. Sanity testing verifies just the discount code flow — that it now works and doesn’t crash.

8. User Acceptance Testing (UAT)

What it is: The final phase of testing where real end users or business stakeholders validate that the software meets their needs and business requirements before going live.

When to use it: After system testing is complete. This is the final gate before production release.

Real example: A hospital asks their nurses to test a new patient scheduling system — using real-world scenarios from their daily work — before the IT team signs off on the go-live.

9. Exploratory Testing

What it is: Simultaneous test design and execution without pre-written test cases. The tester explores the application using experience, intuition, and curiosity to find unexpected bugs.

When to use it: For new features, after major changes, and to supplement scripted testing. Highly effective for finding bugs that scripted tests miss.

Real example: A tester spends 45 minutes freely exploring a new social media feature — trying unusual inputs, clicking in unexpected orders, testing edge cases the spec never mentioned — and discovers a crash when a user tags 50+ people in a post.

Part 2: Non-Functional Testing Types — How the App Performs

Non-functional testing validates how well the software works, not just whether it works. These tests cover performance, security, usability, and reliability — qualities that users care deeply about even when they can’t articulate them.

10. Performance Testing

What it is: Testing how the system behaves under expected workloads — measuring response times, throughput, and resource usage.

When to use it: Before major releases, before high-traffic events (Black Friday, product launches), and whenever significant back-end changes are made.

Real example: Testing a travel booking site to verify that the search results page loads in under 2 seconds when 500 users are searching simultaneously.

Tools: Apache JMeter, Gatling, k6, Locust

11. Load Testing

What it is: A subset of performance testing — simulating the expected number of concurrent users to verify the system handles anticipated traffic volumes without degrading.

When to use it: Before any release where traffic volume is a concern. Essential for e-commerce, SaaS, and consumer apps.

Real example: Simulating 1,000 users adding items to their cart simultaneously on an e-commerce site during a sale event — verifying that checkout still completes in under 3 seconds for all users.

12. Stress Testing

What it is: Pushing the system beyond its expected capacity to find its breaking point — and observe how it fails when it does.

When to use it: When you need to understand maximum capacity and failure behaviour. Critical for systems where failure has serious consequences.

Real example: Ramping traffic from 1,000 to 10,000 concurrent users on a payments API to find at what point transactions start failing, and ensuring the system fails gracefully (returns an error message rather than silently dropping transactions).

13. Security Testing

What it is: Testing the application for vulnerabilities that could be exploited by attackers — covering authentication, authorisation, data exposure, injection attacks, and more.

When to use it: Before every major release. Mandatory for apps handling financial data, personal information, or healthcare records.

Real example: Testing a web app’s login form by attempting SQL injection (' OR '1'='1) to see if it bypasses authentication. Testing API endpoints with expired tokens to verify they correctly return 401 Unauthorized.

Tools: OWASP ZAP, Burp Suite, manual security testing techniques

14. Usability Testing

What it is: Evaluating the software from the perspective of real users — how easy it is to use, how intuitive the navigation is, and whether users can complete tasks without confusion or frustration.

When to use it: During design and development, and before launching new features. Most valuable with real target users as participants.

Real example: Asking 5 real users to complete a sign-up flow without any guidance, while a tester observes where they hesitate, click the wrong button, or give up — then using those findings to improve the UX.

15. Compatibility Testing

What it is: Testing that the software works correctly across different browsers, operating systems, screen sizes, and device types.

When to use it: Before every release. Critical for any web or mobile app — a feature that works on Chrome may be broken on Safari, or on an older Android device.

Real example: Testing a web dashboard on Chrome 120, Firefox 122, Safari 17, and Edge 120; on Windows 11 and macOS Sonoma; and on iPhone 15 and Samsung Galaxy S24. Finding that a dropdown menu doesn’t open on Safari iOS — a bug that affects 25% of users.

Tools: BrowserStack, Sauce Labs, LambdaTest, real device testing

16. Accessibility Testing

What it is: Verifying that the application is usable by people with disabilities — including visual, hearing, motor, and cognitive impairments. Tests against WCAG (Web Content Accessibility Guidelines) standards.

When to use it: Throughout development. Legally required for government and public sector applications in many countries. Increasingly important for all apps.

Real example: Testing that all images have alt text for screen readers, all form fields have labels, the page can be navigated fully with keyboard alone, and colour contrast meets WCAG AA standards (minimum 4.5:1 ratio).

Tools: Axe, WAVE, Lighthouse, manual screen reader testing (NVDA, VoiceOver)

Part 3: Structural Testing Types — How the Code Works Inside

17. White Box Testing

What it is: Testing with full knowledge of the internal code structure — the tester (usually a developer) designs tests based on how the code is written, not just what the requirements say.

When to use it: During development for complex logic, security-critical code, and to achieve code coverage targets.

Real example: Writing tests that cover every branch of a password validation function — testing the path where password is too short, the path where it lacks a number, and the path where it passes all rules.

18. Black Box Testing

What it is: Testing without any knowledge of the internal code — only the inputs, expected outputs, and user requirements. The tester treats the application as a “black box.”

When to use it: Most manual QA testing is black box. Ideal for functional, system, and acceptance testing.

Real example: Testing an online calculator. The tester types numbers and operations and verifies the result — without knowing whether it’s built in JavaScript, Python, or any other language.

19. Grey Box Testing

What it is: A combination — the tester has partial knowledge of the internal structure (enough to design better tests) but does not have full code access.

When to use it: API testing, database testing, and integration testing where knowing the data structures helps design more thorough tests.

Real example: An API tester knows the database schema and the expected JSON structure, so they can test edge cases like maximum field lengths, null values, and referential integrity — without having access to the backend code itself.

Part 4: Change-Related Testing Types

20. Re-Testing

What it is: Running the specific test case that previously failed, after a developer has fixed the reported bug, to confirm the fix works.

When to use it: After every bug fix. Always before marking a defect as “Closed” in your bug tracking tool.

Real example: A tester reported that “Login fails when email contains a capital letter.” The developer fixes it. The tester retests with a capital letter in the email — if it now passes, the defect is closed.

21. Confirmation Testing

What it is: Verifying that a defect reported and fixed has been properly resolved — often includes both re-testing the original failure and testing adjacent functionality to ensure no new issues were introduced by the fix.

When to use it: After bug fixes that touch shared code or affect multiple modules.

Part 5: Specialised Testing Types

22. API Testing

What it is: Testing application programming interfaces directly — sending HTTP requests to API endpoints and verifying the responses are correct, without using the UI.

When to use it: Whenever your application has a backend API. Faster and more stable than UI testing, and catches backend bugs before the UI even exists.

Real example: Testing a user registration API by sending a POST request with valid data (expecting 201 Created), duplicate email (expecting 409 Conflict), missing required fields (expecting 400 Bad Request), and SQL injection in the name field (expecting safe handling, not a server crash).

Tools: Postman, REST Assured, Playwright (API mode), Insomnia

23. Mobile App Testing

What it is: Testing mobile applications on iOS and Android devices — covering functionality, performance, device compatibility, battery usage, offline behaviour, and push notifications.

When to use it: For any app published on the App Store or Google Play. Must cover a range of real devices, not just the device the developer owns.

Real example: Testing a food delivery app across an iPhone 14 (iOS 17), Samsung Galaxy A54 (Android 13), and a 3-year-old Xiaomi phone (Android 11) — finding that the order tracking map doesn’t load on the older device due to a WebView compatibility issue.

24. Database Testing

What it is: Testing the database layer — verifying data integrity, correctness of stored procedures, query performance, and that data is saved, retrieved, and deleted correctly.

When to use it: For data-heavy applications, after database migrations, and after changes to data models.

Real example: After a database migration, verifying that all existing user records were transferred correctly, that foreign key relationships are intact, and that a profile deletion cascades correctly to remove associated orders and addresses.

25. End-to-End (E2E) Testing

What it is: Testing complete user workflows from start to finish — simulating exactly what a real user does across multiple pages, services, and systems. Usually automated.

When to use it: For your most critical business flows — login, onboarding, checkout, subscription. Run on every deployment in a CI/CD pipeline.

Real example: An automated Playwright test that: opens the homepage, searches for a product, adds it to cart, enters payment details using a test card, completes the order, and verifies the confirmation email is received — all in one automated script that runs in 90 seconds on every code push.

Tools: Playwright (recommended), Cypress, Selenium

Which Types of Testing Does Your Project Need?

You don’t need all 25 types. You need the right types for your specific project, risk profile, and stage of development. Here is a practical guide:

The most common mistake teams make is doing only functional testing and skipping regression testing after changes. The second most common mistake is doing only manual testing when automation would run the same tests 50x faster. A balanced QA strategy combines manual testing for exploratory and new-feature coverage with automation for regression and high-frequency flows.

Key Takeaways

• ✅ There are 25+ types of software testing — each designed to catch a different category of problem
• ✅ Functional testing checks if features work as specified — the foundation of all QA
• ✅ Regression testing ensures new changes don’t break existing functionality — run after every change
• ✅ Performance testing (load, stress) validates how the system behaves under real traffic
• ✅ Security testing is non-negotiable for any app handling user data or payments
• ✅ Compatibility testing catches browser and device bugs that affect a significant portion of your users
• ✅ Exploratory testing finds the bugs that scripted tests never thought to look for
• ✅ You don’t need all 25 types — you need the right types for your project risk and stage