Personal test report
example.
A useful report should connect your measurements to an evidence check, a reversible next test, and a decision you can revisit.
All numbers below are invented to demonstrate the report format. This is not a Radiant benchmark, a real customer result, or evidence of any product's performance.
Evidence incomplete. A decision needs a retest.
The after-run median is higher in this example. Driver version, game version and capture duration are missing, and the exact setting values are unknown. These runs do not establish that the setting caused the difference.
The inputs stay visible.
- Measurement
- Manually entered run-average FPS: five runs before and five runs after.
- Variable
- One in-game quality option. Its exact original and changed values were not supplied.
- Configuration
- No hardware or repeatability metadata supplied for this example. Driver version, game version and capture duration need to be recorded before a comparable retest.
| Run | Before | After |
|---|---|---|
| 1 | 120 | 123 |
| 2 | 118 | 124 |
| 3 | 121 | 125 |
| 4 | 119 | 123 |
| 5 | 120 | 124 |
| Median of run averages | 120 FPS | 124 FPS |
| Observed range | 118–121 FPS | 123–125 FPS |
Matching counts are a starting point.
Both groups contain five values of the same stated metric. That makes the summary readable, but it does not confirm consistent test conditions. No metadata or raw capture files were supplied to verify them.
- Driver and game versions: unknown. An update between conditions would introduce another possible explanation.
- Scene and capture duration: unverified. A different scene or capture length can change the run average.
- Setting values and other conditions: unverified. Record the exact option, its original value, its changed value, and the settings kept constant.
An observed difference, with limits.
What these numbers show
- The median of the five after-run averages is 4 FPS higher, a +3.33% difference.
- The observed ranges do not overlap in these invented runs.
- The raw values remain visible so the summary can be checked.
What they cannot establish
- That the quality option caused the difference, or that it will repeat.
- Better frame-time consistency, reduced stutter or lower network latency.
- A statistical significance result or a performance claim about Radiant or another product.
Current decision: retest before deciding. The missing configuration and repeatability details matter more than choosing a winner from this small example.
Complete the conditions first.
- Name the game, version, fixed scene and measurement tool; set one capture duration for every run.
- Record CPU, GPU, resolution, driver version, quality settings, frame limit and V-Sync state.
- Write the exact in-game option and both values. Keep a screenshot of the original setting.
- Retain the raw captures and note warm-up, interruptions or other changes that might affect a run.
The free notebook keeps a configuration snapshot with each test. Use the game/scene, measurement tool and notes fields to include details that need more context.
Recheck the baseline, then repeat one change.
Fill the gaps and confirm the recovery path.
Record the missing metadata and original option value. Choose a fixed scene and equal capture duration. Keep the same hardware, versions and other settings for the whole comparison.
Restore the original option and record five fresh runs.
Warm up the game consistently, then capture five runs as a new baseline. Keep the earlier data. Compare this fresh baseline with the earlier baseline to look for drift; do not assume that a difference is caused by the option.
Change that one option and record five more runs.
Use the recorded changed value, repeat the same scene and capture duration, and retain every capture. Avoid other changes during this experiment.
Return to the original option and check it again.
Record another five baseline runs. If the baselines drift or conditions differ, investigate and repeat before attributing an effect. Keep a decision and a note explaining what evidence you still need.
Use Fresh retest in the archive to link a new comparison to an earlier test. Earlier measurements stay in their original record.
The original value must come from the user.
Recovery steps in this example: not supplied. The report cannot infer an original setting or invent a recovery procedure.
Before testing, record the exact in-game menu path and original option value, and save a screenshot. If the original value is unknown, establish and document a baseline before making the change.
This example concerns one in-game option. It does not instruct the user to edit the registry, disable security features or apply unverified system tweaks.
Keep collecting your own evidence with the free performance notebook. See our measurement method and editorial and privacy information for the site's scope and analytics disclosure.