Repository navigation
What baseline does the second Consumer measure before the first run? #548
Description
Question
What baseline does the second Consumer measure before the first run, so the result can be proved afterwards?
Candidates from the brief: manual test cases, QA effort per sprint, escaped defects. Decide which ones, who measures them, over what period, and where the numbers live. Without a baseline, nothing afterwards is provable.
Activity
orioltf commentedon Sep 29, 2026
Resolution, 2026-09-30
The second Consumer owns the QA Baseline. Its team defines the metrics, measures them before the first run, and keeps measuring them afterwards. This map proposes the metrics and states what the chain must leave behind so they can be counted. It does not measure anything itself.
Every number, result and definition lives in the Consumer's own tracker. None of them goes on GitHub, not even a count or a share. A work item in the Consumer's tracker carries the work of building the metrics there. It has no mirror ticket here.
The proposal
Measure the whole team, per sprint. The chain has handled no ticket yet, so a per-ticket comparison has nothing to compare against.
If the team does not log QA hours, metric 1 drops out and metric 2 stays.
Escaped defects are out. Nothing built by the chain is in production yet.
Whether the chain works at all, meaning its tests pass review and CI, needs no baseline. Before the first run that count is zero.
The process page itself was not read. It is not in the mirror of Unic's process register, and the metric list above comes from the internal QA plugin's file, not from the page (unverified).
What the chain must leave behind
Every generated test names the ID of the acceptance criterion it covers. Without that, metric 3 cannot be counted. The PRD already keeps each criterion's ID (#549), and the defect management step of Unic's software quality management process asks for traceability between defects, requirements and test cases. This is Consumer context and needs no Box change. The format, a test title or a Playwright annotation, is left to #543, which decides the suite's conventions.
When "before" starts
The cut point is the first merge of a generated test to the Consumer's integration branch, not the first run. A first run can happen on a developer's machine and never reach CI. The Consumer measures at least N sprints before that merge, and chooses N.
The QA Baseline is a precondition of that first merge, not of building the chain. If a generated test merges before N sprints are measured, the saving in QA effort can no longer be proved. The Consumer's existing suite is on its integration branch today, so the starting point for metric 3 exists and can be counted.
Not decided here
CONTEXT.md. The chain never reads or writes it, so it is not a term of the plugin's domain.