Black box testing checks software using only its inputs and outputs, with no view of the source code. White box testing gives the tester full implementation access, so cases get built around the code's own branches and logic. Grey box testing is not a compromise sitting between the two; it is a third position, deliberate partial access, useful in its own right. All three describe what a person was permitted to look at, not a property of the system under test.
Most teams never sit down and choose a testing methodology. A five-person engineering team with no dedicated QA function picks one by accident, every single day, based on whatever document happens to be open. A support ticket becomes a black box check because nobody has the diff up. A code review becomes a white box check because the diff is already on screen. Nobody debates it. The label just gets applied afterward, matched to whichever textbook chapter fits what already happened.
That's the useful way to read the split that follows: not as a methodology to select, but as a description of access that already exists on your team, whether anyone named it or not. Once you can say which document produced a given check, you can also see which checks never got produced, because nobody with the right access ever looked.
Black box vs white box vs grey box testing: the row everyone drops
Most write-ups compare two columns and mention grey box testing in a closing sentence, if at all. Here is the full comparison, self-contained, with the row that usually gets dropped left in.
| Technique | What you can see | Who traditionally performs it | What it detects well | What it structurally cannot detect |
|---|---|---|---|---|
| Black box | Inputs and outputs only | QA testers, end users, auditors | Spec violations, usability gaps | Internal logic errors with no visible symptom |
| White box | Full source, logic, data flow | Developers, unit test authors | Logic errors, dead code, edge cases | Requirements never written into the code |
| Grey box | Partial structure: APIs, schemas, logs | Integration testers, security analysts, SREs | Cross-boundary, state-dependent defects | Line-level logic inside an unopened component |
Notice what the last column is really tracking. It isn't a ranking of thoroughness, it's a boundary drawn by access. A black box tester structurally cannot see a logic error that never surfaces in output. A white box tester structurally cannot see a requirement nobody implemented, because there's no line of code to inspect for a scenario that was never written. A grey box tester sees the seam between two systems clearly and the inside of either one barely at all. Each blind spot is the direct, mechanical consequence of what the technique withholds, not a gap in effort. This is not only our framing. The federal security glossary defines all three purely by degree of access: black box testing assumes no knowledge of the internal structure, grey box some knowledge, and white box explicit and substantial knowledge. Not one of the three definitions mentions technique, tooling, or skill. That same access-based framing is the right lens for judging a testing agent like Autonoma: the question isn't how advanced the tooling is, it's which document it actually read before it made a claim.
One defect, two chapters
Here's a defect that makes the point concrete instead of categorical. The spec says orders of $100 or more get 10% off. The implementation uses if (subtotal > DISCOUNT_THRESHOLD), with DISCOUNT_THRESHOLD set to 100. One character, > instead of >=, and an order of exactly $100 gets nothing.
Run the black box suite first, boundary values pulled straight from the spec, no source in view. An order of $99 returns $99, unchanged, correct. An order of $101 returns $90.90, the 10% cut applied, correct. An order of exactly $100 returns $100. The spec says $100 or more qualifies. It failed.
Run the white box suite next, tester with the source open. The literal > and the constant 100 are sitting right there in the file, so the boundary picked for the test is the same $100. Got $100, wanted $90. Failed.
Feed the same code a naive branch-coverage pass, one order above the threshold and one below, and it tells a different story. $150 charges $135, above the threshold, that branch executes. $50 charges $50, below the threshold, the other branch executes. Both branches ran. The suite reports green. The bug never got asked about, so it survives untouched.
Change the operator from > to >= and rerun everything. All six checks pass.
That's the whole argument in one example. The only thing that differed between the two testers was which document each one was permitted to read. An automated agent like Autonoma that only ever read one of those two documents would inherit the same blind spot a single human tester has. Catching this exact class of bug needs both open at once: the code and the behavior it produces.
Why the black box and white box split is really about permissions
The vocabulary here is older than automated testing itself. It comes from a period when a QA department, a development team, and a security function sat in three separate rooms, and a job title told you exactly what you were and weren't allowed to open. A tester never got a copy of the source, so their work got called black box testing, a description of what they were permitted to see, not a claim about method. A developer worked from nothing but the source until the build shipped, so their work got called white box testing, again a label for what document sat on their desk. Grey box testing came later, for the specific person handed just enough, an API contract, a schema, a log format, to test the seam between two systems they didn't own end to end.
None of those three roles describes what happens when the thing running the check isn't a person with a badge, but a system that reads a repository and also drives a live interface, because the taxonomy was built to describe rooms and job titles, not that combination of capabilities. Grey box testing was always the closest existing label, and it was pointing at something better: access constructed on purpose, rather than inherited from whichever role you happened to hold.
How Autonoma sits across the boundary
This is where the permissions framing actually earns its keep, and where a benchmark framing would mislead. State it as architecture, not as a score against black box or white box testing: our Planner agent reads a codebase directly, the routes, components, and flows that actually exist in the source, to decide what a test should cover. That's a white box input, since nothing about it is guessed from a requirements document. The Executor agent then verifies by driving the actual running application inside a live preview environment, checking what happens on screen rather than inspecting an internal variable. That's a black box execution model. Put those two steps together and the result isn't a system doing two jobs on two sides of the table, it's one pipeline that removes the reason the split existed in the first place, because nobody had to be assigned a room.
Said plainly, so the boundary stays honest rather than aspirational: this is not unit-level white box testing. Our agents don't step through a function line by line confirming an intermediate calculation, and they don't stand in for a developer's own unit tests. What they cover is the behavioral layer, an executed flow, checked against what the running application actually does, with a Diffs Agent maintaining those flows as the code underneath them changes. That's closer to grey box testing in the deliberate-construction sense than to either pole of the original taxonomy, and it deserves fuller architectural treatment than a comparison article can give it.
Which one you are being asked about: black box or white box testing
When an interview question or an audit asks whether you do black box or white box testing, it's usually asking something narrower than the phrasing suggests: which document did you have open when you wrote the check. If the honest answer is a requirements doc or a support ticket and nothing else, that's black box testing, plainly. If the honest answer is a diff, a function, or a code review, that's white box testing. If the honest answer is a schema, an API contract, or a log line, something short of full source but well past the outside, that's the grey box case, and it deserves naming as its own thing.
Here's what that looks like in practice. An interviewer asks how you'd test a new checkout discount. If the answer starts from the ticket, boundary values around the stated threshold, unusual currency formats, a coupon-stacking edge case, that's black box testing, and it's a complete answer on its own. If the answer starts from the diff, tracing the conditional that computes the discount and checking whether every branch has a test, that's white box testing, equally valid, answering a different question. The strongest answer names both explicitly, then adds the grey box layer where it applies: if the discount also depends on an inventory service behind an API boundary nobody on the team owns, testing that seam from the contract rather than the full source of either side is a deliberate choice, not a fallback for lacking access.
An audit asks a version of the same question with money attached. A reviewer checking whether payment logic is tested wants to know which document the suite was built from, because that answer determines what the suite could possibly have caught. A suite built entirely from a requirements document and never once from the code has a specific, nameable blind spot: any logic error that happens to produce plausible output for every input someone thought to try. Naming that blind spot out loud, instead of letting a green suite imply full coverage, is what turns an audit answer into a fact instead of a guess.
The exact coverage-criteria arithmetic that decides how thorough a white box suite actually is deserves a full article of its own, and the fuller case for building grey-box access on purpose rather than inheriting it already has one.
Whichever label ends up on the ticket, the more durable habit is naming the access, not the noun: which document, or which running interface, did the check actually depend on. Build that habit manually first, on your own suite, before delegating any of it. Once it's a habit, deciding where a tool like Autonoma sits relative to that table stops being philosophical and turns into a straightforward audit of what the agent actually reads versus what it actually runs.
Frequently Asked Questions
Black box testing checks software using only its inputs and outputs, with no access to the source code. The person or system running the check knows what the software is supposed to do, from a spec, a requirement, or a support ticket, but not how it does it internally. Test cases get derived from expected behavior alone, never from reading the implementation.
The difference is implementation access, not skill level or rigor. Black box testing derives test cases from expected inputs and outputs with no view of the source. White box testing derives test cases from the code itself, its branches, conditions, and internal logic. Both can find the exact same bug from opposite directions, the way a black box tester finds a discount-threshold bug because the spec states a boundary, while a white box tester finds the same bug because the comparison operator is visible in the source.
Neither is categorically better, because each is blind to a different class of defect. Black box testing structurally cannot see a logic error that happens to produce correct-looking output for every case a person thought to try. White box testing structurally cannot see a requirement that was never written into the code at all, since there's no line to inspect for a scenario nobody implemented. A serious test strategy uses both, at different layers, rather than choosing a winner.
White box testing gives the tester full access to the implementation, so test cases get built around the code's own structure: its branches, conditions, loops, and data flow. It is also called clear box, glass box, or structural testing. Because the source is visible, a white box tester can target a specific line or operator directly, which is why a boundary error in a single comparison operator is straightforward to find this way and invisible to a suite built from a requirements document alone.
Grey box testing gives the tester deliberate partial access, an API contract, a database schema, a log format, without the full source and without being limited to pure inputs and outputs. It is not a midpoint compromise between black box and white box testing; it is a third position, particularly useful at integration boundaries and in security testing, where full source access wouldn't even answer the question being asked.
No. Black box testing is defined by what access you don't have, not by what you know. Someone with no coding background can run a rigorous black box suite from a spec or a set of requirements alone, and plenty of professional QA testers do exactly that. Coding knowledge becomes necessary the moment a technique requires reading or writing to the source itself, which is the white box side of the line.
Autonoma is built to work across both sides of that line at once, on purpose. Our Planner agent reads your source to decide what to test, a white box input, then our Executor agent proves it by driving the running application in a live preview environment and checking what actually appears on screen, a black box execution model. No assertion is made by inspecting an internal variable, so it doesn't replace a developer's own unit tests, but it does mean end-to-end coverage doesn't have to wait on someone hand-writing a spec or a test plan first. Autonoma reads what you built, then verifies it the way a real user would.
