Most QA automation engineers don't fit cleanly into either category: you test visible behavior from the user perspective (black-box), but you know the API structure, can read code to understand edge cases, and check coverage reports to find gaps (white-box elements). The distinction matters because each approach is optimized for different bugs: black-box catches requirement mismatches and UI behavior failures, white-box catches untested code paths and internal logic errors. This article explains what each covers, which techniques belong to each, and how all three modes appear on the same feature in a typical sprint.

Black-box testing

In black-box testing, you test the system without knowledge of, or reference to, its internal implementation. You treat the software as a "black box": input goes in, output comes out, and you don't care what happens inside.

You test based entirely on:

  • Requirements ("when the user enters X, Y should happen")
  • Specifications ("the field accepts 1–100 characters")
  • User expectations ("this should work like any standard login form")

You don't look at code. You don't know — or at least don't rely on knowing — what framework is being used, how the data is stored, or what algorithm runs the calculation.

What black-box testing looks like

  • Testing a login form by entering valid and invalid credentials
  • Verifying that clicking "Add to Cart" adds the correct item
  • Checking that an API returns the right data for a valid request
  • Confirming that an error message appears when a required field is empty
  • Running end-to-end tests in Playwright

Techniques used in black-box testing

  • Equivalence partitioning: dividing inputs into valid/invalid groups
  • Boundary value analysis: testing at the edges of input ranges
  • Decision table testing: testing combinations of conditions
  • State transition testing: testing how the system moves between states
  • Use case / scenario testing: testing based on real user workflows

Advantages

  • You test what users actually experience, not what developers think they built
  • No programming knowledge required (for functional black-box testing)
  • Catches requirement mismatches — when the spec said one thing and the implementation did another
  • Works from day one, even before the system is built (you can write test cases from requirements)

Disadvantages

  • You might miss paths through the code that no requirement explicitly covers (dead code, error branches)
  • Without knowing the code, you might test the same logic many times and miss other paths entirely
  • Can't verify things that aren't visible from the outside (memory leaks, internal data corruption)

White-box testing

In white-box testing, you test with knowledge of the internal implementation. You know the code, the logic, the data structures, and the algorithms — and you use that knowledge to design tests.

Also called: glass-box testing, clear-box testing, structural testing, or code-based testing.

What white-box testing looks like

  • Writing unit tests that call functions directly and verify their behavior
  • Looking at a conditional branch in code and writing a test for each branch
  • Analyzing which code paths aren't covered by any existing test
  • Checking that a specific SQL query runs correctly
  • Testing internal APIs or methods that aren't exposed in the UI

Techniques used in white-box testing

  • Statement coverage: every line of code is executed at least once by the tests
  • Branch coverage: every if/else branch is executed at least once
  • Path coverage: every possible path through the code is tested
  • Mutation testing: deliberately changing code to see if tests catch the change

Who does it

White-box testing is typically done by:

  • Developers writing unit tests
  • QA engineers who can read code reviewing test coverage
  • Security engineers doing code audits

As a QA automation engineer, you're on the spectrum: you don't write unit tests, but you can read the code to understand what to test and look at coverage reports to find gaps.

Advantages

  • Finds bugs that no requirement explicitly describes — edge cases in internal logic
  • Ensures code coverage — you can see which paths are actually tested
  • More efficient for optimization and security testing
  • Catches dead code, unused branches, impossible conditions

Disadvantages

  • Requires knowledge of the implementation — needs programming skills
  • Can lead to testing the implementation rather than the requirements (confirmation bias: you test what the code does, not what it should do)
  • Won't catch a correct implementation of a wrong requirement
  • Time-intensive to achieve high coverage

Grey-box testing

In practice, most QA automation engineers operate in the grey zone — they know some internals but test from the user perspective.

Grey-box testing means:

  • You know the architecture (REST API, database, frontend) but test the external behavior
  • You can read basic code to understand test data setup but don't write unit tests
  • You use API-level testing (knowing the endpoint structure) to support UI-level testing
  • You look at code to understand edge cases but design tests from the user's point of view

This is where most modern QA engineers live. You're not purely black-box (you know the tech stack) and not purely white-box (you're not writing unit tests testing internal functions).

Side-by-side comparison

| | Black-Box | White-Box | Grey-Box |

|-|-----------|-----------|----------|

| Knowledge needed | Requirements only | Full code access | Architecture + some code |

| Tests based on | Specifications, user flows | Code logic, coverage | Both |

| Who does it | QA testers, users | Developers, QA engineers | QA automation engineers |

| Catches | Requirement mismatches, UI bugs | Logic bugs, uncovered code | Both categories |

| Misses | Internal logic bugs | Wrong requirements | (minimized) |

| Example | Login form testing | Unit tests for auth logic | API testing + E2E |

What this looks like in a real project

Day 1 — Feature arrives: You get user stories and acceptance criteria. You write test scenarios based on these (black-box: no code yet). Development phase: Developers write unit tests covering the code paths (white-box). Testing phase: You execute your test scenarios against the built feature (black-box). You also call the API directly to set up test data (grey-box — you know the endpoint structure). Bug found: You look at the code to understand why the edge case happens (white-box knowledge) but file the bug against the behavior, not the implementation (black-box report). Coverage review: You check which areas have no automated tests and flag them for the team (white-box perspective applied to planning).

All three modes on the same feature, in the same sprint.

In QA interviews

Classic question: "Explain black-box vs. white-box testing."

The expected answer:

  • Black-box: test without knowledge of internals, based on requirements and user behavior
  • White-box: test with knowledge of the code, based on coverage of logic paths
  • Grey-box (optional): both — typical for automation engineers who know the architecture but test from a user perspective
Follow-up question: "Which one do you do?"

Honest answer for most QA automation engineers: primarily black-box (E2E testing of visible behavior) with grey-box elements (API knowledge, reading code to understand test data setup, reviewing coverage reports).

Key takeaway

The distinction isn't about which is better — they're complementary. Black-box testing ensures the system does what users and requirements expect. White-box testing ensures the implementation is complete, well-structured, and tested thoroughly.

In a mature QA setup, both happen: developers write white-box unit tests, QA engineers write black-box E2E tests, and the combination gives you much stronger coverage than either alone.

→ See also: The Test Pyramid Explained for QA Engineers | Verification vs. Validation in Software Testing: What's the Difference? | Exploratory Testing: The Skill AI Cannot Replace