Testing is like a Swiss Army knife: it has many blades, each designed for its own task.
And if you want to be more than just a “button clicker” and become a true quality engineer, it’s important to understand the different types of testing, how they differ, and why they are needed at all.

This article systematizes what is often confused: the criteria by which testing types are classified and how they relate to each other.

By the degree of system knowledge

1. Black-box testing

You don’t know how the system works inside. You only care about input → output. You provide data and see what happens.

Used for: UI tests, API tests, acceptance testing.
Example: submit a form and check whether an email is received.

2. White-box testing

You know the code and logic. You check specific branches, loops, code coverage, and internal functions.

Used for: unit tests, static analysis, code coverage.
Example: testing a function that calculates delivery costs with all conditions applied.

3. Gray-box testing

You partially know the internal structure. You combine external and internal approaches. A great compromise.

Used for: integration testing, API tests with business logic understanding.
Example: knowing how the backend is structured and testing the API with that in mind.

By testing level

1. Unit testing

Testing a single function or module. Fast, precise, automated.

Who writes: most often developers.
Tools: JUnit, pytest, Go test, etc.

2. Integration testing

Checking how modules work together. Errors often appear at the boundaries.

Example: verifying interaction between the API and the database.

3. System testing

Testing the entire system as a whole. Checking requirements, logic, and behavior.

Example: running automated tests on a built version of the application.

4. Acceptance testing

Testing business logic and user scenarios to ensure everything meets customer expectations.

May be done manually or automatically. Often performed in production or near-production environments.

By testing goal

1. Functional testing

Verifying that the product does what it’s supposed to do.

Example: checking login with email and password.

2. Non-functional testing

Verifying the quality of how the system works: speed, reliability, usability, security.

Key types:

• Load testing - how the system behaves under load
• Stress testing - what if we push it to the max?
• Security testing - what if someone tries to hack it?
• Usability testing - is it even convenient to use?

By degree of automation

1. Manual testing

Checking manually: clicks, inputs, visual inspection.

Pros: flexibility, intuitiveness, quick UI checks.
Cons: not reproducible, costly, slow.

2. Automated testing

Scripts and test frameworks check the application automatically.

Pros: speed, repeatability, coverage.
Cons: high implementation cost, requires maintenance.

By timing in the development process

• Smoke testing - “does the system even run?”
• Sanity testing - quick check of critical functionality
• Regression testing - did something old break after changes?
• Migration testing - checking after data migration or upgrades
• Compliance testing - does the product meet standards and regulations?

Cheat sheet table

| Criterion         | Examples                                   |
|-------------------|--------------------------------------------|
| System knowledge  | Black, White, Gray box                     |
| Level             | Unit, Integration, System                  |
| Goal              | Functional, Non-functional                 |
| Automation        | Manual, Automated                          |
| Development stage | Smoke, Regression, Acceptance, etc.        |