skip to content

A defect reproduces only against the real customer value behind a test token - how do you grant that access?

level: seniorimportance: nice to knowfreq 24%

answer

  1. Ask whether identity or shape matters
  2. Rebuild the row instead
  3. An out-of-band request, not a capability
  4. One value, one reason, one record

basics

~20 s

Rarely, and never as a standing capability. Establish first that the record's shape cannot be manufactured, then resolve one value under a separate owner's approval, record who asked and why, and keep the resolved value out of the dataset.

solid answer

~50 s

Start by doubting the premise. A defect is produced by the shape of a record — field length, character classes, nulls, relationships, age — not by the identity behind it, so the first job is to find which attribute matters and manufacture a row that carries it. That yields a permanent regression case, which a resolution never does. The genuine exceptions are narrow: comparing a transformed extract against a real upstream total, confirming which real accounts an incident touched, or a regulated confirmation about one individual. Arrange those as an out-of-band request rather than a capability of the test estate: state what was tried first, have a different owner approve, resolve exactly one value rather than a range, record requester and reason, and let the access expire. The resolved value then leaves with the investigation — never written back into the dataset or into what a run captured.

code

pseudocode · 17 lines
pseudocode
request = {
    requester:  "engineer-id",
    value:      "STANDIN-8842",          # exactly one, never a range
    reason:     "defect-1174 reproduces only against this record",
    tried_first: "manufactured row with the same field lengths, "
                 "null pattern and relationships - did not reproduce"
}

approval = separate_owner.review(request)      # not the requesting team

if approval.granted:
    original = mapping_store.resolve(request.value)
    audit.record(request, approval, expires_in = HOURS)
    # original goes to the investigation only:
    #   not into the dataset, not into the defect record,
    #   not into anything the run captures
    close_out(convert_finding_into_manufactured_row())

go deeper

for a junior

Be ready to say that you do not look up the real person behind test data on your own initiative, and that a defect which reproduces for one record is usually about the shape of that record rather than who it belongs to.

for a middle

Explain the first move: work out which attribute of the record drives the failure and manufacture a row carrying it. Know that resolving a value back to a real person is an approved exception with a record, not something a test job does.

for a senior

Demonstrate the judgement. Name the narrow set of workflows that genuinely need the original, design the request path around a separate approver and a single value, and show how each exception is converted into a permanent manufactured case.

for a principal

Own the policy: how much friction an exception should carry, who approves it, and how the organisation notices when the exception has become routine. Decide whether the workflows that drive resolutions should be redesigned out instead.

## Most reproductions do not need the real person The instinct, when a defect will not reproduce, is to reach for the real record. It is almost always the wrong first move, and it is worth being precise about why. A defect is produced by the *shape* of data — a name containing a character the parser mishandles, an address with no postal code, a balance that went negative at the wrong moment, a history long enough to trip a pagination boundary. It is not produced by the identity behind that shape. If a reproduction only works against one real record, the useful question is which attribute of that record matters, not who the person is. So the first response to "it only reproduces for this one customer" is an investigation of the record's shape, conducted against the transformed copy: the field lengths, the character classes, the null pattern, the relationships to other rows, the ordering, the age of the record. Nearly always one of those is the trigger, and the outcome is far better than a resolution would have been — a manufactured row that reproduces the defect, which can be checked into the suite as a permanent regression case. Reaching for the original produces a fix and no test. ## The narrow set that genuinely needs it A short list survives that reasoning, and honest teams can name every item on it: - **A comparison against a real external figure.** Confirming that a transformed extract still totals to what an upstream system reports may require establishing that particular rows correspond, and no manufactured row can stand in for that. - **Confirming who an incident touched.** When a reproduction implicates specific rows and the organisation must know which real accounts those are, that is an operational obligation, not a testing one, and it is the strongest case for a resolution. - **A regulated confirmation.** Some obligations require demonstrating that a specific individual's data was handled a specific way, and a stand-in cannot carry that demonstration. - **Proving the transformation itself is correct.** Verifying that a field really was replaced, or that two records that should be distinct did not collapse onto one value, needs a comparison against source values — and this one is better solved by an automated check inside the transformation pipeline than by any human request. Notice what is missing: "the bug is urgent", "the manufactured row is fiddly to build" and "we always did it this way" are none of them on the list. ## Designing the path so it is not the ordinary one The difference between a defensible arrangement and a fiction is whether resolution is a **capability** of the estate or a **request** against it. | | Standing capability | Requested resolution | |---|---|---| | Who can resolve | Anyone holding estate credentials | A named requester, per request | | Scope | Whatever the caller asks for | One value, stated in advance | | Evidence | None, or logs nobody reads | A record of requester, reason, value | | Lifetime | Permanent | Expires with the investigation | | What a breach yields | The whole mapping | Whatever was already resolved | Concretely, five properties make the path exceptional rather than ordinary: 1. **Something is tried first.** The request states what was attempted with a manufactured row and why it did not reproduce. This alone removes most requests. 2. **A different owner approves.** Not the requesting team. The approval is what makes the exception an exception. 3. **One value, not a range.** A range is an export, and an export puts a slice of the mapping back inside the estate for good. 4. **The resolution is recorded.** Requester, reason, value, approver, time. If nobody can count the resolutions, nobody can tell whether the arrangement is still exceptional. 5. **It expires.** The access ends with the investigation rather than accumulating as a standing grant nobody revisits. ## What happens to the answer afterwards A resolved real value is production data in a hostile place: on a laptop, in an investigation, next to a defect record. It must leave with the investigation. Do not write it back into the dataset, do not paste it into the defect's description or a chat thread, and do not leave it in whatever the run captured. A real value copied into a test artefact has created a second route back that nobody governs and nobody will remember to delete — which is exactly the outcome the transformed copy existed to prevent. The best long-term outcome of a resolution is that it produces a manufactured row. Once you know which attribute mattered, encode it as a permanent case in the dataset, so the next occurrence of that defect class reproduces without anyone needing to ask again. A team whose resolution count falls year on year is not one that has become less careful; it is one that has been converting each exception into a fixture that no longer needs the exception.

  • How do you tell a genuine need for the original from an unwillingness to reproduce the defect properly?
    Ask what the original value would let you do that the record's attributes would not. Usually the honest answer is 'confirm which customer', which is an operational question rather than a testing one. A genuine need names a comparison against a real external figure or a regulated confirmation; everything else is a manufactured row and a bit more effort.
  • What happens to the resolved value once the investigation ends?
    It leaves with the investigation. Not written back into the dataset, not pasted into the defect record or a chat thread, not left in what the run captured. A real value copied into a test artefact is a second route back that nobody governs and nobody remembers to delete, which defeats the transformation entirely.
  • What is the best outcome of an approved resolution?
    A manufactured row that reproduces the defect without it. Once you know which attribute mattered, encode it as a permanent case in the dataset so the next occurrence of that defect class needs no request at all. A resolution count that falls year on year usually means exceptions are being converted into fixtures.

saying these in an interview costs you the question

  • Gives the whole team a standing ability to resolve any value
  • Exports a range of mappings in order to investigate one defect
  • Pastes the resolved real value into the defect record
  • Assumes a defect that reproduces once needs the real identity
  • Treats an approval and a recorded reason as unnecessary friction