What is a potential drawback of white-box testing?

• A. It is expensive
• B. It may miss unimplemented parts of the specification or missing requirements
• C. It cannot detect security vulnerabilities
• D. It requires production data

Answer: (B)

White-box testing focuses on the internal structure of the code—its paths, branches, and data flows—using knowledge of how the program is built. The main benefit is you can verify that the implemented logic works correctly and that every path is exercised. The reason this option is the best answer is that a key drawback of this approach is its tendency to overlook parts of the requirements or specification that haven’t been implemented yet. Since you’re testing what exists and how it’s built, you may miss gaps in what the system is supposed to do, or issues arising from unmet requirements, leaving those areas unchecked.

Other options aren’t describing this fundamental limitation as accurately. While white-box testing can be resource-intensive in some cases, cost is not the defining drawback. It can indeed help uncover security-related issues by inspecting code, so saying it cannot detect vulnerabilities isn’t correct. And testing often uses non-production data; requiring production data is not an inherent drawback of white-box testing.