You have configured a new field mapping from a case repository into an issue tracker. How would you prove it works before the first real defect is filed through it?
answer
- the screen shows intent, not enforcement
- create one, then read it back
- aim it away from the live queue
- provoke the awkward values too
basics
~20 sCreate a throwaway item through the mapping into a destination nobody triages, then read it back. Only a real create exercises mandatory-field checks and list validation; the configuration screen shows your intent, not the tracker's rules.
solid answer
~50 sReading a mapping screen shows you your own intent. Only an actual create shows you what the tracker enforces — which fields it refuses to proceed without, which values its closed lists reject, and whether the item lands in the shape you expected. So file a throwaway item, and file it somewhere that is not the live queue people triage from, because test items in a real defect project pollute the counts read off it. Then read the item back rather than trusting the create call's success: confirm each mapped field arrived with the value you meant, that the back-link to the case resolves, and that the item is visible to the people who are supposed to work it. Repeat the exercise for the awkward cases too — a case whose value has no counterpart in the destination list, and one that leaves an optional field empty.
go deeper
Know that the only real check is creating an item and looking at it afterwards, and that a throwaway item should not be filed into the queue a team really works from.
Describe what a create exercises that a review cannot: mandatory-field enforcement, closed-list membership, writability at creation, and whether the intended readers can see the result.
Deliberately provoke the awkward inputs — an unmapped value, an empty optional field, an unattended run — and explain why a happy-path item mostly re-demonstrates your own assumptions.
Decide what verification is owed before an integration is switched on, who signs it off, and which changes on the tracker's side must trigger the same checks again.
## Why the configuration screen is not evidence A field mapping looks complete long before it is correct. What a configuration view shows is the set of associations you asserted; what matters is the set of rules the tracker applies when an item is actually created. Those diverge in ways nobody can read off a screen: - a field is **mandatory** on the destination item type and the mapping supplies nothing for it; - a value is offered that is not a **member** of the destination's closed list, so it is refused; - a field exists on the item type but is not writable at creation; - the account the integration uses cannot see or create in the destination at all; - the item is created successfully and lands somewhere the intended readers never look. Every one of those is invisible until something is created. The verification step is therefore not a review, it is a **create**. ## The shape of a useful dry run 1. **Pick a destination nobody triages.** A scratch project, or an item type the queue does not read. Throwaway items in a live defect project distort the counts people read off that queue, and someone will spend real time triaging your test. 2. **File one item through the real path**, using the integration exactly as it will run rather than by hand. 3. **Read the item back** instead of trusting that the create succeeded. A create can return success and still have dropped an unmapped optional field. 4. **Check each mapped field individually** against what you intended, including the back-link to the case that produced it. 5. **Confirm who can see it.** An item created into a place the intended readers cannot reach is a silent failure with the most misleading possible symptom: everything worked. ## The cases worth deliberately provoking A single happy-path item proves less than people assume, because the happy path is exactly the case you designed for. The runs that earn their keep are the awkward ones: - **A source value with no counterpart** in the destination list, to see whether the fallback you specified is the fallback that actually happens. - **An empty optional field**, to check that empty is carried as empty rather than filled with something helpful. - **A second item for the same case**, if duplicate handling is part of the arrangement. - **An unattended filing**, if the integration will ever run without a person present — a mapping that quietly depends on someone answering a prompt works perfectly in a manual test and fails on the first automated run. | What you exercise | What it catches | |---|---| | One ordinary item | Mandatory fields, list membership, visibility, the back-link | | A value with no counterpart | Whether the specified fallback is the real behaviour | | An empty optional field | Values silently invented to fill a gap | | An unattended run | A mapping that secretly requires a human | ## Cleaning up, and what to keep Delete or close the throwaway items so they cannot be mistaken later for real ones, and keep the record of what you checked next to the mapping itself. That record is worth more than it looks: when the destination changes, or a list gains a member, the same short list of checks is exactly what has to be run again, and the person doing it is unlikely to be you. ## The habit underneath The general principle is that **an integration is verified by exercising it, not by inspecting it**, and the awkward inputs are where the verification lives. A mapping that has only ever carried the value you had in mind while writing it has been demonstrated, not tested.
- The dry run succeeds but the item lands somewhere the triage team never looks. How would that have been caught?By checking visibility as an explicit step rather than treating a successful create as proof. Confirm that a person from the receiving team can find the item through the view they actually work from, not through a direct link. A create returning success only says the tracker accepted it; it says nothing about whether anyone will ever see it.
- What is worth re-running from that dry run later, and when?The same short checklist whenever the destination or either closed list changes: mandatory fields, list membership for each mapped value, the fallback path, the back-link and visibility. Those are precisely the things other people alter without knowing an integration reads them, so the trigger is a change on the tracker's side rather than a change on yours.
saying these in an interview costs you the question
- Treats a reviewed configuration screen as verification
- Runs the dry run into the live defect queue
- Trusts a successful create without reading the item back
- Tests only the happy-path value
- Leaves throwaway items behind, uncleaned and countable