Types of Software Testing: A Guide

Software testing is easier to understand when you sort it across three dimensions: level (what scope is tested), objective (what behavior or quality is evaluated), and approach (how the test is performed). A single activity can be described on all three dimensions: for example, automated functional testing at system level.

This guide uses the introductory taxonomy in the ISTQB Certified Tester Foundation Level syllabus v4.0.1 and the ISO/IEC/IEEE 29119 series overview. Standards and teams may use terms differently, so name the framework when precision matters.

1. The three dimensions of software testing

Dimension	Question it answers	Examples
Level	What is the test object and its scope?	Component, component integration, system, system integration, acceptance
Objective or type	What behavior or quality are we evaluating?	Functional behavior; non-functional characteristics such as performance or usability
Approach	How is the test designed or executed?	Manual or automated; scripted or unscripted; static or dynamic; white-box or black-box

These categories are not competing items in one master list. For example, a scripted automated test can check a non-functional objective at system level. Decide the level, objective, and approach separately, then describe the combination.

2. Test levels: what scope is being checked?

ISTQB CTFL v4.0.1 describes five principal levels. The sequence below is common, but it is not a rule that every product must use every level in the same way. ISO’s overview notes that testing at all levels is not always necessary; tailor coverage to the test object, objectives, risks, and environment.

Level	Typical test object	Main question	Example
Component (often called unit)	An individual component or unit	Does this small part behave as specified?	Check how a price calculation handles a zero quantity.
Component integration	Interactions among components	Do connected parts exchange data and control correctly?	Check that an order component passes the expected total to a payment component.
System	The integrated system	Does the system as a whole meet its specified behavior?	Complete a purchase flow through the application.
System integration	Interfaces between the system and other systems or services	Does the product interact correctly with external systems?	Check the application’s interaction with an external payment service.
Acceptance	The product or solution in a business or user context	Is it ready and suitable for the intended needs and use?	Have intended users or stakeholders assess a workflow against business needs.

Component versus component integration

Component testing focuses on one component in isolation or under controlled conditions. Component integration testing focuses on connections among components within the product. The distinction is the boundary under examination, not the programming language or test tool.

Component integration versus system integration

Component integration examines interactions among product components. System integration examines interfaces between the system under test and other systems or services. A team may use mocks or controlled dependencies in earlier checks, then validate real or representative interfaces at system integration level.

System versus acceptance

System testing evaluates the integrated system against specified requirements. Acceptance testing evaluates readiness against business needs and intended use. Acceptance is therefore not simply another name for system testing: it brings a different purpose and often different stakeholders or criteria.

3. Test objectives: what is being evaluated?

Functional testing

Functional testing checks what a component or system should do. The expected behavior comes from a test basis such as requirements, examples, business rules, or interface contracts. Useful cases include normal inputs, boundary values, invalid inputs, and important state transitions.

For a password reset flow, functional checks might ask whether a valid request produces the expected response, whether an unknown account is handled according to the product’s rules, and whether a reset token can be used as intended.

Non-functional testing

Non-functional testing evaluates how well the system behaves against quality characteristics. ISTQB points to ISO/IEC 25010 for a classification of these characteristics. Examples developers commonly investigate include performance, security, usability, reliability, and compatibility; select and define the characteristics relevant to the product and its requirements.

A test can have both functional and non-functional concerns. A checkout may produce the correct result (functional) while taking too long under a specified workload (non-functional). State the objective clearly so the result has an interpretable pass or failure condition.

4. Acceptance testing forms

Acceptance testing checks whether a product or solution is ready against needs and criteria beyond merely demonstrating that the system operates. ISTQB identifies several forms:

User acceptance testing: evaluates the product from the users’ perspective and against their needs.
Operational acceptance testing: considers operational readiness, such as whether the solution can be run and supported as required.
Contractual acceptance testing: evaluates acceptance criteria agreed through a contract.
Regulatory acceptance testing: evaluates relevant regulatory acceptance criteria.
Alpha and beta testing: forms of acceptance testing that involve users or environments associated with the product’s intended use; the specific setup depends on the product and process.

Choose the form based on who needs confidence and which acceptance criteria apply. Acceptance criteria should be stated before evaluation so stakeholders can interpret results consistently.

5. Test approaches and design distinctions

Approach labels describe how testing is performed or how test cases are derived. They complement levels and objectives; none replaces them.

Distinction	Meaning	Practical use
Static / dynamic	Static testing evaluates work products without executing the software; dynamic testing executes software and evaluates its behavior.	Review a requirement or code change before running the application; execute tests to observe runtime outcomes.
Manual / automated	A person performs the test steps, or a tool executes some or all of them.	Manual exploration can investigate unexpected behavior; automation can repeat stable checks and report results.
Scripted / unscripted	Testing follows defined steps and expected results, or the tester has more freedom to explore.	Use a script when repeatability matters; use unscripted exploration to investigate areas where useful paths are not fully known.
White-box / black-box	Test design uses knowledge of internal structure, or focuses on externally observable behavior without relying on that internal knowledge.	Use implementation knowledge to target paths or boundaries; use specifications and observable inputs and outputs to check behavior.

These are useful distinctions, not always strict either-or choices. A tester can combine approaches, and the right mix depends on the test objective, the information available, and the risk.

6. Retesting and regression testing

When a change is made, teams often need to check both the specific issue and the possibility of unintended effects elsewhere. Retesting is commonly used informally for checking a reported failure again after a fix; regression testing commonly refers to checking whether a change has adversely affected existing behavior. Terminology can vary between frameworks and teams, so define these terms in the project’s test strategy. Both activities can apply at different test levels.

Choose regression coverage based on what changed, dependencies, and the consequences of a failure. A focused check gives quick feedback on the changed behavior; broader checks provide evidence across related paths and interfaces.

7. How to choose a useful testing mix

Identify the test object. Decide whether the question concerns a component, connections among components, the integrated system, external interfaces, or business readiness.
State the objective. Specify the behavior or quality characteristic and what evidence would count as success.
Assess risk and consequence. Prioritize areas where failure would have the greatest effect, including critical workflows and important boundaries.
Check dependencies and environment realism. Decide whether a controlled substitute is adequate or the test needs a representative external service, device, data set, or deployment environment.
Choose an approach. Select manual or automated execution and scripted or exploratory work based on repeatability, uncertainty, and feedback needs.
Plan change coverage. Identify the focused checks for changed behavior and the related existing behavior that merits regression coverage.
Record the framework and limits. Document terminology, assumptions, test data, environment, and what the result does not establish.

A practical plan usually balances scope, risk, dependency realism, speed of feedback, and maintenance effort. Those tradeoffs depend on the implementation; no one level or approach is universally sufficient.

8. Example: testing a web checkout

Consider a web checkout that calculates an order total, hands the order to a payment component, and calls an external payment service.

Dimension	Example choice
Level	Component tests for total calculation; component integration for checkout-to-payment handoff; system tests for the full purchase flow; system integration for the external payment interface; acceptance checks for business readiness.
Objective	Functional checks for totals and flow behavior; non-functional checks for relevant quality requirements such as performance or security.
Approach	Automate repeatable cases with stable expected outcomes; use manual or unscripted investigation where behavior needs exploration; use appropriate test data and environments.

This example shows why “unit versus integration versus end-to-end” alone is incomplete. It describes scope but leaves out the objective and execution approach.

9. Visual testing for web interfaces

For browser-based products, screenshots can help compare visible output across routes, viewports, themes, and states. A screenshot is evidence of appearance at a point in a particular environment; it does not establish that underlying functionality, accessibility, or all responsive states are correct. Pair visual checks with tests suited to those questions.

Make comparisons reproducible by controlling the URL, viewport or device, color scheme, wait condition, and relevant page state. Dynamic timestamps, rotating content, animations, cookie banners, and third-party widgets can create differences unrelated to the change under review. Decide whether to stabilize, hide, or separately assess those elements.

10. Screenshot capture options for repeatable visual checks

A browser-based screenshot workflow generally needs a browser runtime, a target URL, a viewport, and a wait condition that fits the page. Full-page capture is useful for long documents; selector capture narrows the image to an element. Device presets or custom viewport sizes help cover layout changes. Dark mode, custom CSS, JavaScript, cookies, headers, user agents, and geolocation can set up a particular state when the page needs them. Use request blocking or hidden selectors carefully, because they can change the page being evaluated.

For a one-off, run a browser capture locally and save the image. For repeatable checks, keep the capture settings alongside the test case, use stable test data, and decide how to handle image differences before reviewing results. PDF output can be useful when the artifact is a document or print layout rather than a viewport image.

11. Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server for developers. One GET request can return a PNG, JPEG, WebP, or PDF. See the ScreenshotNeo API documentation for the request options.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
    timeout=90,
)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await Bun.write('shot.webp', res);

Replace the example URL with the page under test and supply your API key. ScreenshotNeo removes cookie banners, newsletter popups, and chat widgets before the shot; each of those steps can be turned off. Bot checks, blank pages, failed loads, timeouts, and cache hits are not billed, and response headers report the page verdict and billing status. Its MCP server provides take_screenshot, get_page_info, and capture_pdf tools for AI agents. The free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000 screenshots.

12. Troubleshooting common testing problems

Symptom	Likely cause	What to do
A test passes alone but fails in a suite	Shared state, order dependence, or test data that is not isolated.	Make setup and cleanup explicit, isolate data, and check whether a prior test changes shared state.
A component test passes but the workflow fails	The defect may be in component interactions, system behavior, or an external interface outside the component’s test boundary.	Add a test at the level that includes the failing boundary and inspect the exchanged data and assumptions.
A system integration check behaves differently from a local test	The local environment may use substitutes or differ in configuration, credentials, data, or dependency behavior.	Compare environments and determine which interface behavior needs representative coverage.
Acceptance results are disputed	Criteria, stakeholders, or intended usage were unclear or changed.	Agree on observable acceptance criteria and relevant stakeholders before evaluation.
Automated UI checks are unstable	Timing, dynamic content, animations, or external widgets may change between runs.	Wait for a meaningful condition, stabilize test data, and isolate or intentionally assess dynamic regions.
Visual comparisons show noisy differences	Viewport, theme, fonts, data, browser state, or page timing may not match.	Control capture conditions and compare equivalent states before treating a difference as a product change.
Many tests run, but confidence remains low	The suite may repeat easy cases while missing high-risk objectives, levels, or dependencies.	Map coverage to test objects, objectives, risks, and interfaces; remove redundant cases only after checking what evidence they provide.

13. Performance, reliability, and cost considerations

Feedback time: Narrow checks can often return feedback sooner than checks involving a full system or external services. Use fast feedback where it helps developers, while retaining coverage at boundaries that matter.
Reliability: Repeatable results depend on controlled inputs and a known environment. Record relevant versions, configuration, data, and dependencies so failures can be investigated.
Maintenance: Automated checks need upkeep as behavior and interfaces change. Automate stable, valuable checks; retain human investigation where interpretation or exploration is needed.
Environment cost: More realistic environments may require additional setup and coordination. Choose realism according to the risk and question being tested.
Test evidence: A passing result only supports the conditions and objective that were actually checked. It does not prove the absence of all defects.

These are practical planning considerations, not universal performance figures. The appropriate balance varies with the product, architecture, risks, and team workflow.

14. FAQ

Are there universally agreed types of software testing?

There are widely used frameworks and standards, but terminology and classification can differ. This guide uses the ISTQB CTFL v4.0.1 introductory framework and identifies the ISO/IEC/IEEE 29119 series as a standards framework.

Does every project need all five test levels?

No. Select levels according to the test object, objectives, risks, dependencies, and environment. The usual sequence is a useful model, not a requirement to apply every level identically.

Can one test be both functional and automated?

Yes. Functional describes the objective; automated describes the execution approach. The test can also be assigned a level, such as system.

Is acceptance testing the same as user acceptance testing?

User acceptance is one form. Other identified forms include operational, contractual, and regulatory acceptance testing, as well as alpha and beta testing.

Which standards edition should I cite?

Check the current edition of the relevant part before citing or purchasing it. The dossier identifies ISO/IEC/IEEE 29119-1:2022 and Part 2:2021 as newer editions than the 2013 versions shown in older catalog pages.

Sources and terminology

ISTQB Certified Tester Foundation Level Syllabus v4.0.1 for introductory definitions of levels, types, and acceptance forms.
ISO/IEC JTC 1/SC 7 overview of the ISO/IEC/IEEE 29119 series for the series’ scope and parts.
IEC catalog: ISO/IEC/IEEE 29119-1:2022 and IEC catalog: ISO/IEC/IEEE 29119-2:2021 for edition context.