Beginner-Friendly Topic
Take your time - it's perfectly normal to re-read this topic 2-3 times. Try the interactive code editor below to run code yourself. Use the Q&A section to check your understanding before moving on. You've got this! 🚀
Black-Box vs White-Box vs Grey-Box Testing
Black-box, white-box, and grey-box testing are the three fundamental perspectives from which software can be tested. Each requires a different level of system knowledge, targets different types of defects, and is performed by different roles. As an SDET, you will regularly apply all three.
The Three Testing Perspectives
- Black-Box Testing: Test WITHOUT knowledge of internal code. Tester only knows inputs and expected outputs. Focuses on WHAT the system does. Used in functional, acceptance, and UI testing.
- White-Box Testing: Test WITH full knowledge of internal code. Tester examines branches, conditions, and code paths. Focuses on HOW the system does it. Used in unit testing and code coverage.
- Grey-Box Testing: Partial knowledge of internals. Tester knows architecture, APIs, and data models but not low-level code. Used in integration testing and API testing.
All Three Testing Perspectives in Code
// The system under test: a password validator
function validatePassword(password) {
if (password.length < 8) return false;
if (!/[A-Z]/.test(password)) return false;
if (!/[0-9]/.test(password)) return false;
if (!/[!@#$%]/.test(password)) return false;
return true;
}
// ══════════════════════════════════════════════════════════════
// BLACK-BOX TESTS (tester doesn't know the rules above)
// Derives tests from the SPECIFICATION: "Must be secure password"
// ══════════════════════════════════════════════════════════════
// Spec says: "password must be at least 8 chars with special chars"
test("BB: valid password is accepted", () => {
expect(validatePassword("Secure1!")).toBe(true);
});
test("BB: short password is rejected", () => {
expect(validatePassword("Ab1!")).toBe(false);
});
test("BB: all lowercase is rejected", () => {
expect(validatePassword("password1!")).toBe(false);
});
// ══════════════════════════════════════════════════════════════
// WHITE-BOX TESTS (tester reads the code, targets each branch)
// Must achieve 100% branch coverage of the 4 if-statements
// ══════════════════════════════════════════════════════════════
test("WB: triggers length < 8 branch", () => {
expect(validatePassword("Aa1!xyz")).toBe(false); // 7 chars
});
test("WB: triggers no uppercase branch", () => {
expect(validatePassword("secure1!abc")).toBe(false);
});
test("WB: triggers no digit branch", () => {
expect(validatePassword("Secure!!abc")).toBe(false);
});
test("WB: triggers no special char branch", () => {
expect(validatePassword("Secure123abc")).toBe(false);
});
test("WB: all branches pass - returns true", () => {
expect(validatePassword("Secure123!")).toBe(true);
});
// ══════════════════════════════════════════════════════════════
// GREY-BOX TESTS (tester knows the API + data format, not code)
// Tests the /register endpoint knowing password goes through
// validatePassword() internally
// ══════════════════════════════════════════════════════════════
test("GB: registration with weak password returns 400 and reason", async () => {
const res = await post("/register", { email: "a@b.com", password: "weak" });
expect(res.status).toBe(400);
expect(res.body.error).toContain("password"); // knows API format
});Common Mistakes
- Pure black-box testing missing internal edge cases - without code visibility, testers miss specific branch conditions that only white-box testing reveals.
- White-box testing replacing functional testing - 100% branch coverage does not mean 100% correct behavior. You need both.
- SDETs only doing one type - real-world SDETs need all three perspectives; black-box for user-facing behavior, white-box for unit coverage, grey-box for API contracts.
- Using white-box techniques for acceptance testing - acceptance testing must be black-box; testing implementation details makes tests brittle to refactoring.
Tip
Tip
Practice BlackBox vs WhiteBox vs GreyBox Testing in small, isolated examples before integrating into larger projects. Breaking concepts into small experiments builds genuine understanding faster than reading alone.
Every element follows the box model - content + padding + border + margin
Practice Task
Note
Practice Task - (1) Write a working example of BlackBox vs WhiteBox vs GreyBox Testing from scratch without looking at notes. (2) Modify it to handle an edge case (empty input, null value, or error state). (3) Share your solution in the Priygop community for feedback.
Quick Quiz
Common Mistake
Warning
A common mistake with BlackBox vs WhiteBox vs GreyBox Testing is skipping edge case testing - empty inputs, null values, and unexpected data types. Always validate boundary conditions to write robust, production-ready software testing code.
Key Takeaways
- Black-box, white-box, and grey-box testing are the three fundamental perspectives from which software can be tested.
- Black-Box Testing: Test WITHOUT knowledge of internal code. Tester only knows inputs and expected outputs. Focuses on WHAT the system does. Used in functional, acceptance, and UI testing.
- White-Box Testing: Test WITH full knowledge of internal code. Tester examines branches, conditions, and code paths. Focuses on HOW the system does it. Used in unit testing and code coverage.
- Grey-Box Testing: Partial knowledge of internals. Tester knows architecture, APIs, and data models but not low-level code. Used in integration testing and API testing.