Software Testing in Software Engineering: Black-Box, White-Box and Cyclomatic Complexity with a Worked Example

Software-testing terms are easy to memorise separately. The difficulty begins when one requirement must become partitions, boundary cases and control-flow paths without changing the expected result halfway through. So take one integer score classifier and hold it fixed. That single six-band rule becomes six equivalence partitions, 15 boundary values, a control-flow graph of cyclomatic complexity 6, a unit-to-acceptance ladder and a nine-input regression suite, with every expected output traceable back to the requirement that produced it.

Software testing fundamentals: error, fault, failure and the test oracle

Testing evaluates software or its artefacts against expectations. Finite passing tests cannot prove that no defect exists. A test oracle, such as a requirement, model or trusted calculation, supplies the expected result.

The rule says score 40 is PASS. Misunderstanding it is a human error; coding score <= 40 is the fault; 40 producing FAIL is the observed failure.

Verification asks, "Are we building to specification?" Validation asks, "Does the specified product meet the user's need?" Reviews and inspections are static; dynamic testing executes software. Either can reveal problems before a user-facing failure.

From a requirement to test cases: define the score classifier exactly

The requirement, R-CLASS-01, says classifyScore(score) accepts one integer and returns exactly one label:

• Below 0 or above 100 returns INVALID.

• 0 to 39 returns FAIL.

• 40 to 59 returns PASS.

• 60 to 79 returns MERIT.

• 80 to 100 returns DISTINCTION.

Real grading schemes vary. What matters for testing is that the bands are stated precisely, cover every integer and never overlap, because an untestable requirement produces untestable code.

A test case records test ID, requirement ID, precondition, input, action, expected output, actual output and status. TC-40 maps to R-CLASS-01, with precondition "classifier available", input 40, action classifyScore(40) and expected PASS. Actual and status await execution.

Most systems cannot be tested exhaustively. Equivalence partitioning and boundary analysis are requirement-based black-box techniques. Statement, branch and path coverage are structure-based white-box views. Neither is automatically better.

Black-box testing: equivalence partitions and boundary values

Equivalence partitioning groups inputs with expected common behaviour:

One representative covers a partition, not its boundaries. The full suite and oracle are:

-1 -> INVALID, 0 -> FAIL, 1 -> FAIL, 39 -> FAIL, 40 -> PASS, 41 -> PASS, 59 -> PASS, 60 -> MERIT, 61 -> MERIT, 79 -> MERIT, 80 -> DISTINCTION, 81 -> DISTINCTION, 99 -> DISTINCTION, 100 -> DISTINCTION, 101 -> INVALID.

The values 39, 40, 41 expose faulty score <= 40: only 40 disagrees. Black-box tests reveal wrong output, not its internal cause. If the rule never assigns 40, resolve the ambiguity rather than guess.

White-box testing: control flow and cyclomatic complexity

Now inspect this exact implementation shape:

classifyScore(score):
  if score < 0: return INVALID
  if score > 100: return INVALID
  if score < 40: return FAIL
  if score < 60: return PASS
  if score < 80: return MERIT
  return DISTINCTION

Five predicates give M = P + 1 = 5 + 1 = 6. Independently, 13 nodes and 17 edges give M = E - N + 2 = 17 - 13 + 2 = 6. This counts linearly independent paths in the connected graph, not defects or source lines.

The six basis-path inputs are: -1, first true branch, INVALID; 101, false then true, INVALID; 39, third predicate, FAIL; 59, fourth, PASS; 79, fifth, MERIT; and 80, all five false, DISTINCTION.

They cover both outcomes of every decision here. With loops or interacting decisions, branch coverage need not cover every complete path.

Levels of testing: place the same rule in a complete system

Testing levels describe scope, not the tester's job title:

For ResultPage -> ResultService -> classifyScore -> ResultRepository, top-down integration can stub ResultRepository; bottom-up can drive ResultService before the page exists. Big-bang integration joins many parts, complicating fault isolation.

Levels and techniques are separate. A unit test may be contract-facing or branch-facing. A specification-facing acceptance test still needs an oracle.

Retesting, regression and specialised testing

Defect B-17 makes 40 return FAIL because the third condition is score <= 40. After changing it to score < 40, retesting confirms 40 -> PASS. Regression reruns -1, 0, 39, 59, 60, 79, 80, 100, 101 to check neighbouring classes and invalid-input behaviour. Retesting targets the repair; regression checks for unintended effects elsewhere.

Smoke checks build health, sanity checks a narrow change, and regression gives broader change-safety evidence. Those three names describe intent and scope, not a fixed size: one team's smoke suite is 20 cases and another's is 200, and both are smoke suites.

Alpha testing uses a controlled pre-release setting; beta gives selected external users a release candidate under stated conditions. Performance testing needs the same precision the classifier needed. Written as "under 500 concurrent authenticated users, at least 950 of 1,000 result requests finish within 2.0 seconds", the requirement is testable: exactly 950 passes and 949 fails. Written as "the result page should be fast", it is not, and no load tooling will rescue it.

Common software testing traps and how the topic is examined

Questions on this topic run to a short list: classify verification against validation, pick the representative for a partition, decide whether 39/40 or 79/80 is the pair that catches an off-by-one, compute M from a graph, place a reported failure at the right testing level, or separate retesting from regression. Every one of those is answered by the classifier worked through above.

Traps include testing only 0, 40, 60, 80 and 100, missing just-outside values; counting if lines instead of graph flow; assuming 100 percent statement coverage includes false branches; trusting a wrong oracle; and asking automation to decide requirements.

KnowledgeGate's question bank carries over 170 Software Testing questions, enough to drill each of those shapes rather than read about them once. GATE CS Exam Preparation gathers the subject-wise resources, and the same requirement-to-worked-example method runs through Operating Systems for GATE: Deadlocks, Scheduling and Memory and DBMS Normalization Explained Simply for GATE.

Software testing in short: a revision chain and the next step

Revise this chain: requirement -> oracle -> partitions -> boundaries -> control flow -> testing level -> regression. The results are six partitions, 15 boundary values, five predicates, complexity 6 and six basis paths. Ask whether every input has a requirement-backed expected output.

Software engineering appears on some syllabuses and not others, so check your own paper's current official notification before you budget revision time on it. For GATE-focused study, GATE Guidance by Sanchit Sir sequences the subjects that are on the syllabus, and GATE Test Series gives timed practice against that scope.

Next, redraw both figures without looking back. Recompute all 15 boundary outcomes and then verify M = 6 using both formulas.