Bug Taxonomies for Exploratory Testing: Classifying Defects to Find More

01 Oct 2026 — 6 min read

Most teams classify bugs by severity and priority. Useful, but limited. A severity scale tells you how bad a bug is. It doesn't tell you what kind of bug it is, why it happened, or where to look for similar ones.

Bug taxonomies fill that gap. A well-designed taxonomy makes bugs informative — each defect teaches you something about where the system is fragile.

Why Taxonomy Matters for Exploration

Exploratory testing is fundamentally about finding the next bug. Taxonomy helps because bugs cluster.

When you find an input validation failure, there are probably more. When you find a race condition, the same pattern likely exists in similar concurrent operations. When you find an off-by-one error in pagination, pagination throughout the system deserves attention.

A taxonomy gives you the vocabulary to say "this is an X-type bug" and immediately ask "where else might X-type bugs exist?" It turns a single finding into an exploration direction.

The Beizer Taxonomy

Boris Beizer's Software Testing Techniques (1990) gave us the most widely used taxonomic framework. Beizer classified bugs into categories that map to root causes:

Function bugs: The system doesn't do what it's supposed to do. Wrong output for valid input. Missing function entirely.

System bugs: Integration failures — the components work individually but fail together. Wrong interface assumptions, incompatible data formats, timing issues between systems.

Process bugs: The behavior changes based on sequence or state. Operations that work in isolation fail in combination.

Data bugs: Wrong data handling. Bad initial values, incorrect data transformation, data structure failures.

Code bugs: Implementation defects without a specification failure. Off-by-one errors, uninitialized variables, memory issues.

Test bugs: The tests are wrong, not the code. Reveals gaps in test design or requirements misunderstanding.

Beizer's taxonomy is analytical — it maps to development phases and root cause categories. It's useful for post-mortem analysis but can be heavy for real-time exploratory session use.

A Practical Taxonomy for Exploratory Testing

For real-time use during exploration, you need something faster. Here's a practical taxonomy organized by what the tester experiences:

Behavioral failures

The system does the wrong thing with valid input.

Wrong output (calculation error, incorrect response)
Missing behavior (feature doesn't activate)
Extra behavior (unexpected side effects)

Boundary failures

The system fails at limits.

Off-by-one errors (0 vs 1, n vs n+1)
Maximum/minimum value failures
Empty/null/zero handling failures
Maximum length/size failures

State failures

The system behaves differently based on prior actions.

Wrong state after operation sequence
State not persisted correctly
State not cleared when it should be
State corruption under concurrency

Error handling failures

The system handles bad input, failures, or edge cases poorly.

No error message (silent failure)
Wrong error message (misleading)
No recovery path after error
Exception exposed to user
Error leaves system in bad state

Integration failures

The system fails at boundaries with other systems.

Wrong API contract (sends/expects wrong data)
Timeout handling failures
Missing retry logic
Data format mismatch
Authentication/authorization failure across systems

UI/UX failures

The interface misleads or confuses.

Misleading labels or messages
Inconsistent behavior vs. similar features
Accessibility failure
Lost data on navigation
Stale state displayed

Security failures

The system can be exploited.

Input not sanitized (injection)
Authorization not enforced
Sensitive data exposed
Session management failure
CSRF/SSRF vulnerability

Performance failures

The system is slow, resource-hungry, or fails under load.

Unacceptable response time
Memory or CPU spike
Degraded behavior under concurrency
No rate limiting

Using Taxonomy During a Session

During an exploratory session, log bug type alongside the defect description:

Bug: checkout silently drops items when cart has >50 products
Type: boundary failure (maximum count)
Severity: critical
Exploration direction: are there other implicit maximums in cart/order flow?

The "exploration direction" field is the key addition. When you classify a bug, immediately ask where else that pattern might appear.

Boundary failure → scan for similar boundaries: What other operations have implicit maximums? What about minimum limits?

State failure → probe similar state transitions: Which other features have multi-step flows? Are they using the same state management approach?

Error handling failure → test all error paths: If one error is handled badly, scan for other error paths in the same flow.

Integration failure → find similar integrations: If one API call fails badly, other calls to the same service probably have similar issues.

Building an Organizational Bug Taxonomy

The taxonomies above are starting points. Your organization's most useful taxonomy is the one built from your own history.

Step 1: Audit past bugs

Pull 100 bugs from the past year. For each one, ask: what fundamental type of failure was this?

Look for patterns. If 40% of your bugs are state failures, your state management code deserves extra attention. If 25% are error handling failures, your team has a systematic gap in error handling.

Step 2: Identify your top bug types

Most organizations have 3–5 dominant bug types. These are the categories worth tracking actively.

Example findings from a real audit:

35% boundary failures (the system was heavy on business logic with many limits)
28% state failures (complex multi-step workflows)
18% integration failures (many third-party APIs)
12% error handling failures
7% other

Step 3: Create targeted charters

For each dominant bug type, create a class of charters specifically designed to find that type:

Boundary hunting charter: "Explore [feature] using boundary values — maximums, minimums, zero, empty — to discover limit handling failures"

State corruption charter: "Explore [multi-step workflow] using interruptions, back navigation, and concurrent operations to discover state management failures"

Error path charter: "Explore [feature] inducing failures at each step — network errors, invalid data, timeouts — to discover error handling coverage"

Step 4: Track and refine

Track which charter types find the most bugs for your system. Over time, your taxonomy reflects actual failure patterns, not theoretical ones.

Taxonomy and Root Cause Analysis

When a production incident occurs, classify it. Then ask: what charter type would have caught this?

If it was a boundary failure, check whether your charter backlog includes boundary hunting charters for that feature area. If not, write them.

This creates a feedback loop:

Production incident → classify bug type
Map bug type to charter type
Check charter backlog coverage
Add missing charters

After 6 months of this, your charter backlog reflects your actual production risk profile.

Common Taxonomies in Use

James Whittaker's Attack Patterns

Whittaker's How to Break Software (2002) organizes testing as "attacks" — techniques for finding specific failure types:

Disturb the environment (no disk space, no memory, network failure)
Manipulate user interface inputs (boundary values, special characters)
Trigger state-based failures (navigation patterns, session issues)
Attack the software directly (configuration, installation, timing)

The "attack" framing is useful for security-oriented exploration. Each attack type maps to a charter pattern.

ODC (Orthogonal Defect Classification)

IBM's ODC taxonomy is used for process improvement, not real-time exploration:

Trigger (what caused the bug to surface): boundary testing, normal mode testing, load testing, etc.

Defect type: assignment, checking, algorithm, interface, function, timing/serialization, build/package/merge, documentation

Target: design, code, build, testing

ODC is heavy for daily use but useful for quarterly process reviews. Run an ODC analysis on your bug database to understand where defects are introduced.

The Heuristic Test Strategy Model (HTSM)

James Bach's HTSM lists quality criteria and provides a systematic way to generate test ideas. It's not a bug taxonomy per se, but the quality criteria map to bug types:

Capability (function bugs)
Reliability (state and system bugs)
Performance (performance bugs)
Usability (UI/UX bugs)
Security (security bugs)
Compatibility (integration bugs)
Supportability (error handling, logging)
Installability (environment bugs)

Using HTSM to generate charters ensures you're not systematically missing whole categories of bugs.

Bug Clustering: Finding More from One

When you find a bug, use taxonomy to find its relatives.

Same type, same component: The bug represents a failure mode that code often exhibits consistently. If one API handler doesn't validate input, others probably don't either.

Same type, different component: If the team had a pattern of getting state transitions wrong, that pattern likely appears throughout the codebase.

Same trigger, different target: If the system fails under high concurrency in one place, stress charters for other shared resources are warranted.

Clustering turns a single bug find into a systematic sweep. A tester who finds one boundary failure and immediately generates 5 more boundary-hunting probes for adjacent features is using taxonomy effectively.

Reporting with Taxonomy

Bug reports that include taxonomy information are more actionable.

Basic report: "Cart drops items silently when over 50 products"

Taxonomized report:

Title: Cart silently drops items at >50 product limit
Type: Boundary failure (implicit maximum, no user feedback)
Severity: Critical (data loss without notification)
Cluster risk: Other quantity/limit operations in order flow
Related patterns: Check: order line limit, wishlist limit, saved cart limit

Steps: Add 51 products to cart, proceed to checkout. Expect: error message or truncation notice. Actual: items 51+ silently removed.

The "cluster risk" and "related patterns" fields tell developers and other testers where to look next. The bug report becomes an exploration lead, not just a defect description.

Summary

Bug taxonomies turn individual defects into exploration intelligence. When you classify a bug as a "boundary failure" or "state corruption," you immediately know where to look next.

Build your taxonomy from your own bug history. Find your organization's dominant failure modes. Write charters that specifically target those failure types.

The goal isn't perfect classification. It's directional: each bug you find should point toward the next one.