What a Server Memory Test Report Should Contain (and What It Should Not Claim)
Short answer: a test report is worth exactly what can be checked against it. The five fields that make one useful are what was tested, in which host, in which population, using which pattern and for how long, with which result. Anything less is an assertion rather than evidence — and the most commonly missing field, population, is usually the reason you wanted the report in the first place.
Why the population field is the one that matters
A module that passes alone has been shown to be alive. It has not been shown to work in your machine, because the failures that hurt are the ones that appear when modules are populated together: a channel training to slower timings, a rank budget exceeded, an initialisation that depends on the order modules are fitted.
So a report that says "tested, passed" and stops there is answering a different question from the one you asked. What you want to know is whether the configuration resembles the one you intend to run — how many modules, in which slots, across how many channels.
The five fields a useful report contains
| Field | What it should say | Why it matters |
|---|---|---|
| 1. Scope | Part numbers, quantity, lot numbers, and whether the whole lot or a sample was tested | Ties the report to specific goods. A report that cannot be matched to a delivery is not evidence about that delivery. |
| 2. Host | The machine the test ran in — model and, where relevant, firmware level | Platform behaviour differs. A pass on one platform is not automatically a pass on yours. |
| 3. Population | How many modules, in what slot configuration, across how many channels | The field that predicts your outcome. Population is where the real failures live. |
| 4. Method | Which pattern or tool, and for how long | Lets you judge what was actually stressed, and compare against what you plan to run. |
| 5. Result | Errors recorded, and any module marked marginal or doubtful | A clean pass is only meaningful if failures would have been reported. Ask what would have caused a fail. |
If a report has all five, it is falsifiable — you can attempt to reproduce it, and you can check the delivered goods against it. If it is missing any of the first three, it is closer to a claim than a measurement.
What a report should not claim
- A guarantee of future reliability. A test can establish that modules work now, in a stated configuration. It cannot establish how long they will continue to.
- Compatibility with your platform. Unless your platform was the one tested. A pass elsewhere is a reason for confidence, not the same thing.
- Coverage it did not have. If the method was a sample, the report should say a sample. Reports that imply full coverage are misleading even when the sample was reasonable.
- Anything about untested grade. There is no test to report by definition — which is precisely what the lower price is buying. A seller offering a report on untested stock is either testing it or describing it wrongly.
A template you can use for incoming inspections
The same fields work in the other direction. When goods arrive, this is a reasonable structure for your own record — and having it in a fixed form makes a claim far easier to argue if one becomes necessary.
Lot / order reference: Part number(s): Quantity received: Condition grade per line (as quoted): Date received: Host used: Firmware level: Population tested (modules, slots, channels): Sample size and how drawn (whole lot / across cartons / single box): Pattern(s) run: Duration: Result (errors observed): Modules marked doubtful: Photographs attached (lot, label, contacts, packaging): Agreed claim threshold: Claim deadline:
The two lines people leave out and most often need are the sample drawing method and the agreed claim threshold. Without the first, a clean result is not comparable to anything. Without the second, a dispute has no procedure and becomes a negotiation.
Reading a report you have been sent
A short sequence for evaluating a report that lands in your inbox:
- Can you match it to the goods? Part numbers and quantity should agree with the quotation and the packing list.
- Is the population stated? If not, the report cannot tell you about your configuration.
- Does the method name a pattern and a duration? If not, "passed" is an assertion.
- Would a failure have been recorded? A test that cannot fail is not a test. Ask what the failure condition was.
- Does it claim more than it measured? Watch for implied full coverage over a sample, or compatibility with platforms that were not tested.
What we put in ours
Test reports ship with tested and refurbished grade lines as standard, rather than being available on request. Ours state the part numbers and quantity covered, the host and population used, the pattern and duration, and the result — and where a sample rather than the whole lot was run, the report says so and describes how the sample was drawn.
For untested grade there is no report, and we say that plainly rather than implying otherwise: the goods are sold as-is, and the absence of testing is the thing the price reflects.
If your own inspection turns up a result that disagrees with a report we sent, tell us — with the lot numbers and your test record attached. That is the conversation we would rather have than a disagreement later.
Ask Ms Aya for the test report on a specific lot, or read the guide to buying pulled memory for what each condition grade promises.