Acceptance Testing Hardware Before You Deploy It

Hardware failures cluster at the beginning of service life. Manufacturing defects and transit damage show up in the first weeks, which is precisely why testing before deployment catches problems while they are cheap.

Why early testing pays

Failures follow a pattern: an early period where defects surface, a long middle period of low random failure, and a wear-out phase late in life. Our lifespan guide covers the shape.

The practical consequence is that the riskiest weeks are the first ones, and they are also the weeks when the warranty window is open and the hardware is not yet carrying anything.

A component that fails on a bench costs an hour. The same component failing three weeks later, in a production array, during a rebuild, costs considerably more — and by then the return window may have closed.

This applies to new hardware as much as refurbished. New parts have manufacturing defects; refurbished parts have been tested by the supplier but have also travelled.

Verify identity before testing function

First, confirm what arrived is what was ordered.

Query the device electronically and compare against the label — capacity, firmware, model identity, serial. That reads what the device reports about itself rather than what is printed on it, and it is the most reliable check available. Our verification guide covers the detail.

Check the part number matches what you ordered, not just the specification. Carrier generation and firmware coding are encoded in the part number, and a drive with the right capacity and the wrong coding will be rejected by the controller.

Record serials against your asset register at this point. It is easier now than later and it makes warranty claims straightforward.

Do this while the return window is open. Our claims guide covers the terms worth knowing.

Testing drives

The component most worth testing, because it holds data and fails most often.

Check health attributes as received. Reallocated sectors, pending sectors, power-on hours and any predictive failure flag. On refurbished drives, hours are expected; what matters is whether error counts are clean.

Run a full surface read. Reading the entire drive verifies every sector is accessible and surfaces media problems that a quick check misses.

Then check attributes again. This is the step people skip, and it is the informative one — a drive whose reallocated count moved during testing is telling you something a single reading would not.

Test under sustained load where practical. Drives frequently pass idle checks and misbehave under continuous work, which is what a rebuild will demand of them.

Testing memory

Different failure mode, and worth its own attention.

Memory either works correctly or produces errors that testing detects. There is no gradual wear-out comparable to a mechanical drive, which makes testing unusually conclusive here.

Run a thorough memory test before deployment, and be aware that intermittent memory faults may only appear under thermal stress or after extended running — a short test can pass on a module that fails later.

On systems with ECC, check the correctable error log after testing. A module producing corrected errors is working, and it is also telling you it will not keep working. Our ECC guide covers why that log is monitoring as much as correction.

Testing a complete server

Where the value is in running it, not in any single check.

Let it run under load for a period — days rather than hours. Thermal problems, marginal components and intermittent faults surface with time and heat, not with a quick boot.

Watch the management controller log throughout. It records what the operating system does not see, and it frequently identifies a problem directly. Our management guide covers accessing it.

Check temperatures and fan behaviour under load. Fans running high on a lightly loaded server indicate an airflow or cooling problem before it becomes a throttling one.

Verify redundancy actually works. Pull one power supply and confirm the server continues. Pull a drive from a mirrored pair and confirm it degrades gracefully rather than stopping. Redundancy that has never been tested is an assumption.

That last test is the one most worth doing and least often done.

Bring firmware to a known level

Before deployment rather than after.

Arriving hardware is at whatever level it left the previous environment. Bringing it to the level you have standardised on means it behaves consistently with the rest of the fleet, and it means a replacement part matches what an array expects.

Do this on the bench, where a failed update is an inconvenience rather than an outage. Our firmware guide covers when updating is justified and the precautions that matter.

Record the level you settled on, with the serial, in your asset records.

Testing scanners and printers

Different components, same principle.

Scanners: confirm the optics variant is what you ordered by testing against the smallest code and the furthest distance you actually need — not against the box label. Check that the symbologies you use are enabled, since several are commonly off by default. Our scanning guide covers this.

Printers: print on the media you will actually use, at the real label size, and check the barcode quality rather than only that it scans. Our verification guide covers why scanning is not verifying.

Before it goes into production

Identity verified against the order and recorded. Health attributes clean, checked before and after a full read. Run under load long enough for thermal and intermittent faults to appear. Redundancy tested by actually removing something. Firmware at your standard level and recorded. And all of it done while the return window is open.

That sequence takes a few days of elapsed time and very little attention, and it moves failures from production into the bench.

Common questions

Test while the return window is open — ours is 30 days with no restocking fees, and a problem found on a bench is a different conversation from one found in production.