Quality needs two perspectives on time
Shift-left and shift-right describe when we obtain evidence about quality. The former brings questions and checks into requirements, design and development. The latter examines actual service behaviour after deployment. My proposed approach connects them through feedback between expectations and observed outcomes. It does not move every test to one side of a delivery timeline or assume one perspective can establish everything.
An early discussion can uncover an ambiguous rule before several components implement incompatible interpretations. Production observation can reveal dependencies or volumes absent from the test environment. Each kind of evidence has a boundary. A passing test does not establish correctness for every real input, while an uneventful hour does not establish readiness for monthly closing. I would describe the behaviour verified rather than simply report that testing is complete.
Documented case: Cloudflare's global network, July 2019
Cloudflare's own analysis, published on 12 July 2019, describes the global outage of 2 July. A web application firewall rule exhausted CPU resources through excessive regular-expression processing. The company identified missing performance checks and global deployment without staged rollout among the contributing weaknesses. [1] This is a documented external event, not a project I participated in or a fictional banking scenario.
My inference is that preventive checks need to connect with deployment scope and production detection. A fast alert cannot reverse damage already caused, while preproduction checks cannot anticipate every operating condition. The relevant questions concern resource consumption, rollout, access to controls and the ability to stop the change. The case supports investigating these dimensions without establishing a universal rollout recipe for every organisation.
Hypothetical example: repayment notifications
Imagine a fictional bank changing its repayment notification rule. A message should now be generated three working days before the due date. During requirements work, I would ask about public holidays, time zones, amended due dates and repeated batch runs. Leaving these questions until final testing risks allowing different teams to implement different meanings of the same short sentence.
Production uncertainty is different. A correctly generated message might wait at a supplier or be sent twice after a retry. Alongside calculation tests, I would propose tracking unique messages, waiting time and evidence of handover. These are illustrative controls for a hypothetical bank. The service owner would need to agree appropriate boundaries based on customer needs and operational capabilities rather than borrow an arbitrary threshold from another system.
Check meaning before implementation
I would begin with concrete examples. For a given due date, responsible stakeholders would specify the expected generation date under different calendar conditions. The examples serve more than future automation: they expose disagreements about the rule itself. If a business owner and developer expect different results, the team needs a decision about intended behaviour before it needs faster implementation.
I would also define system responsibilities. Which component determines timing, which creates content and which performs delivery? Does “sent” mean accepted by a provider or delivered to the customer? Those are potentially different events. Precise terminology affects test assertions, support screens and monitoring. Without it, several teams can each report success while the overall customer journey remains incomplete or impossible to reconstruct.
Design tests around consequential paths
I would derive the test set from failure scenarios and boundaries rather than screens alone. The fictional notification service needs a normal path, missing information, a changed due date and repeated processing. For retries, the important question is whether one business event produces a second message. Automation can repeatedly verify a stable expectation, but it cannot decide what that expectation should be.
Operational assumptions deserve their own checks. A month-end run might process substantially more records than an ordinary day. I would ask how the test volume was derived and which dependencies it represents. Real customer data should not be copied simply to make a test look realistic. Representativeness depends on relevant properties and relationships, together with controlled access and appropriate protection of information.
Observe outcomes after release
For the fictional service, I would connect technical availability with a business outcome. A running process does not show that every expected notification exists. I would compare expected events with uniquely handed-over messages, accounting for understood exceptions. I would also monitor the age of waiting records. A small queue can be serious when its remaining messages have already missed the useful notification window.
Every alert needs an owner and response. Otherwise monitoring produces information without an operational decision. Support must distinguish supplier delay from an incorrect calculation because indiscriminate retries can create duplicates. Google SRE's monitoring material offers further reading on service signals. [2] Its general ideas would still need translation into the particular customer journey, operating cycle and responsibilities of the bank being assessed.
Limit exposure and preserve intervention
Where architecture permits, I would propose staged rollout with agreed stopping conditions. A small cohort must nevertheless include relevant variation, such as different calendars or older contracts. A handful of simple cases can miss the path most challenged by the change. Limiting exposure and choosing a representative cohort are related decisions; neither alone establishes that expansion is safe.
I would also check how intervention remains possible during failure. If the control tool depends on the same failing service, the recovery plan may be theoretical. The team needs available permissions, a practised route and a clear decision point. Emergency access should remain controlled. The purpose is an authorised, tested way to act under disruption rather than a permanent weakening of normal protections.
Feed production learning back into design
Suppose actual operation reveals unexpected duplicate notifications. I would add the demonstrated mechanism to requirements examples and regression checks. I would also ask whether other message types share the same assumption. Feedback should improve future decisions rather than merely close the incident. Preserving the mechanism is more useful than preserving only the identifier of the record where someone happened to notice it.
The team should assess the new safeguard after adoption. Does it catch the demonstrated problem, and does it create excessive false alarms? If a check blocks unrelated changes, it may need a narrower trigger. If it misses another occurrence, the original assumption may have been wrong. Learning therefore includes simplifying ineffective controls as well as adding safeguards justified by evidence.
Summary and recommendations
I recommend beginning with verifiable examples, connecting them to tests and adding production signals for actual outcomes. Significant uncertainties need owners and proportionate safeguards. Shift-left reduces the problems carried into implementation; shift-right examines assumptions under real conditions. Their combined value lies in a working feedback loop that updates requirements, tests and operating responses as evidence changes, while making the limits of confidence explicit.