PROPOSED PROJECT
Bug Reproduction Assistant
Help engineers recreate a bug reported by a customer. Use error records with private details removed, the product version, and support messages to draft the steps, run approved tests away from the live system, and attach a recording of what happened.
“I selected two. It only archived one.”
Product build 4.8.2
Brand guide is selected.
page 2
Selection still says 1. Expected: 2.
Give engineering
something they can repeat.
Fictional ticket SUP-218 reports that selecting files across two pages archives only the second-page file. In build 4.8.2, the example selects Brand guide F-012 on page 1 and Launch notes F-027 on page 2. The event list shows the selection clearing at 00:07 during the page change. Two illustrative attempts archive only F-027; both should have included F-012 as well. No real customer files or test recordings are used in this study.
WHAT IS USUALLY DONE
A support ticket says something went wrong, but engineering receives an incomplete sequence and no matching test data. Staff repeat the conversation, try several versions, and guess which action caused the problem. A suspected cause can enter the ticket as fact before anyone has recreated the failure.
WHAT SOVRUN CAN DO FOR YOU
Sovrun would build a controlled path from a support report to a repeatable engineering case. AI reads the supplied conversation and cleaned error records, identifies missing details, and proposes exact steps. An approved test runner repeats the task in a separate workspace, recording the screen and relevant events. The assistant packages the expected result, observed result, product version, and evidence for an engineer; unsuccessful attempts remain visible.
Keep the steps
and the evidence together.
The proposed assistant turns a support conversation into a test plan, runs only approved actions in a separate workspace, and records what actually happens. A suspected cause stays separate from the observed failure.
Recreate the exact task.
- Open Files in the test workspace.
- Select Brand guide (F-012) on page 1.
- Go to page 2 and select Launch notes (F-027).
- Choose Archive and inspect the affected file IDs.
- Build
- 4.8.2
- Browser
- Approved test profile
- Viewport
- 1440 × 900
- Data
- Fictional file workspace
Where the selection disappears.
Example attempts show the same missing selection.
R-01 and R-02 / reset data between runs
Observed: selection clears on page change.
Possible cause: the selection is stored only for the current page. That is a hypothesis for code review, not a confirmed diagnosis. Keep the recording and event log attached even if the eventual cause is different.
From support ticket
to a useful engineering handoff.
The proposed first build targets one product workflow and a defined set of allowed test actions. It produces a repeatable report, captured evidence, and a draft test for the engineer.
Two selected. One archived.
- Expected IDs
- F-012 + F-027
- Observed IDs
- F-027
- Product build
- 4.8.2
- Example attempts
- R-01 + R-02
Go straight to the moment.
Example filenames for the proposed handoff.
Keep both selections.
- Select F-012 on page 1
- Select F-027 on page 2
- Expect both IDs in Archive
No fix is inferred or deployed by this study.
How we’d make it happen.
Turn the report into a testable task
Extract the sequence and expected outcome from the supplied ticket. Ask for missing version or setup details rather than inventing them, and agree on safe test data.
Repeat only approved actions
Run the task in a separate workspace with defined limits. Capture the screen and relevant events, reset the data between attempts, and record failures or blocked steps honestly.
Package what was observed
Write the reproduction report, attach the evidence, and propose a test for engineering review. Keep observed behavior separate from suspected causes and leave fixes to the engineering process.
Where AI helps
Language and code models extract the reported sequence, propose test setup, and help write a draft regression test. We test their handling of vague reports, missing steps, conflicting versions, and irrelevant errors. Only approved actions run in a bounded test environment. Captured events determine what happened; model explanations of why it happened remain labeled as hypotheses until an engineer confirms them.
What people approve
Support approves the cleaned source material and expected task. Engineering approves the test environment, permitted actions, and sample data, then reviews the recording and proposed test. Logs exclude private customer content and secrets. A reproduction failure does not close the customer’s report, and a successful reproduction does not authorize a code fix or production release.
What we’d need to start
- Support messages and relevant error records with private details and credentials removed
- The reported product version, browser conditions, permissions, and an approved test workspace
- Safe sample data, permitted test actions, expected behavior, and the engineering handoff format
How we’d test it
Test complete and incomplete reports, wrong versions, permission failures, intermittent behavior, and tasks that cannot be reproduced. Check that recorded steps can be repeated independently, source timestamps locate the right events, and sensitive details stay out of the handoff. Confirm that uncertain causes remain hypotheses and that an unsuccessful attempt never becomes a false success claim.
Prepared for Technology & software. We would agree on the work after reviewing your brief, materials, and requirements.
This is a proposed project, not completed client work. The visuals and numbers show example outputs, not measured results.
