CtrlK
BlogDocsLog inGet started
Tessl Logo

testland/confirmation-testing-workflow

Procedure for proving that a claimed defect fix actually reached the build under test and actually works. Covers the merge-base ancestry check that proves the running build contains the fix commit rather than trusting a version label, the priority order for choosing which reproduction to re-run, and the VERIFIED / NOT FIXED / BLOCKED verdict table whose governing rule is that any ambiguous, flaky, or unreproducible result resolves to BLOCKED and is never guessed. Scoped to ISTQB confirmation testing (does this specific fix work?), not regression testing (did the fix break something else?), and not triage or severity assignment. Use when a developer has marked a defect Fixed and someone must decide whether it moves to Verified or back to Reopened.

99

1.03x
Quality

94%

Does it follow best practices?

Impact

100%

1.03x

Average score across 10 eval scenarios

SecuritybySnyk

Passed

No findings from the security scan

Overview
Quality
Evals
Security
Files

criteria.jsonevals/scenario-9/

{
  "context": "The build provably contains the fix, the reported symptom did not recur on four attempts in the environment under verification, and the developer's unit test is green. The predicted unaided answer closes the ticket on exactly that. What it misses is that the server-side rejection is gated on strictDocumentVersioning, which config/features.json sets to false for staging - so the code the fix added never ran during the paired session, and the developer's test passes only because it uses the 'dev' environment where the flag is on. Something else stopped the overwrite (the same release shipped a client-side draft-cache banner), which means the observation cannot be attributed to the fix at all. The correct output withholds the decision, names the flag state as the reason, and asks for a re-run with the flag on.",
  "type": "weighted_checklist",
  "checklist": [
    {
      "name": "Record delivered",
      "description": "A file qa-record/BUG-6017.md exists and states a decision. Scores zero if absent.",
      "max_score": 4
    },
    {
      "name": "Identifies that the fixed code path did not run in the environment observed",
      "description": "The record states that strictDocumentVersioning is false for staging in config/features.json, so the stale-version rejection the fix added could not have executed during the 2026-08-13 session. Missing this scores zero however the decision lands - it is the single fact that changes the answer. Mentioning the flag only as background, without connecting it to the observation, scores at most half.",
      "max_score": 32
    },
    {
      "name": "Refuses to move the defect to Verified",
      "description": "The decision is that the evidence does not settle the question and the defect stays where it is. Recommending Verified scores zero, including 'Verified, since the flag is on in production'. Recommending a reopen also scores zero: nothing suggests the fix is wrong, only that it was never exercised.",
      "max_score": 22
    },
    {
      "name": "Refuses to substitute the production flag value for evidence",
      "description": "The record does not argue that because production has strictDocumentVersioning true the behaviour is confirmed. Reasoning from the configured value of the flag in another environment to a decision about this defect scores zero on this criterion.",
      "max_score": 14
    },
    {
      "name": "Gives the concrete action that would settle it",
      "description": "The record names the specific next step: enable strictDocumentVersioning in the verification environment - or run in one where it is already on - and repeat the same four reproduction steps against a build that contains 2ea5f19, then decide. 'Test again' or 'investigate further' with no flag state named scores zero.",
      "max_score": 16
    },
    {
      "name": "Attributes the observed banner honestly",
      "description": "The record says the banner the testers saw cannot be traced to the fix and names the client-side draft cache shipped in the same release as an alternative explanation, rather than reporting the session as a pass. Reporting 'could not reproduce, therefore fixed' scores zero.",
      "max_score": 12
    },
    {
      "name": "MUST NOT record a conclusion without the evidence attached",
      "description": "MUST NOT settle for a 'works for me' write-up. The record must carry the fix commit 2ea5f19, the environment and its build commit 74b0c62, the flag state during the run, and the testers' observations as written rather than paraphrased into a verdict. A record missing the build commit or the flag state scores zero on this criterion.",
      "max_score": 10
    },
    {
      "name": "Does not treat the containment result as sufficient",
      "description": "The record reports the affirmative containment check and states that it shows the source is present, not that the fixed behaviour was exercised. Presenting the exit-0 result as if it settled the question scores zero; omitting the check entirely scores at most half.",
      "max_score": 10
    }
  ]
}

SKILL.md

tile.json