What Is Black-Box Testing?
Black-box testing — also called behavioral testing, specification-based testing, or functional testing — designs tests based entirely on what the software should do according to its requirements and specifications. The tester has no knowledge of the internal code, architecture, or implementation details.
Think of it like using a vending machine. You insert money, press a button, and expect a specific product. You do not know or care about the internal machinery — you only verify that the correct output appears for the given input.
Black-box testing answers the question: “Does the system behave as specified?”
Who Performs Black-Box Testing?
Black-box testing can be performed by:
- QA engineers — the most common practitioners, testing against requirements
- Business analysts — verifying that features match business expectations
- End users — during User Acceptance Testing (UAT)
- Developers — when writing integration or system tests
No programming skills are required, making it accessible to a wider range of team members.
Core Black-Box Techniques
Black-box techniques provide systematic methods for selecting test inputs. These techniques are covered in depth in Module 3 (Test Design Techniques), but understanding the overview is essential at this stage.
Equivalence Partitioning (EP)
Equivalence partitioning divides the input domain into classes (partitions) where all values within a class are expected to produce the same behavior. You then test one representative value from each class.
Example: An age input field accepts values 18-65.
| Partition | Range | Representative Value | Expected Result |
|---|---|---|---|
| Invalid (below) | < 18 | 10 | Error |
| Valid | 18-65 | 30 | Accepted |
| Invalid (above) | > 65 | 80 | Error |
Instead of testing all values from 0 to 100, you test just three. The assumption is that if the system handles 30 correctly, it will handle 25, 40, and 55 the same way.
Boundary Value Analysis (BVA)
Boundary value analysis focuses on the edges of equivalence partitions, where bugs are most likely to occur. Off-by-one errors are among the most common programming mistakes.
Using the same age example (valid range 18-65):
| Boundary | Values to Test | Why |
|---|---|---|
| Lower boundary | 17, 18, 19 | Tests the exact transition from invalid to valid |
| Upper boundary | 64, 65, 66 | Tests the exact transition from valid to invalid |
BVA typically tests the boundary value, one below, and one above. For two boundaries, this produces 6 test values instead of 48 from testing the entire range.
Decision Tables
Decision tables are used when the system behavior depends on combinations of conditions. They systematically list all possible combinations and the expected outcomes.
Example: An insurance discount depends on age and driving record:
| Condition | Rule 1 | Rule 2 | Rule 3 | Rule 4 |
|---|---|---|---|---|
| Age > 25 | Yes | Yes | No | No |
| Clean record | Yes | No | Yes | No |
| Discount | 15% | 5% | 5% | 0% |
Each column represents a unique combination that must be tested. With 2 conditions having 2 values each, there are 2² = 4 rules. With more conditions, the table grows exponentially, and techniques like collapsing redundant rules become important.
State Transition Testing
State transition testing models the system as a finite state machine with defined states, transitions, and events. Tests are designed to exercise each state and transition.
Example: A user account can be in states: Active, Locked, Suspended, Deleted.
Tests would verify each transition: Can a locked account be reactivated after password reset? Does the account get deleted after 30 days of being locked? Can a suspended account be directly deleted?
When to Use Black-Box Testing
Black-box testing is most effective for:
- Functional testing — verifying features work as specified
- Acceptance testing — business users validating requirements
- System testing — testing the complete integrated application
- Regression testing — verifying existing functionality after changes
- Usability testing — evaluating the user experience
Black-Box vs. White-Box: A Comparison
| Aspect | Black-Box | White-Box |
|---|---|---|
| Test basis | Requirements, specifications | Source code, architecture |
| Knowledge needed | Domain knowledge, requirements | Programming skills, code access |
| What it finds | Missing requirements, behavior errors | Logic errors, dead code, security flaws |
| What it misses | Internal logic errors, dead code | Missing features, usability issues |
| Who performs it | QA, BA, users | Developers, SDETs |
| Testing level | System, acceptance, E2E | Unit, integration |
| Test design timing | Can start early (from requirements) | Requires completed code |
| Maintenance | Low (tests survive refactoring) | High (tests break when code changes) |
Neither approach is superior. They complement each other. A mature testing strategy uses both:
- White-box for unit and integration testing (developers)
- Black-box for system and acceptance testing (QA team)
Advantages and Limitations
Advantages:
- Tests can be designed as soon as requirements are written
- No source code knowledge needed — broader team participation
- Tests are independent of implementation — they survive code refactoring
- Catches requirements gaps and specification errors
- Simulates the user perspective
Limitations:
- Cannot guarantee code coverage — untested code paths remain hidden
- Redundant tests are possible (testing the same internal path without knowing it)
- Difficult to design tests for complex internal logic without code insight
- May miss edge cases that are obvious from reading the code
- Requires clear, complete specifications (which are rare in practice)
Exercise: Design Black-Box Test Cases from a Specification
You are testing a loan eligibility calculator with these requirements:
Requirements:
- Applicant must be between 21 and 65 years old (inclusive)
- Minimum annual income: $25,000
- Credit score must be 600 or higher
- Loan amount requested must be between $1,000 and $500,000
- If credit score is 750+ AND income is $75,000+, interest rate is 3.5% (premium rate)
- If credit score is 600-749 OR income is $25,000-$74,999, interest rate is 7.0% (standard rate)
- If any eligibility criteria fails, the application is rejected
Part 1: Equivalence Partitioning. Identify the equivalence partitions for each input field. For each partition, specify a representative value and the expected outcome.
Part 2: Boundary Value Analysis. Identify the boundary values for each input field and design test cases using the boundary + one below + one above approach.
Part 3: Decision Table. Create a decision table for the interest rate determination (requirements 5 and 6). List all condition combinations and the expected interest rate.
Part 4: Design 8-10 complete test cases that provide good coverage of these requirements. For each test case, specify all four inputs (age, income, credit score, loan amount) and the expected result.
Hint
For Part 1, each input field has at least 3 partitions: below valid range, valid range, and above valid range. Some may have sub-partitions within the valid range (e.g., credit score has standard and premium tiers).For Part 3, focus on the two conditions that determine the interest rate: credit score threshold (750) and income threshold ($75,000). There are 4 combinations.
Solution
Part 1: Equivalence Partitions
Age:
| Partition | Range | Representative | Expected |
|---|---|---|---|
| Invalid (young) | < 21 | 18 | Rejected |
| Valid | 21-65 | 40 | Eligible |
| Invalid (old) | > 65 | 70 | Rejected |
Income:
| Partition | Range | Representative | Expected |
|---|---|---|---|
| Invalid (low) | < $25,000 | $15,000 | Rejected |
| Valid (standard) | $25,000-$74,999 | $50,000 | Standard rate |
| Valid (premium) | $75,000+ | $100,000 | Premium eligible |
Credit Score:
| Partition | Range | Representative | Expected |
|---|---|---|---|
| Invalid (low) | < 600 | 500 | Rejected |
| Valid (standard) | 600-749 | 650 | Standard rate |
| Valid (premium) | 750+ | 800 | Premium eligible |
Loan Amount:
| Partition | Range | Representative | Expected |
|---|---|---|---|
| Invalid (low) | < $1,000 | $500 | Rejected |
| Valid | $1,000-$500,000 | $100,000 | Accepted |
| Invalid (high) | > $500,000 | $600,000 | Rejected |
Part 2: Boundary Values
| Field | Boundaries to Test |
|---|---|
| Age | 20, 21, 22, 64, 65, 66 |
| Income | $24,999, $25,000, $25,001, $74,999, $75,000, $75,001 |
| Credit Score | 599, 600, 601, 749, 750, 751 |
| Loan Amount | $999, $1,000, $1,001, $499,999, $500,000, $500,001 |
Part 3: Decision Table (Interest Rate)
| Condition | Rule 1 | Rule 2 | Rule 3 | Rule 4 |
|---|---|---|---|---|
| Credit ≥ 750 | Yes | Yes | No | No |
| Income ≥ $75,000 | Yes | No | Yes | No |
| Rate | 3.5% | 7.0% | 7.0% | 7.0% |
Only Rule 1 (both conditions met) qualifies for the premium 3.5% rate. All other combinations get the standard 7.0% rate.
Part 4: Complete Test Cases
| # | Age | Income | Credit | Loan | Expected Result |
|---|---|---|---|---|---|
| 1 | 40 | $100,000 | 800 | $200,000 | Approved, 3.5% |
| 2 | 35 | $50,000 | 650 | $100,000 | Approved, 7.0% |
| 3 | 18 | $80,000 | 780 | $50,000 | Rejected (age < 21) |
| 4 | 30 | $15,000 | 700 | $50,000 | Rejected (income < $25K) |
| 5 | 30 | $60,000 | 500 | $50,000 | Rejected (credit < 600) |
| 6 | 30 | $60,000 | 700 | $600,000 | Rejected (loan > $500K) |
| 7 | 21 | $25,000 | 600 | $1,000 | Approved, 7.0% (all minimums) |
| 8 | 65 | $500,000 | 850 | $500,000 | Approved, 3.5% (all maximums) |
| 9 | 45 | $100,000 | 700 | $150,000 | Approved, 7.0% (high income, standard credit) |
| 10 | 45 | $50,000 | 780 | $150,000 | Approved, 7.0% (standard income, high credit) |
Combining Black-Box Techniques
In practice, experienced testers combine multiple techniques:
- Start with equivalence partitioning to identify the main input categories
- Apply boundary value analysis to the edges of each partition
- Use decision tables when multiple conditions interact
- Use state transition testing for stateful behavior
This combination provides efficient coverage without exhaustive testing. The techniques from this lesson are explored in much greater depth in Module 3.
Key Takeaways
- Black-box testing designs tests from requirements and specifications without code knowledge
- Equivalence partitioning reduces test cases by grouping similar inputs
- Boundary value analysis targets the edges where most bugs hide
- Decision tables systematically cover condition combinations
- State transition testing verifies behavior across system states
- Black-box and white-box testing complement each other — mature teams use both
- Black-box tests are resilient to code changes since they are based on behavior, not implementation