Test Levels vs Test Types: Finally Explained

A practical guide to understanding what you're testing, how you're testing it, and why the difference matters.

Approximately 7 min read | ISTQB CTFL v4.0.1

If you've ever mixed up system testing, integration testing, functional testing, and regression testing, you're definitely not alone.

These terms often appear together in test plans, interviews, and certification questions. But they don't all describe the same thing.

1. What Are Test Levels?

Test levels organize testing according to the scope of the software being tested and the objectives of that testing.

ISTQB CTFL v4.0.1 identifies five test levels.

Let's imagine a fictional online store. Customers can add products to a cart, apply discounts, pay, and receive confirmations.

Component Testing

Imagine a function that calculates a discount. We test that calculation independently.

Does it handle a 10% discount correctly? What happens when the discount is zero? What about invalid inputs?

Remember: Are the individual building blocks correct?

Component Integration Testing

Now the shopping cart needs to communicate with the discount calculation component.

Both components may work individually, but do they exchange information correctly?

Remember: Do internal components work together?

System Testing

Now we test the complete online store. A customer adds a product, applies a discount, completes checkout, and receives an order confirmation.

The focus is on the behavior of the system as a whole. System testing may include both functional and non-functional checks.

Remember: Does the complete system behave as expected?

System Integration Testing

Imagine the online store communicates with an external payment provider.

The application sends a payment request, receives or retrieves a result, and updates the order.

What happens if the provider responds late? What if the payment succeeds externally but the application still shows Pending?

Remember: Does our system communicate correctly with external systems and services?

Acceptance Testing

Finally, business stakeholders want to confirm that the online store supports the intended business needs and is ready for acceptance.

User Acceptance Testing (UAT) is one form of acceptance testing. Other forms include operational, contractual, regulatory, alpha, and beta acceptance testing.

Remember: Is the system suitable for its intended use?

Test levels don't always happen in a strict sequence. Their activities may overlap, depending on the development lifecycle.

2. What Are Test Types?

Test types focus on specific quality characteristics or the basis used to derive tests.

CTFL v4.0.1 covers four test types.

Functional Testing

Functional testing evaluates what the software should do.

• Can a customer add a product to the cart?
• Is the discount calculated correctly?
• Does the payment status update as required?
• Can a user reset their password?

Remember: What does the system do?

Non-functional Testing

Non-functional testing evaluates how well the software behaves and whether it satisfies relevant quality requirements.

• Is checkout fast enough under expected load?
• Is the interface accessible?
• Does the system meet security requirements?
• Is it reliable under expected conditions?

Remember: How well does the system behave?

Black-box Testing

Black-box testing derives tests from specifications and expected behavior, without depending on knowledge of internal implementation.

Imagine a discount field that accepts values from 0 to 50. We can design valid, invalid, and boundary test cases from the requirements.

Remember: Design tests from specifications, not internal code structure.

White-box Testing

White-box testing derives tests from knowledge of internal implementation or structure.

For example, a discount calculation contains several conditional branches. Tests can be designed to exercise these branches and measure coverage.

Remember: Design tests using internal structure.

3. Can a Test Have Both a Level and a Type?

Absolutely. They describe different dimensions of testing.

These are illustrative classifications based on the stated test objectives. Actual classification depends on scope and context.

4. Regression vs Confirmation Testing

These two are particularly easy to confuse. Both are important when software changes.

Confirmation Testing

A defect was reported and fixed. We test the affected behavior again to confirm that the original problem no longer occurs.

Question: Did the fix resolve the reported defect?

Regression Testing

A change has been introduced. We test for unintended consequences in previously working functionality.

Question: Did the change break something else?

5. How I Remember It

6. Common Mistakes to Avoid

• Confusing Component Integration with System Integration Testing.
• Assuming System Testing is always functional.
• Assuming Black-box means manual testing.
• Treating Regression Testing as a test level.
• Thinking End-to-End Testing is a separate sixth ISTQB test level.

7. Final Thought

Here's the simplest way I remember the difference.

When you encounter a scenario-based ISTQB question, don't rush to recognize a familiar word.

First, identify the actual test objective. Understanding why a test belongs to a particular level or type is more useful than simply memorizing a list.

Reference

Based on the ISTQB Certified Tester Foundation Level Syllabus v4.0.1, Section 2.2.

Read the official ISTQB syllabus

Examples and practice questions are original educational material. This article is not affiliated with or endorsed by ISTQB.

← Explore more Field Notes