A real-device QA workflow that produces reproducible tickets

The gap between QA and engineering is usually not effort. It is that a tester sees the bug and a developer receives a sentence about it.

Everything below is about closing that gap while the device is still in the tester’s hand.

The problem with a good bug report

Even a careful report — steps, expected, actual, a screenshot — loses almost everything that was on the device at the time. The log around the failure. What the app was doing in the two seconds before. Whether memory was climbing. Which iOS build, how full the disk was, whether the phone was hot.

A developer who cannot reproduce it has to guess at all of that, one question at a time, over a week of comments.

Capture while it happens

The device is right there. Take four things:

1. The log around the failure

Not the whole session. Clear, reproduce, stop, save. A log that starts ten minutes early is nearly as useless as no log, because nobody will read it. Filter to the app under test and note in the ticket which filter you used.

2. A performance capture, if it is a performance bug

Ten seconds either side of the stutter, freeze or crash. This is the difference between “it was slow” and “CPU spiked to 90% for 400 ms during the transition”.

3. Screenshots on a timer

For anything visual and intermittent, a burst at 500 ms intervals catches what a manual screenshot never will. Set it running, reproduce, stop.

4. Device state

iOS build, model, free storage, battery health, installed profiles, locale, accessibility settings. Copy it into the ticket verbatim. This is the section that resolves “cannot reproduce” more often than any other.

The template

Keep it short enough that people actually fill it in.

Summary:
Steps:
Expected / Actual:

Device:      iPhone 12, iOS 17.4.1
Storage:     4.2 GB free
Battery:     84%, 612 cycles
Build:       2.8.0 (412)
Profiles:    none unexpected
Locale:      en-GB, Dynamic Type default

Attached:    filtered log (filter: [Feed])
             performance capture (10s around the stutter)
             screenshot burst (500 ms)

Six lines of device state and three attachments. It is more work than a screenshot and much less work than a week of back-and-forth.

Two things worth doing before filing

Try it on a second device. If it reproduces on both, say so — that removes a whole branch of the investigation. If it does not, you have already found the most valuable fact in the ticket, and the device-state block is where the answer is.

Check the crash list. If the app disappeared rather than misbehaved, there is a crash report on the device. Attach it. A report with a dSYM behind it turns a two-day investigation into a five-minute one.

Working with someone else’s device

When the phone belongs to a customer rather than to the team, everything above still applies with an extra rule: take the least you need.

• Logs and performance captures are usually fine.
• Screenshots may contain their data. Look before attaching.
• An app container or a device backup contains their whole life. Only with explicit permission, only the narrowest export that answers the question, deleted when the ticket closes.

The failure mode here is not malice; it is exporting a container to debug something, finishing, and forgetting the folder exists.

What changes

A team that does this consistently ends up with tickets that a developer can act on the same day, and a body of captures that make the second occurrence of a bug much faster to place than the first. The cost is about four extra minutes per report, at the moment when the bug is in front of you and the information is free.