Testing and quality foundations · Lesson 3

Where can a fault be found with the least ambiguity?

5 min read

Lesson objectives

Distinguish what a requirements review can find from what needs component or interface execution.
Allocate evidence across suitable test levels and state their blind spots.

Some problems can be found before a line of code runs. If a requirement says ‘an appointment may be cancelled until the previous day’ without defining the cutoff hour or time zone, reviewing the wording with the person who owns the need can expose the ambiguity immediately. That is static testing: examining a work product such as a requirement, design or code without executing the product. Dynamic testing runs an implementation with an input and observes its behavior. ‘Static’ does not mean unimportant, and execution alone cannot always reveal the source of a problem. If the team has not agreed what ‘previous day’ means, competing tests may each look reasonable. Good tests first establish the reference against which behavior is judged.

Case

Assume an agreed rule: a 15:00 appointment may be cancelled only when the request arrives before 15:00 on the previous day in the clinic's time zone. Requests exactly at 15:00 or later are refused. In a trial implementation, `cancelAllowed(requestTime, appointmentTime)` compares the two values after converting them to one reference instant. A component check probes 14:59:59 and 15:00:00 around the cutoff. An integration check of the booking service asks whether the interface passes the correct zone to that function. A system check follows the user's path from selecting Cancel to the appointment state and message. An acceptance check asks a representative of the need whether ‘before the cutoff’ reflects the intended policy. Each level answers a different question; a passing function does not establish that the page sent the right zone.

Early testing is not running every case early. It is placing a question where it can be answered clearly and economically. The meaning of ‘previous day’ belongs in a requirements review. An erroneous `<` versus `<=` comparison can be isolated in a component test at the boundary. A lost time-zone offset between interface and service needs an integration check. A Cancel control absent from the page despite a permissive service needs a system check. A system test may detect any of these symptoms, but diagnosing the cause can take longer because many layers participate. Start with precise checks and then add evidence that connects the layers. A large collection of end-to-end tests cannot prove an unobserved component or contract is correct.

Static and dynamic work also complement each other after a real failure. If the service accepts cancellation at exactly 15:00, compare behavior with the agreed rule first. If the rule says ‘before’, this is a repeatable mismatch. Then investigate whether comparison logic, time conversion or another interface path caused it; a single screen cannot prove root cause. If the rule was never settled, record a requirements question before accusing the developer of violating it. A quality report connects each judgment to an approved rule, input, expected result, actual result and remaining uncertainty. That prevents a release decision from resting on many tests of the wrong rule.

Exercise

Exercise 1: The first draft says ‘the user may cancel an appointment on the previous day’. Two appointments are on 20 June, at 09:00 and 18:00. In review, a product representative proposes a cutoff at the start of 19 June; support proposes a 24-hour cutoff before each appointment. Produce a review log with a justified decision: ambiguous phrase, two decisive questions, two examples that distinguish the proposals, and the provisional decision about executing tests before the rule is settled. Estimated work: 20 minutes.

Check your answer

Exercise 1 solution: The inputs are two 20 June appointments and two interpretations of ‘previous day’. The uncertainty concerns the hour of cutoff, not the appointment date alone. Ask whether cancellation ends at the start of 19 June or exactly 24 hours before each appointment; also ask which time zone and whether the exact instant is included. A request on 19 June at 08:00 for the 20 June 09:00 appointment is rejected by the midnight rule but accepted by the 24-hour rule. A request on 19 June at 17:00 for the 20 June 18:00 appointment has the same disagreement. Do not assign a decisive expected result to those cases before the requirement owner chooses a rule; record both candidates, then test the selected boundaries. A sound answer shows the divergent outcome and time-zone limit rather than picking a rule without authority.

Exercise

Exercise 2: An agreed rule permits cancellation before 15:00 on the preceding day in the clinic's zone and rejects it exactly at 15:00. A trial build gives these results: the function accepts 14:59:59 and accepts 15:00:00; an interface request at 14:59:59 is rejected even though the function accepts that supplied time in isolation. Produce a test-level map with a justified decision: component, integration and system checks; what the results prove and cannot prove. Add a two-step diagnosis plan without naming an unverified root cause. Estimated work: 20 minutes.

Check your answer

Exercise 2 solution: Function acceptance at 14:59:59 conforms. Acceptance at 15:00:00 does not, because the cutoff instant is excluded. That is a component failure under a clear input. Interface rejection at 14:59:59 also contradicts the rule but does not establish one particular cause: a different value or offset may have arrived, or another layer may have refused the request. Record the whole-path failure. First capture request time, appointment time and both offsets at service entry and compare them with the original input. Second repeat function and interface calls with the same recorded values in a fixed environment to locate the divergence. One passing component case does not certify interface integration. A complete answer identifies boundary inclusivity, every observed outcome, evidence location and bounded diagnosis.

Lesson summary

Distinguish what a requirements review can find from what needs component or interface execution. Allocate evidence across suitable test levels and state their blind spots.

Report an error in this lesson

Lesson objectives

Lesson summary

Share this page