Requirements¶

Agents / Requirements answers: what do my test cases actually cover of my requirements — and what do they not?

Your assistant reads your requirements from a source you recorded, splits each one into checkpoints — single testable statements — and links a checkpoint to the step of a test case that checks it, with a quote from both sides and a reason. XPressRT refuses data that contradicts itself, lays the run onto the state that is already there, and keeps the decisions people made.

Coverage is judged against the test cases in this workspace, never against a list in a document.

Not every checkpoint is shown by running a test. Shall not rely on a single photodiode is shown by a review of the design; others by an analysis or a demonstration. Such a checkpoint names how it is verified — inspection, analysis or demonstration — and, where there is one, the evidence. It stands under Verified otherwise on the page, beside the coverage: it is not a gap, it does not block its requirement, and it is not counted among the testable checkpoints.

It is not done without its evidence, though. A requirement whose other checkpoints are covered reads complete by test · 1 to verify otherwise until the evidence is named — by the run, or by you: Record evidence on the checkpoint, for example Design review DR-12. It is kept with your name and time, like a decision, and shows in the History. Evidence named by mistake is taken back with Withdraw evidence and a reason; the entry stays in the History, and the checkpoint is without evidence again — an older entry does not come back by itself. Every view says it the same way — the list, the matrix, the marks in the text, Traceability, its CSV and the export: inspection · no evidence named, never red and never green.

Bringing your requirements in¶

There is no separate import, and that is deliberate: a requirement without the question and what checks it? is worth nothing in a test tool. Asking for your requirements to be brought in is this run — they arrive by being read, split and judged against what is already here.

Before that, one question decides the whole way: do tests for these requirements already exist somewhere — a document, a spreadsheet, a ticket system, another tool? If they do, that is Onboarding and it comes first. Otherwise you get proposals for test cases that already exist somewhere else, which is the most expensive kind of duplicate work there is.

If they do not, the run goes against the stock as it is. Nothing is covered is then the honest starting picture and not a fault — it is the work list.

A large source does not have to come in one attempt: a run can name the requirements it covers, and the rest counts as not part of this run rather than as gone. One attempt over 166 requirements is one attempt that is either wholly through or wholly lost.

Where they come from, and which part¶

A coverage run reads from a source your assistant records once, on your word: its short name, what it is, the link — and its scope, the part of it that is meant, in the system's own words: Set 281-SET-22 (container 34859), an area path or a saved query, a module, a folder. A source is hardly ever the whole system, and that part decides what a run read; where it really is the whole project, the scope says so. The assistant asks you for it and does not guess it from the link. A source recorded before there was a scope shows scope not recorded, and the next run asks.

Wherever a source is named — on this page, on Regression and Onboarding, in a report or an export — it reads the same way: its short name, its name as a link, and its scope. A run keeps the source as it was when it was handed in; if somebody changes the scope later, the run still says what it read from, and adds the source's scope has changed since this run.

What the page shows¶

The head answers the question you come with. One number — how many testable checkpoints are covered — with a bar in which every status has its colour and its word. Beside it three tiles, each a filter: proposals to decide, findings to review, requirements with no test case. On the right the source, what the last run was asked about proposals, whether the decomposition is confirmed, and Deciding as — the name every decision on the page is kept under, entered once. Underneath, one line with the runs, how fresh the state is and where the requirements come from; Freshness and sources opens the details. The state counts as out of date when a procedure with its test cases has different content since the last run — a file saved again unchanged, or changed and set back, does not count. A source counts as read by a full run, or by limited runs that together brought every one of its requirements into the state (or said they fetched from it), dated by the oldest of them. A limited run that only checks what the state already holds reads nothing.

Six views:

Requirements, filtered by the work: To decide, Gaps, Waiting on others, Complete, No test case. A row carries the requirement's title from the source, its id underneath, a small bar of its checkpoints and at most two counters. Opened, it shows its text as Description, with every place a checkpoint quotes marked and lettered — a table in the requirement stays a table, a list a list, and a quote in a cell is marked in its cell. The checkpoints follow in the order of the work: to decide, waiting on someone else (the agent, the next run, the bench, the author), gaps nobody is on yet, and covered, folded away. A checkpoint opens to its evidence and its proposals. Matrix shows the same requirement as checkpoints × test cases, with a mark where a proposal would change a cell.
Proposals: every proposal, by what became of it — to decide, approved and waiting for the agent, written, rejected — grouped by requirement.
Test cases with their steps in their colours, and at every check the checkpoints it covers; a check that covers none says so.
Traceability: requirements × test cases over the whole state, grouped by procedure, each requirement opening to its checkpoints. A row carries the requirement's title, or the start of its text, with the id underneath; the table scrolls in its own frame and keeps the test cases in view. Each cell shows what the runs checked, and a dot in its corner shows what the source itself links — see What the source links. Filter it by procedure, status or proposals, or only where source and coverage disagree, and export it as CSV — with a row for every open proposal, its id and kind, and a source link column.
History: who did what to the state, and when — newest first. Every run an agent laid onto it, every decision on a finding (also the ones a later decision replaced, marked superseded), every approval and rejection with its reason, every question to the agent and how it ended, every withdrawn request with who withdrew it and why. Each entry names the file it is recorded in, so it can be checked there. Filter by people, agents or XPressRT, open it for one requirement with History of … on its card, and export it as CSV. Decisions only narrows it to the log of every decision made on a finding — what used to be the second half of the Decisions view. The HTML export carries the same history.
Decisions: what waits for you, in sections — see Decisions.

A proposal shows what it changes as a difference: what goes in red, what comes in green, the steps around it grey.

Every id is a way there. A checkpoint, requirement, proposal, data point, finding, run or test case named anywhere on the page — in a description, a reason, a note — is a link, also in a shortened list such as SRS-109, 110. The place you jump to opens and is marked; the address carries it, so Back in the browser returns to where you were, scrolled as you left it, and a link can be passed on. Ids on the regression page lead here the same way.

A quote is matched to whole words. 10 ms does not light up inside 110 ms. Where the quoted words stand more than once in the requirement, the page counts the places and marks the quote as unclear, and the run is told — a checkpoint should say which of them it means.

What the source links¶

Your source often already says which test case belongs to which requirement: a relationship in the ALM (verified by in Jama, for example), or a requirement tag on the test case (@SRS-109). A coverage run does not take those over as coverage — a link in the ALM says somebody connected the two, not that a step checks the requirement. They are shown next to what the runs checked, under Traceability, so you can see where the two disagree.

The legend calls it the source links them (ALM or a requirement tag): a small dark dot in the top left corner of a cell. It comes from one of two places:

ALM — your assistant brings the relationships from the source with the run (sourceLinks). XPressRT does not read the ALM itself.
Requirement tag — a test case carries a tag that names the requirement: its id, or an ending of it that points at exactly one requirement (@SRS-109 for 281-ES1183_SRS-109). XPressRT reads these tags itself.

The source links a requirement with a test case, not a single checkpoint, so the dot stands in the requirement's row.

The cell shows	It means
✓ or ½ with the dot	source and coverage agree
only the dot, dashed red frame	the source claims coverage that no step checks — the case that matters most
✓ or ½ without the dot	the test case checks the requirement, and the source does not link them — the link could be added there

Only where source and coverage disagree keeps the requirements with one of the last two. Click a cell, and below the table it says how the source links them — The source links them: tag @SRS-109 — and no step checks it. The CSV carries the same in its source link column, with a row of its own for a pair only the source links.

The run is told as well: where the source links and no step checks it, it should bring a WRONG-LINK finding or a proposal; and a tag that looks like a requirement id but matches none in the state — renamed, retired, a typo — is named. Neither refuses the run.

The legend line appears only once the state has at least one such link: tags on your test cases show at once, ALM relationships once your assistant brings them.

Decisions¶

The Decisions view shows what is waiting for you, one section each; a section opens and closes on its heading and remembers how you left it.

Look again — a decision whose evidence changed under it: the finding points at a different step now (Zwei Blicke, step 11 → 12), or at a test case that is no longer there. It stands here until you Confirm again or Change it.
To review — the findings nobody has answered yet: Confirm, Reject or Other, with a comment. A finding you decide stays where it is until you change the filter, so you see the answer.
Waiting for the agent — every request on this page that is still with your assistant: approvals, data points, questions for a proposal. Each can be withdrawn here, with a reason. The same list over every page is the Agent queue.
Confirmed, Rejected, Decided as other — what is answered.
Marked outdated — waiting for the next run — a finding you marked as no longer true, with a reason. The next run is told; if it brings the finding back unchanged, it is told again.
Handled at the checkpoint (GAP, PARTIAL, TRIGGER) — a gap or a partial coverage at a checkpoint is part of that checkpoint's status, and so is a TRIGGER finding (below). It is answered through the proposal there, not here; the section lists them with a way to each.

A TRIGGER finding says that an existing test case gets the order of what it does wrong against its requirement: what is established beforehand (the world), the one event that causes the reaction (the trigger), and what the device then does (the observation). It names which of five it is:

Subtype	Means
world after the trigger	a condition the world must meet is set after the trigger — a check that "the sensor answers X" observes, it does not make the sensor answer
trigger not last before its checks	something else happens between the trigger and the checks that time it
one condition from two triggers	a state is built in two steps, and the first alone already causes a reaction
sentence and definition differ	the sentence promises something its blocks do not do
time check names no trigger	a time check that serves many test cases does not say in its sentence what it measures from — see A check that names its trigger

It stands at the checkpoint under Why, for test cases, with the proposal that corrects the test case where the correction is clear. Where the requirement itself does not say which event causes the reaction, the finding is an UNCLEAR one for the author instead. The assistant never rearranges a test case on its own; a correction is a proposal you approve.

Every finding says for whom it is: the author of the requirement, the test cases, the bench, or the team. The assistant has to say it for every finding that is not answered at a checkpoint; you can change it on the card, and your choice is kept under your name and counts before the assistant's. For: at the top filters the sections by it — several at once — and every count reads 3 of 7 while the filter is on. Where the state has TRIGGER findings, Trigger: filters by their subtype the same way. Export gives exactly what is filtered and open, as CSV or HTML, with the requirement, its link at the source, the quoted words and, for a TRIGGER finding, its subtype in a column of its own; the HTML report has the questions for the author in a section of their own.

What you do here¶

Schedule coverage — the button under the title, also on the empty page. It does not start anything: it leaves a request for your assistant in the Agent queue. Choose what it covers: all requirements (a full run — only a full coverage run closes it, a limited one does not), only those whose test cases changed since the last run, or only those the filter shows now. Then tell your assistant Work through the open requests in XPressRT.
Work through the open decisions. A decision belongs to the statement it was made against. Change that text and the decision is suspended: it comes back with the old text beside it, so nobody silently keeps an answer to a different question. A new revision number alone does not do that — it is named, and the decisions stand.
Compare two runs, or a run with the state as it is now.
Confirm the decomposition, or say what is wrong with it. The split of a requirement into checkpoints is the one thing a person spots a mistake in within seconds, and almost every wrong verdict later comes from a bad split. Until somebody confirms it, the report carries decomposition unconfirmed; afterwards it says who confirmed it and when. That can happen in the conversation — your assistant records it with your name, you do not have to go looking for a button. It holds for the split as it stands: if a later run splits something differently, it is a confirmation of something else.
Export the state as HTML — the record to hand on.

Proposals¶

A run can bring a proposal for a checkpoint that no test case checks yet: rows for a variants table, a step, or a new test case. It stands in a box under the checkpoint, and the checkpoint keeps its own status above it — an approved proposal covers nothing yet. Whether what gets written covers the checkpoint, the next coverage run says.

What it costs is in the box before you decide. A new test case that needs sentences the pool does not have yet lists them: they stay, and every later test case can write them.
Approve — the agent writes it — under the name in Deciding as. It becomes a request your assistant sees the next time it calls XPressRT, the same way an approval on the regression page does. If no assistant is working right now, the box offers the sentence to give it — Work through the open requests in XPressRT. — to copy. The box says not written yet until the test case says otherwise, and then ✓.
Note for the agent — optional, beside Approve: put the 90 ms row first, only after the 15th. It goes with the request to your assistant and into the History. It does not change what you approve; if the assistant does it differently because of your note, it says how, and the box reads done, deviating as the note asked. To want a different change, reject it with a reason and ask for a new proposal.
Reject — with a reason. The proposal stays rejected as long as runs propose the same thing, and with missing a rejected proposal counts as there: the repair you turned down does not come back by itself. When you want a different one, Ask for a new proposal on the rejected box. Your assistant is told what you rejected and why; the rejection stays on the page, and a run that brings the same repair under a new name is told so.
Withdraw approval — while the request is still with the agent: with a reason, under your name. The request is withdrawn, and the proposal stands to be decided again; the History keeps both. Once the agent has written or declined it, that is Send back or a rejection instead. The same button is under Decisions → Waiting for the agent and in the Agent queue.
Send back to the agent — when the agent could not do it, reported done although the test case does not show it, or the request was withdrawn. It becomes a new request. A request can only be closed as done when the test case says so; your assistant is told what is missing otherwise.
Look at it again. If a later run proposes something else for a checkpoint you approved, the approval was for the earlier proposal and does not carry over. The box shows both, and a request that was still open is withdrawn, so your assistant does not write what nobody wants any more. The same proposal again keeps your approval.

The head of the page counts them: to decide, to look at again, approved and not written yet, written, rejected. Show the ones to decide filters the page down to those. A checkpoint you just decided stays where it was, open, so you see the answer — it moves to its new place when you change the filter.

Two steps approved behind the same step both count as written, in either order: the one written second stands right behind that step and moves the first one down. A step that already stands behind its step cannot be approved again — the page says already in the test case as step 4. If such a request is still open from earlier, the box says so and offers Withdraw approval; your assistant is told to close it without changing anything, and XPressRT does not let it write the step a second time.

An approval belongs to the test case it asks for. A later proposal for a different test case on the same checkpoint — the failure path next to the good one — is a new proposal, not a replacement. A test case written on request stays at its checkpoint as written, not yet judged until a coverage run has read it.

Data points the bench does not have yet¶

Often the only thing missing is a data point — the requirement names the light barrier on PC13, the bench cannot read it yet. Your assistant then proposes the data point and writes the tests as if it were there. Under Proposals, Data points to decide comes first: what it is, what stands behind it, where the details come from, and how many checkpoints it makes proposable.

Approve answers every open question the source left — which level means present — and becomes a request to your assistant to create it, exactly so.
Reject with a reason: the tests that wait on it come back to you, No data point — D-1 rejected: …, with Ask for a new proposal.
Withdraw approval while the request to create it is open — with a reason; the data point stands to be decided again.
The tests that wait on a data point cannot be approved until it is created. Then they are ordinary proposals.

A missing request — run the self test — is proposed the same way. Its box shows the parameters and the instruction as the operator will read them, and why it is a request and not a set point: every data point proposal says why its kind, in one line, and one without is refused. The finding behind a missing data point is a gap in the catalogue and is addressed to test, never to bench: without a bench a person carries it out, so the test case can always run.

An approval holds for what was approved — path, direction, type, unit, values, and for a request its parameters, instruction and safe state — not for the path alone. When a later run proposes the same point differently, the approval is open again: the box says changed since approved: direction read → set, and the request to create it is withdrawn. When your assistant closes the request, XPressRT compares the point it created with the approval; one created with another unit stays open, with the difference named.

A created data point says whether equipment delivers its values or a person answers it. A test that checks a time — within 100 ms — needs values with a timestamp, and the box says so when a person would be answering. Export CSV gives the list, with the reason for each kind and a request's parameters and instruction.

Checkpoints without a proposal¶

Before every coverage run your assistant asks whether it should bring proposals: all (every open checkpoint, anew), missing (only those that have none yet — the ones there come back unchanged, with your decisions), or none. The answer is recorded with your name — yours, not the assistant's: an assistant working for you answers with your name, one that enters its own is refused — and the head of the page says it, so "no proposal" after a "none" reads as a decision and not as something forgotten.

With all or missing, every open checkpoint has a proposal or a reason why there is none: the bench has no data point for it, a procedure is missing, or it is a question for the author. The head of the page counts them by reason — which ones a test developer can do something about, and which ones need the bench or the author. When the reason is gone — or where a run was never asked for proposals — Ask the agent for a proposal at the checkpoint; the next coverage run over that requirement answers it. The request stays at the checkpoint until it is answered, and a refusal of the agent stands there with its reason and Ask again.

A test case that checks several checkpoints is one proposal: the others are named in it, and they show the proposal they depend on. Both buttons ask about their checkpoint only: the other open checkpoints of the requirement stay as they are, and the run is not asked to fill them.

A requirement the last full run did not bring stays on the page, marked, but is not counted until you say whether it is gone.

When a test case changes under a verdict¶

A link quotes the step it rests on. If that step now reads differently, or a variants row the run named is gone, the link is unjudged: it no longer counts, and a checkpoint that stood only on such links reads unjudged — was covered. The number at the top, the bar and the exported report count it the same way. Nothing is changed in the state; a coverage run over those requirements settles it.

What a run must carry¶

Every requirement names the version the source itself counts with — in Jama the item's version number, in a document the revision printed on it, none if the source keeps none. One word, not a sentence: the next run, and the regression, must write the same thing for the same version, or nobody can compare them.

Limited runs¶

A limited run judges only what it brings. A finding that also concerns requirements outside it stays in the state as it is, and the run's links may still name it; the answer says which findings were kept that way and which, if any, were removed.

A coverage run can be limited to a few requirements — that is what the regression asks for when its coverage is not current. Everything outside that scope stays exactly as it was, and the page says so: not delivered here means not part of this run.

What a run cannot take away¶

A run lays what it brought onto the state. What it did not bring stays: requirements, their checkpoints, the links between them, the test cases, and the findings that name any of them. Each is kept with its decisions, and the run's answer counts them out.

A requirement the run did not bring also gets a finding of its own — the run did not bring this one — so a person decides whether it is gone from the source or was simply not read. The product does not decide that.

One rule sits above the rest: a finding somebody decided on never disappears without a word. If it points at nothing this state knows any more, it is kept anyway and named, so you can see whether what it was about was renamed.