15 Types of Software Testing and When to Run Each

What Is Software Testing?

Software testing is the practice of checking that an application behaves as intended before users depend on it. It covers finding defects, confirming requirements are met, and measuring qualities such as speed and security that requirements often leave implicit.

Two distinctions do most of the work in this article. Levels describe where you test, from a single function up to the assembled product. Types describe what you are checking for. A related pair worth separating early is verification vs validation: verification asks whether you built the thing correctly, validation asks whether you built the correct thing.

The Four Levels of Software Testing

Levels and types are different axes, and conflating them is the most common source of confusion in test planning. A level is how much of the system is assembled when you test. A type is what you are checking for. You always pick both: a performance test at system level is a different job from a performance test at unit level.

The ordering matters more than the labels. Each level assumes the one below it passed, so a failure at acceptance level that a unit test could have caught means the cheap layer was skipped, not that the expensive layer worked.

The Four Categories of Software Testing

Every named test type falls into one of four categories. Naming the category first is what stops the list of types from feeling arbitrary, because the category tells you what a failure actually means.

Functional testing and non-functional testing carry most projects. Structural testing is where black box vs white box testing becomes the deciding distinction, since only white box work can measure code coverage.

The 15 Core Types of Software Testing

These 15 types cover the overwhelming majority of real projects. The table gives the whole picture at a glance; the sections below define each one and say when it earns its place in your pipeline.

test('applies the standard rate and rejects negative orders', () => {
  expect(calculateTax(100, 0.08)).toBe(8);
  expect(() => calculateTax(-1, 0.08)).toThrow();
});

Functional vs Non-Functional Testing

This is the split that decides how you read a failure. Functional testing tells you the software is wrong. Non-functional testing tells you the software is right but not yet fit for the real world.

Commonly Confused Types of Software Testing

Most arguments in test planning are vocabulary disputes rather than technical ones. These seven pairs cause the majority of them, and each has a one-line rule that settles it.

The smoke and sanity distinction causes the most disagreement of the seven, and it is worked through case by case in the dedicated smoke testing vs sanity testing comparison linked earlier.

Testing Types for Modern Architectures

The 15 core types were defined when software was a single deployable unit. Microservices, distributed systems, and AI features each break an assumption those types rely on, and three newer types exist to cover the gap.

• Contract testing verifies that a service still honours the interface its consumers depend on, without spinning up every service at once. It replaces the slow, brittle full-stack integration run that microservice teams outgrow first.
• Chaos and resilience testing injects real failures such as a killed node, added latency, or a dropped dependency, then checks the system degrades gracefully instead of cascading. It tests the recovery path that normal tests never exercise.
• AI agent evaluation checks non-deterministic behaviour, where the same input legitimately produces a different answer each run. Conventional assertions cannot work here because there is no fixed expected string and no DOM state to assert against.

That last one is the sharpest break with everything above. A Selenium assertion checks that button text equals Submit; an AI agent has no such fixed answer, so evaluation shifts from pass or fail on a string to scoring behaviour across quality dimensions. TestMu AI's Agent Testing platform takes that approach, deploying autonomous testing agents against chat, voice, and phone agents and scoring each scenario on dimensions including hallucination, bias, completeness, and context awareness.

Which Types of Software Testing Should You Automate?

Automate a type when it is deterministic and repeated. Keep it manual when the finding is a human judgement. Applying those two rules to the 15 core types splits them cleanly.

By those criteria, unit, integration, system, smoke, regression, performance, load, stress, and compatibility testing should be automated. Usability and beta testing should stay manual. Sanity, acceptance, security, and accessibility testing are partly automated, with a scripted baseline and a human pass on the parts that need judgement.

How to Choose Which Types of Testing to Run

No team runs all 15 types. These eight factors decide the shortlist, and each one maps to a specific action rather than a general principle.

• Cost of a production defect - if a bug can cost money, data, or safety, security and accessibility testing stop being optional.
• Release frequency - shipping weekly or faster makes automated regression testing the difference between confidence and hope.
• Interface stability - a design still changing every sprint argues for testing below the user interface until it settles.
• Audience breadth - a consumer product needs compatibility testing that an internal tool on one managed browser does not.
• Regulatory exposure - public sector, healthcare, and finance work carries accessibility and security conformance obligations.
• Traffic profile - predictable load needs load testing, while a launch or sale event justifies stress testing as well.
• Existing coverage - measure what is already exercised before adding a type, since duplicate coverage across layers is pure cost.
• Team shape - a team without a performance specialist gets more from a strong automated regression suite than from a shallow load test.

Work through them in order:

• Write down what a production defect actually costs your organisation.
• Take the five types every project needs - unit, integration, end-to-end, regression, and compatibility.
• Add security and accessibility testing if regulation or defect cost demands them.
• Add load or stress testing only if you have a real traffic profile to test against.
• Assign each chosen type to a pipeline stage so it has a trigger, not just an owner.
• Review after two releases and drop any type that has never once caught a defect.

Where Each Type Runs in a CI/CD Pipeline

A type without a trigger never runs. Mapping each type to a pipeline stage is what turns a list into a working quality gate, and it is the step most teams skip. The ordering principle is cheapest and most specific first, so the fastest feedback arrives soonest.

Expressed as a pipeline, the same mapping is a handful of jobs separated by trigger:

# Each test type gets its own trigger, cheapest first
jobs:
  unit:
    if: github.event_name == 'push'
    run: npm run test:unit          # Small tests, seconds

  integration-and-smoke:
    if: github.event_name == 'pull_request'
    run: npm run test:integration && npm run test:smoke

  regression:
    if: github.ref == 'refs/heads/main'
    run: npm run test:regression

  e2e-compatibility:
    if: github.event_name == 'schedule'   # nightly
    run: npx playwright test --project=chromium --project=webkit

The stage ordering follows the cost of each type, and the gap is measurable. We ran a smoke check, a functional check, and a compatibility check on the TestMu AI cloud in a single Playwright session against the Selenium Playground, under build 100181973:

PASS     338 ms  smoke: app loads          {"status":200,"title":"Selenium Grid Online | Run Selenium Test On Cloud"}
PASS    1302 ms  functional: form submit   {"echoed":"types of software testing"}
PASS     274 ms  compatibility: mobile     {"width":375}
total 1914 ms

The functional check cost roughly four times the smoke check, because it drives a form and waits on the result rather than asserting the page responded. That ratio is why smoke testing runs first and gates everything else. It also shows why compatibility testing belongs on a cloud grid: the same 274 ms check has to repeat across every browser and operating system your users run, and running those sequentially on one machine is what turns a fast check into an overnight job.

TestMu AI's Automation Cloud runs existing Selenium, Cypress, Playwright, and Puppeteer suites across 3,000+ real browser and OS combinations in parallel, with network logs, console logs, video, screenshots, and command logs captured automatically on every run. Auto Healing recovers from locator changes and SmartWait absorbs timing flakiness, though on Selenium the two are mutually exclusive within a session, so pick the one matching your failure mode. The automation testing documentation covers the grid setup.

Other Types of Software Testing

Beyond the 15 core types, these are the named variants you are most likely to meet in a test plan or a job description. Each is a specialisation of one of the four categories rather than a separate discipline.

Definitions for the wider vocabulary live in the software testing glossary. If you are choosing how to derive the cases inside any of these types rather than which type to run, that is a separate decision covered in software testing techniques.

Conclusion

Start by writing down what a production defect costs you, then take the five types every project needs: unit, integration, end-to-end, regression, and compatibility. Add security and accessibility testing where regulation or risk demands them, and give each type a pipeline trigger so it runs without anyone remembering to run it.

The types you skip are a decision whether or not you make it deliberately. Reviewing that shortlist every couple of releases, and dropping any type that has never caught a defect, keeps the suite honest. Teams tracking that across releases usually manage it alongside their cases in a test management workspace, and the sequencing of the surrounding activities is covered in the software testing life cycle.

Citations

• Google Testing Blog, Test Sizes (Simon Stewart, 2010) - the 60, 300, and 900 second budgets for Small, Medium, and Large tests.
• OWASP Foundation, OWASP Top 10 - the 2025 edition is the most current released version.
• W3C, Web Content Accessibility Guidelines (WCAG) 2.2 - W3C Recommendation, 12 December 2024.
• TestMu AI cloud run, build 100181973 - the smoke, functional, and compatibility timings quoted in the pipeline section.