White box testing
White box testing is a software testing approach in which the tester designs test cases from the internal structure of the code, such as its statements, branches and paths, and judges them by how much of that structure they exercise. It is also called structural, glass box or clear box testing, and it is usually done by developers.
The longer version
The tester reads the code, or a model of it such as a control-flow graph, and chooses inputs that drive execution through particular parts. The question is not what the specification promises but what the implementation does: does every statement run, does every decision go both ways, does every loop run zero, one and many times. Coverage measures such as statement coverage and branch coverage turn those questions into numbers a team can track.
Black box testing sits at the opposite end. The tester sees only inputs and outputs and designs cases from the requirements, with techniques such as equivalence partitioning. Grey box testing is the middle position, where the tester knows something of the internals, such as the database schema or the API contract, without working from the source line by line. The three describe how much of the system is visible when the test is designed, and a real test effort uses all of them.
Unit tests are the common home of white box work, written by the developer who knows the branches. Coverage tooling in the build then reports which lines the suite never reached, and those gaps become the next tests to write. Reading the code without running it is a separate activity, static testing, and the two complement each other.
A suite built this way can only test what the code does. A requirement that was never implemented has no statement to cover, so full structural coverage still passes while a whole feature is missing. Tests written against the internal structure are also coupled to it, and a refactor that keeps behaviour identical can break those that reach into the old implementation.
Common questions
What is white box testing in simple terms?
Testing with the code open. The tester looks at how the software is built and writes cases to make specific statements, branches and paths run, then checks that each behaves correctly. The aim is to prove that the structure itself works, not only that the visible result looks right.
What is the difference between white box and black box testing?
White box testing designs cases from the internal structure of the code and measures coverage of that structure. Black box testing designs cases from the requirements and observes only inputs and outputs, with no knowledge of the implementation. Each finds defects the other tends to miss, so they are used together.
What techniques are used in white box testing?
Statement coverage, branch (decision) coverage and path coverage form a chain in which each demands more of the tests than the last, and condition coverage is a separate criterion that looks inside compound decisions. Control-flow analysis is used to find the paths, and mutation testing is sometimes added to check whether the tests would notice a deliberate change in the code.
Who performs white box testing?
Developers do most of it, because it needs the source and a working knowledge of how it was written, and it usually takes the form of unit tests run in the build. Specialist testers with programming skills also do it, particularly for security review and for raising coverage on code nobody has tested.
Can white box testing find missing features?
Missing functionality is invisible to it, because tests are derived from code that exists. A requirement with no implementation leaves no statement or branch to cover, so coverage can read complete while a feature is absent. Black box techniques driven by the requirements are what catch the omission.
Bug reports that arrive ready to triage.
Collect replay, console, network and browser context with the Free plan.