Types of Software Testing: 25 Types Explained With Examples

If you are preparing for your first QA interview, switching from manual testing, or studying software engineering in college, “what are the types of software testing?” is the question you will hear first. Most tutorials answer it with a long, flat list of 50+ names. That is hard to remember and even harder to explain in an interview.

This guide does it differently. First you get a simple map of how testing types are classified. Then you get 25 types of testing in software testing, each with a one-line definition and a concrete example from the same app — a food-delivery app — so you can see how the types fit together on a real project. Finally, we cover the confusions interviewers love (smoke vs sanity, retesting vs regression), which types you can automate with Playwright, and which ones matter most for QA jobs in India.

New to testing altogether? Start with our software testing tutorial for beginners, then come back here.

How Software Testing Types Are Classified

Every testing type you will ever hear about can be placed on four axes. Learn these four and the long lists suddenly make sense.

1. By what you test: functional vs non-functional

• Functional testing checks what the system does against the requirements. “When I apply a valid coupon, the order total reduces.”
• Non-functional testing checks how well the system does it — speed, security, usability, reliability. “The checkout page stays fast when thousands of users are ordering at dinner time.”

2. By how you test: manual vs automated

• Manual testing: a human executes the steps and judges the result. Best for exploratory, usability and one-off checks.
• Automation testing: a script (Playwright, Selenium, Postman/Newman, JUnit) executes the steps and asserts the result. Best for repetitive checks like regression and smoke suites. Our automation testing guide explains the basics.

3. By level: unit, integration, system, acceptance

The four levels of testing follow the order in which software is built and assembled:

1. Unit testing — one function or class in isolation (usually written by developers).
2. Integration testing — two or more modules talking to each other.
3. System testing — the complete, integrated application against the requirements (the main job of the QA team).
4. Acceptance testing (UAT) — the business or end users confirm the product is fit for release.

4. By approach: black box, white box, grey box

• Black box testing: you test inputs and outputs without seeing the code. Most manual QA work is black box. Techniques: equivalence partitioning, boundary value analysis, decision tables.
• White box testing: you design tests using knowledge of the code — statements, branches, paths. Mostly done by developers through unit tests.
• Grey box testing: partial knowledge of internals. Example: a tester who knows the database schema checks that placing an order writes the correct row in the orders table.

Functional Testing Types (With Examples)

All the examples below use the same imaginary food-delivery app: users sign up, search restaurants, add items to a cart, apply coupons, pay, and track the order.

1. Unit testing

Tests the smallest piece of code — a single function or method — in isolation. Example: a developer tests that calculateDeliveryFee(distanceKm) returns the right fee for 0 km, 3 km and 15 km.

2. Integration testing

Verifies that separate modules or services work together correctly. Example: after the payment service confirms a payment, the order service changes the order status from “Pending” to “Confirmed”.

3. System testing

Tests the complete, integrated application against the requirement specification. Example: QA runs every documented flow — signup, search, cart, payment, tracking, cancellation — on the staging build.

4. User acceptance testing (UAT)

Business users or clients confirm the software meets their needs before go-live. Its sub-types are alpha testing (inside the organisation) and beta testing (real users before full release). Example: the restaurant-partner team checks the new menu-upload feature works the way their partners actually upload menus.

5. Smoke testing

A quick, broad check that the most critical features of a new build work, so deeper testing is worth starting. Also called build verification testing. Example: on every new build: app opens, login works, search returns results, cart accepts an item, payment page loads.

6. Sanity testing

A quick, narrow check of one area after a small change or bug fix. Example: the coupon logic was patched, so you check coupon apply, remove and expiry — nothing else.

7. Regression testing

Re-running existing tests to make sure new changes did not break features that already worked. Example: after adding UPI as a payment option, you re-run card payment, wallet payment, refunds and order history tests. Deep dive: regression testing in software testing.

8. Retesting (confirmation testing)

Re-executing the exact test case that failed, after the developer fixes the bug, to confirm the fix. Example: bug #412 said “coupon FIRST50 applies twice”; after the fix you run that same test with the same data.

9. End-to-end (E2E) testing

Tests a complete user journey across the UI, APIs, database and third-party services, just like a real user. Example: a new user signs up, orders a biryani, pays, and sees “Order delivered” in history. See our Playwright end-to-end testing guide.

10. API testing

Tests the backend endpoints directly — status codes, response body, headers, error handling — without the UI. Example: POST /api/orders with an empty cart must return 400 with a clear error message. Learn how in the Playwright API testing guide.

11. UI / GUI testing

Checks the visible interface: buttons, forms, validation messages, navigation, layout behaviour. Example: entering a 9-digit mobile number on signup shows “Enter a valid 10-digit number” and keeps the Continue button disabled.

12. Exploratory testing

Simultaneous learning, test design and execution — the tester explores the app guided by experience instead of a script, usually inside a time-box. Example: a 60-minute session on “what happens if the network drops during payment?”

13. Ad-hoc testing

Informal, unplanned testing with no documentation, aimed at breaking the app. Similar to exploratory testing but less structured. Example: rapidly double-tapping “Place Order” to see if two orders get created.

14. Database testing

Validates data integrity, constraints, stored procedures and that the UI/API writes the correct data. Example: after cancelling an order, run a SQL query to confirm status = 'CANCELLED' and the refund row exists.

Non-Functional Testing Types (With Examples)

15. Performance testing

The umbrella term for measuring speed, responsiveness and stability under a workload. Example: measuring that restaurant search responds within the agreed time limit under typical traffic.

16. Load testing

Checks behaviour under the expected peak number of users. Example: simulating the expected Saturday-night dinner traffic and confirming response times stay within the target.

17. Stress testing

Pushes the system beyond its limits to find the breaking point and see how it fails. Example: keep increasing virtual users during a sale event until errors appear — does it show a friendly error or crash?

18. Security testing

Finds vulnerabilities such as broken authentication, SQL injection, XSS and data exposure. Example: logged in as user A, change the order ID in the URL — you must not see user B’s order and address.

19. Usability testing

Evaluates how easy and intuitive the product is for real users. Example: watch five first-time users try to add a delivery address and note where they hesitate.

20. Accessibility testing

Ensures people with disabilities can use the app (screen readers, keyboard-only use, colour contrast), usually against WCAG guidelines. Example: can you complete checkout using only the keyboard, and does the screen reader announce the “Place Order” button? See Playwright accessibility testing.

21. Compatibility / cross-browser testing

Verifies the app works across browsers, operating systems, devices and screen sizes. Example: the order-tracking map works in Chrome, Firefox and Safari, and on a small Android screen.

22. Visual testing

Compares screenshots against an approved baseline to catch unintended visual changes. Example: a CSS change accidentally pushes the “Pay” button below the fold — the screenshot diff flags it. Read Playwright visual regression testing.

23. Localization testing

Checks the app is correctly adapted for a language and region: translations, date/time formats, currency, text fitting the layout. Example: switching the app to Hindi or Tamil — are labels translated, and does the longer text break the buttons?

24. Installation testing

Verifies install, upgrade and uninstall of the software work cleanly. Example: upgrading the Android app from the previous version keeps the user logged in and keeps saved addresses.

25. Recovery testing

Checks how well the system recovers from crashes, network loss or hardware failure. Example: kill the app mid-payment, reopen it, and confirm the order status is correct and the user is not charged twice.

Bonus: A/B testing

Strictly speaking, A/B testing is a product experiment, not a defect-finding test: two variants are shown to different users to see which performs better. QA’s job is to verify both variants work. Example: variant A shows a green “Order Now” button, variant B an orange one — both must place orders correctly.

Comparison Table: Which Testing Types Can You Automate With Playwright?

Playwright is a browser automation and test framework. It is excellent for some types and simply the wrong tool for others. Here is an honest breakdown:

Here is what tagging smoke and regression tests looks like in a Playwright project written in JavaScript:

import { test, expect } from '@playwright/test';

test('home page loads @smoke', async ({ page }) => {
  await page.goto('/');
  await expect(page.getByRole('searchbox')).toBeVisible();
});

test('empty cart order is rejected @api @regression', async ({ request }) => {
  const res = await request.post('/api/orders', { data: { items: [] } });
  expect(res.status()).toBe(400);
});

// Run only smoke tests:  npx playwright test --grep @smoke

Common Confusions Interviewers Love

Smoke testing vs sanity testing

Honest note: many teams use these two words loosely. In an interview, give the textbook difference above, then add how your team actually used them — that shows real experience.

Retesting vs regression testing

Verification vs validation

• Verification — “Are we building the product right?” Checks work products against specifications, mostly through reviews, walkthroughs and inspections (static testing).
• Validation — “Are we building the right product?” Checks the actual software meets the user’s needs by executing it (dynamic testing, UAT).

Functional vs non-functional testing

Functional = what the system does (login works). Non-functional = how well it does it (login is fast, secure and accessible). A login feature needs both.

Exploratory vs ad-hoc testing

Both are unscripted. Exploratory testing has a charter, a time-box and notes; ad-hoc testing is completely informal and usually undocumented.

Which Testing Types Matter Most for QA Jobs in India?

We are not going to invent salary or hiring numbers. But if you read QA job descriptions on Naukri, LinkedIn or company career pages, and sit through fresher and mid-level interviews at service companies and product startups, a clear pattern shows up:

• Must know cold (freshers and manual testers): functional, smoke, sanity, regression, retesting, system testing, UAT, black box techniques (boundary value analysis, equivalence partitioning), the STLC and the defect life cycle.
• Expected with 1–3 years’ experience: API testing (Postman or code-based), basic SQL for database testing, cross-browser testing, and at least one automation tool.
• Differentiators for automation roles: UI and E2E automation (Playwright or Selenium), regression suites running in CI/CD, visual and accessibility checks, and increasingly AI-assisted test generation.
• Specialist tracks: performance (JMeter, k6) and security testing are separate career paths with their own tools — useful to understand, not required for most QA openings.

The shift worth noticing: manual testing knowledge is the foundation, but the roles that grow are the ones where you can automate the repetitive types — smoke, regression, API and E2E. Our manual tester to automation engineer roadmap lays out that path step by step, and the software testing tools guide shows which tool fits which testing type.

Automating the Right Types With Playwright + Claude AI

You do not automate “testing” in general — you automate specific types. The highest-return types to automate first are smoke, regression, API and end-to-end, because they run on every build and are the most boring to repeat by hand.

This is where AI helps today. Claude AI can turn a user story into a list of functional, negative and boundary test cases in seconds. With the Playwright MCP Server, Claude can open a real browser, read the page and draft Playwright tests that you then review, run and commit. The human part — deciding which types of testing a feature needs and judging the results — stays with you. That judgement is exactly what this guide trains.

Preparing for interviews? Pair this guide with our Playwright interview questions.

Frequently Asked Questions

Meet Your Instructor

Asim Noaman

Senior QA Automation Engineer & AI Testing Specialist

With years of hands-on experience building test automation frameworks for production applications, Asim specializes in combining traditional QA methodologies with cutting-edge AI tools. He has helped teams adopt Playwright and AI-driven testing workflows to ship faster with fewer bugs.

Udemy Instructor Published course author

Playwright + AI Expert Specialized in AI-powered QA

Production Experience Enterprise-grade frameworks

Connect on LinkedIn