Before a TestRail-class case repository can create a defect in a separate issue tracker, what must the two systems agree on about the destination?
answer
- the destination is an address
- it has two parts, not one
- configuration hangs off the pair
- project plus item type
basics
~20 sTwo things, as a pair: which tracker project receives the item, and which item type it is created as. Trackers attach mandatory fields, closed value lists and workflow to that pair, so the mapping is defined against it.
solid answer
~50 sThe destination is an address with two parts: the tracker **project** the item is created in, and the **item type** it is created as — what trackers call an issue type or work-item type. That pair is what the tracker scopes its configuration to. Which fields exist, which ones the tracker refuses to create an item without, which closed lists those fields draw from, and which workflow the item then follows are all properties of one project-and-type combination, not of the tracker as a whole. So the pair has to be settled first: every later mapping decision is defined against it, and changing either half later invalidates the mapping rather than merely relocating it. In Jira-resident tools such as Xray or Zephyr the point is sharper still, because their own objects live in the tracker as items of particular types.
go deeper
Be able to name both halves of the destination out loud: the tracker project and the item type inside it. Say plainly that required fields belong to that combination, so it has to be chosen before anything is mapped.
Explain the mechanics: field existence, mandatory status, closed list membership and workflow all hang off one project-and-type pair, which is exactly why a mapping is not portable between destinations.
Show you have lived with a destination that changed. Talk about projects being renamed or merged, mandatory fields appearing afterwards, and items landing in a queue nobody triages.
Own the shape of the whole arrangement: one destination per stream versus one for everything, who decides, and why a shared destination pushes the mandatory-field set toward the union of every team's needs.
## The address a link is built on Before any value crosses between a case repository — a TestRail-class product, or Qase, Testmo, qTest, Polarion and their peers — and the tracker holding requirements and defects, the two systems must agree **where** an item is created. That agreement is a pair, never a single choice: 1. the **destination project** in the tracker, and 2. the **item type** the new item is created as (an issue type, a work-item type, whatever that tracker calls its shape of item). Only once both halves are pinned does the phrase *field mapping* mean anything, because a field mapping is a statement about a specific item shape in a specific place. ## Why the pair, not just the project Trackers scope nearly all of their configuration to the project-and-type combination rather than to the tracker globally. Attached to one such combination are: - the **set of fields that exist at all** on that item; - which of those fields are **mandatory**, so the create is refused without them; - the **closed lists** those fields draw their members from; - the **workflow** states the item can occupy and the transitions between them; - the **visibility and edit rules** that decide who can read or change it. Change the project and any of the five can change; change the type inside the same project and most of them still can. That is why a mapping is not portable. It is a set of promises about one shape of item in one place. | What the pair fixes | What it means for the mapping | |---|---| | Which fields exist | A repository value with no destination field simply has nowhere to go | | Which fields are mandatory | A create is rejected outright unless every one of them is supplied | | Which closed lists apply | Member-for-member value mapping can only be written against a known list | | Which workflow applies | The state a newly created item starts in, and what may move it on | | Who may read and edit | Whether triage can even see the item the repository files | ## The item type is not a formality Teams tend to argue about the project and accept whatever type is offered. That is backwards often enough to be worth naming. A defect, a task, a child item under an existing story and a record of one execution are commonly different types with genuinely different mandatory fields. Pick the wrong one and the failure is not cosmetic: the item lands outside the queue triage actually reads, or it demands a value the repository has no way to produce. The Jira-resident tools make the point vividly. Products that live inside the tracker rather than beside it store their own objects as tracker items of particular types, so for them the item type **is** the integration surface rather than a setting on it. ## Where the choice goes wrong in practice 1. **The project was chosen by whoever wired it up.** Many organisations run a defect project per product or per team. A repository that files everything into one project produces a queue nobody owns. 2. **The type was left at the tracker default.** The default type in a project is frequently the generic work item, whose mandatory fields are tuned for planning rather than for defects. 3. **The destination was decided once and then moved.** Projects get renamed, merged and archived. A mapping written against the old pair keeps referring to a shape that has changed underneath it. 4. **One destination was made to serve several products.** The mandatory fields then become the union of everyone's requirements, and the repository has to supply values it has no business asserting. 5. **Nobody wrote the pair down.** The configuration lives in one integration screen and the reasoning behind it lives nowhere, so the next person re-derives it from scratch. ## How to settle it well - Choose the destination from the **consumer's** side: whose triage queue should this appear in, and which item shape does that queue expect? - Confirm the item type by looking at what the tracker demands for it, not by what the type is called. - Record the pair alongside the mapping itself, with the reason, so a later reader can tell a deliberate choice from an accidental one. - Treat a change to either half as a change to the whole mapping — re-check mandatory fields and value lists rather than assuming the mapping travelled. The underlying discipline is small and easy to state: **an integration writes into a shape, and the shape has a two-part address.** Everything else in a field mapping — a mandatory field with no source, a value list that does not line up, a field both sides can edit — is a consequence of which address you picked.
- The destination project is merged into another one after the integration has been running for months. What do you re-check?Treat it as a new mapping rather than a relocation. Re-check which fields exist on the item type in the merged project, which of them are now mandatory, and whether the closed lists gained or lost members. Also confirm that items already filed still resolve, and that triage in the merged project actually reads the queue the repository now writes into.
- Why can one repository need several destination pairs rather than one?Because different products, teams or work shapes are triaged in different places. A defect from a payments suite and a defect from an internal tool often belong in separate projects with different mandatory fields. One pair per stream keeps each mapping honest; forcing one destination makes the mandatory-field set the union of everyone's, and the repository ends up asserting values it cannot know.
saying these in an interview costs you the question
- Says only the project matters, item type is cosmetic
- Assumes tracker field configuration is global, not per project
- Thinks a mapping moves unchanged to a new destination
- Picks the tracker default item type without checking it
- Cannot say why required fields depend on the destination