Create reproducible bug reports and triage issues by impact, evidence, and release risk.

A bug report is useful when it helps someone reproduce, understand, prioritize, and verify a problem.

Good bug report structure

Include:

title that states the broken behavior
environment and version
affected user role or account type
steps to reproduce
expected result
actual result
evidence such as screenshot, log, trace, run ID, or session ID
frequency or reproducibility
severity and suspected impact

Expected vs actual

Expected result should describe the correct product behavior. Actual result should describe what happened instead.

Example:

Expected:
The owner can open Billing and see the current subscription.

Actual:
Billing opens to a blank page with a console error after the loading spinner disappears.

Avoid writing "expected: it works" or "actual: it does not work." That does not help triage.

Severity vs priority

Severity describes user or business impact. Priority describes when the team should fix it.

Severity	Meaning
Critical	Blocks core workflow, data integrity, security, or release
High	Major user impact with no acceptable workaround
Medium	Important issue with workaround or limited scope
Low	Cosmetic, minor, or low-impact issue

Priority can differ from severity. A low-severity issue on a high-value launch path may be high priority.

Reproducibility

Record whether the issue is:

always reproducible
intermittent
environment-specific
data-specific
user-role-specific
likely flaky or timing-related

If the issue is intermittent, preserve run evidence and look for patterns before closing it as noise.

Deduplication

Before creating or escalating an issue, check whether an equivalent issue already exists.

Two issues are likely duplicates when they share:

same user-visible failure
same affected workflow
same environment/version
same error signature
same root cause signal

Do not merge unrelated symptoms just because they happen in the same area. Keep issues separate when fixes or owners differ.

Triage flow

Confirm the failure has enough evidence.
Check whether it is already tracked.
Classify severity and affected scope.
Decide whether it blocks release.
Assign owner or next investigation step.
Re-run or schedule confirmation after a fix.

Certyn workflow

Use Certyn artifacts to keep triage grounded:

run result for what failed
session logs and screenshots for evidence
issue lifecycle for current state
observations for exploratory findings that need review
project metrics for trends and release pressure
wiki rules for project-specific severity or readiness policy

Bug Reporting & Triage