Automatic Bug Reproduction

Finding a bug is only half the battle. Reproducing it reliably is the other half. Certyn's bug reproducer agent handles this automatically — when the exploratory agent spots something suspicious, a dedicated agent spins up to verify whether the issue is real and reproducible.

How It Works

The flow is fully automated:

1. Explorer finds something — during an exploratory session, the agent notices an inconsistency, error, or unexpected behavior
2. Reproduction request — the explorer files a reproduction request with details about what it observed
3. Bug reproducer activates — a separate agent receives the report and attempts to reproduce the issue from scratch
4. Verdict — the reproducer reports one of several outcomes

This happens automatically once the workflow is configured, with humans still reviewing the result before closing the loop.

Reproduction Outcomes

The bug reproducer reports one of five outcomes:

Outcome	Meaning
Reproduced	Bug confirmed — it happens consistently
Not Reproduced	Could not trigger the issue — may be intermittent or environment-specific
Partially Reproduced	Some symptoms appeared but not all — the bug may be more nuanced
Blocked	Could not complete the investigation — environment or access issue
Not Applicable	The reported behavior doesn't apply to the current environment version

Why Automatic Reproduction Matters

Reduces false positives

Not every anomaly is a bug. Sometimes a page loads slowly once, or a transient network error causes a flicker. The reproducer separates real bugs from noise.

Saves time

Manual reproduction is one of the most time-consuming QA activities. The reproducer does it in minutes.

Provides evidence

When a bug is reproduced, you get a full session recording: screenshots, agent conversation logs, and step-by-step details. This is the evidence your developers need to fix it.

Catches intermittent issues

By attempting reproduction from a clean state, the reproducer can distinguish between consistent bugs and flaky behavior.

From Observation to Issue

The typical path for a finding:

Explorer spots something
  → Creates an observation
    → Spawns bug reproducer
      → If reproduced: creates an issue with evidence
      → If not reproduced: observation stays as-is for review

Issues created from reproduction have:

• The original observation context
• Reproduction steps
• Screenshots and session artifacts
• A link to the full agent session

Retesting Fixed Bugs

The bug reproducer also handles retesting. When a developer marks a bug as fixed:

1. The reproducer runs the original reproduction steps
2. If the bug no longer appears → verified as fixed
3. If the bug still appears → issue reopened with new evidence

This can be triggered from the dashboard, CLI (certyn issues retest), or browser extension.

Tips

• Review observations regularly — even "not reproduced" findings can reveal edge cases worth testing
• Use the CLI to monitor issue status: certyn issues list --activity attention
• The reproducer works from a clean browser session, so it catches bugs that depend on fresh state
• Combine with the browser extension to trigger retests directly from your issue tracker
• Partially reproduced bugs often indicate race conditions or timing-dependent issues — these are worth investigating manually