FAT testing of PCs and servers before shipment: protocol

What FAT is and what it covers

FAT (Factory Acceptance Test) is the factory acceptance testing done before shipment. The idea is simple: demonstrate with facts that a particular PC or server in its specified configuration is working, stable under load and ready to operate at the customer. If FAT is done correctly, the incoming inspection does not spend days repeating tests. The inspector checks the protocol and selectively verifies key points.

It’s important to distinguish a “functional check” from FAT. A functional check answers “does it power on and basically work?”. FAT answers “does the delivery meet the requirements and withstand the typical load?”. Therefore FAT needs measurable results, not vague statements, so the tests can be repeated under the same conditions.

In practice, acceptance disputes rarely happen because of the hardware itself; they happen because of the evidence. Incoming inspection is usually dissatisfied when tests aren’t tied to a serial number (or asset ID), logs are incomplete (only screenshots without timestamps, utility versions or conditions), tests were run in “ideal” conditions while the customer has different power and cooling, or it’s unclear exactly what was tested (which ports, which drives, what load, how long).

A good FAT mitigates these risks in advance. Results must be repeatable: BIOS/firmware versions, OS or boot image version, utility versions, test durations, room temperature (if relevant), and Pass/Fail criteria. Then the inspector sees a protocol, not an opinion.

A simple rule: every FAT test should answer three questions — what was tested, how it was tested, and what the numeric result was. For example: RAM capacity and number of errors (0), SMART/health of drives, network throughput, stress duration, maximum CPU/GPU temperature, absence of throttling and reboots. Such detail is especially helpful for deliveries from manufacturers and integrators where traceability and a unified documentation standard matter, including companies like GSE.kz.

What to record in advance so the protocol is accepted without disputes

Disputes at incoming inspection almost always start not with numbers but with different understandings of what was tested and under which conditions. Before FAT, agree the scope so the protocol is read the same way by the factory and the inspector.

First, record what belongs to the delivery and the batch. The protocol must clearly state: model (for example, the PC or server series), configuration components (CPU, RAM size and type, drives, RAID, network adapters, power supplies), serial numbers, quantity, batch number and assembly date. Also list BIOS/UEFI and key component firmware versions (RAID/HBA, BMC/IPMI, network cards) and the OS or boot test image version if tests were run from it.

Next, describe test conditions. This often answers most questions: mains type (220 V, presence of UPS), grounding scheme, room temperature and allowed range, network layout (internet access, DHCP or static IPs), peripheral set (monitor, keyboard) and the test stand composition (switch, load sockets, test drive).

To make results objective, predefine Pass/Fail criteria and acceptable deviations. Examples to agree in advance: what is considered an ECC failure (if applicable), which SMART attributes are critical, allowable temperature spread under load, and how to treat warnings that don’t affect operation.

Finally, record what constitutes FAT completion: who signs the protocol (name, position, organization), date and place, which files are attached (test logs, screenshots, configuration dump), how the device is labeled after passing (e.g. “FAT Pass” sticker and protocol number), where primary logs are stored and for how long.

If you manufacture and integrate equipment at a factory, like GSE.kz, it’s useful to include a traceability item: link device serial number to the protocol number, assembly shift and production line. This simplifies acceptance and dispute resolution.

Basic configuration and identification checks

If this step is incomplete, any subsequent test results will be disputed: it’s unclear what was tested and whether the protocol applies to the specific machine. First confirm device identity, completeness and basic configuration, then move to load tests.

Collect a single set of identifiers that ties the protocol to the exact PC or server: manufacturer serial number, internal inventory tag (sticker/plate), model and configuration code. For network parts, record MAC addresses of all interfaces that are delivered per spec (built-in ports and additional cards).

Record completeness as a separate line: power supply, cables, mounting rails, documentation, image media (if provided). This reduces disputes when a device arrives but “a small accessory” is missing.

BIOS/UEFI: what to check and how to record it

In BIOS/UEFI record the version (and build date if available), boot mode (UEFI/Legacy), boot order and critical options from procurement requirements. If the customer requests Secure Boot, TPM or disabling boot from external media, state explicitly “enabled/disabled” with date and signature.

OS/image and specification compliance

If the OS is part of the delivery, record its edition and build number, activation status and a list of key drivers (chipset, network, video/storage controller). If the OS is not included, state that tests were run from a service environment and specify which one.

Before tests, verify the ordered specification: CPU model, total RAM and module count, drive types and capacities, presence of RAID controller, models of network adapters. Prefer concrete values over “matches”. Example: “CPU: 1x Intel Xeon ..., RAM: 4x32 GB, Disk: 2x1.92 TB SSD, NIC: 2x10GbE”.

If you keep internal production mapping, add the order/batch number and assembly location. This speeds up traceability if acceptance finds a discrepancy.

Memory tests: minimal set and recording results

Memory testing in FAT is not a formality but a way to catch rare failures before shipment: bad cells, instability under load, module incompatibility and problematic slots. Disputes at incoming inspection often stem from the protocol not showing what was tested and how the error was localized.

For batches, perform a quick test over 100% of memory on each device and an extended test on a sample. For single deliveries and critical systems (server, workstation, medical PC) include the extended scenario for every unit. Practical minimum: a quick run per device (one pass or 30–60 minutes) plus an extended run (4 passes or 4–8 hours) on 10–20% of the batch, and on every unit after repair or module replacement.

Agree in advance which tool will be used (for example, UEFI standalone test, MemTest86, memtester in Linux or OS memory check) and record consistent fields.

What to record for memory in the protocol:

• installed RAM capacity and actually tested RAM capacity (GB), mode (ECC on or off if applicable)
• tool and version, launch environment (UEFI/OS), start and end date/time
• number of passes, duration, result (PASS/FAIL)
• module map: model and serial number of module, slot (e.g. DIMM_A1), actual frequency/parameters
• on error: address (or range), expected/actual value, bit mask, test number, suspected module and slot

“Memory error” is not acceptable wording. Provide values so incoming inspection can confirm the problem is gone after replacement, not just “we reran the test”.

After replacing a module or moving it between slots, repeat the same scenario: quick run over 100% then extended run of at least 4 passes. If the error persists, note whether it moved with the module to another slot and record the outcome: module replaced or faulty motherboard slot identified. Attach the test log to the protocol (file or printout).

Drives and RAID: what to check and how to describe it

Disputes about drives usually arise from two issues: “the wrong disk” and “the wrong health state”. So it’s important not only to run tests but to record clear fields that are easy to verify at incoming inspection.

For each SSD/HDD record model and serial number, interface (SATA/SAS/NVMe), capacity, firmware (if available) and final status (Pass/Fail). Then add health: a SMART snapshot with key attributes (errors, reallocated sectors, CRC, power-on hours). For SSDs record wear indicators (e.g. Media Wearout/Percent Used, Total Host Writes).

Surface checks should be safe: a quick read scan plus a short read/write test on a small area (to avoid consuming drive lifetime). Speed is useful to record but keep it as a general range confirming normal operation.

For NVMe include temperature and throttling checks: maximum temperature during test, whether Thermal Throttling occurred (Yes/No) and under which conditions (load duration, profile).

If there is RAID, describe it so acceptance can compare one-to-one: controller (model, firmware), RAID level, array composition (which disks by serial), size, cache policy, state (Optimal/Degraded). Agree the rebuild test in advance: either perform a full rebuild on the stand with start and end timestamps, or explicitly state that rebuild testing was not performed per contract. The key is to avoid surprises at incoming inspection.

Ports and interfaces: quick repeatable checks

Ports are a common source of disputes: “it doesn’t see the flash drive”, “no display”, “link is flaky”. To avoid long back-and-forth, do short functional checks with the same recording method.

First list which interfaces are present by configuration and where they are located (front/back panel, expansion slots). This ensures the inspector checks the same ports and not an expected extra port.

A minimal set takes minutes if you prepare a reference peripheral set (USB 3.x flash drive, headset, cables, monitor, patch cord, loopback for COM):

• USB Type-A/Type-C: plug in flash drive, read/write a test file, record port mode (USB 2.0/3.x per system/utility)
• Video (HDMI/DP/VGA): output image, change resolution, check for artifacts
• Audio: play a test tone and do a short recording from a microphone
• LAN: link, negotiated speed (1G/10G), simple data transfer (ping and file copy/iperf by agreement)
• COM and other ports: test via loopback or agreed device

If there are multiple LAN ports, test each separately and indicate which physical port was tested (LAN1/LAN2 by label or by OS interface name).

How to record: one line per port (or per group of identical ports using the same method) — port and location, method (what device was connected and what was done), result (PASS/FAIL) and any measurement (link speed, USB mode), plus a short remark if needed.

Stress load and thermal control: how to do it properly

The purpose of stress tests in FAT is to reveal issues not visible in a “cold” check: overheating from poor heatsink contact, unstable power, errors under load, random reboots and throttling. This is especially useful for batch shipments and critical servers so the incoming inspection won’t ask “why does it fail after an hour?”.

What to load

Load should match the device role. For an office PC, CPU and memory stress is usually enough. For a graphics workstation include GPU. For servers load CPU, memory and storage subsystems, including RAID.

Scenarios usually fall into 3–4 directions: CPU+memory, GPU (if applicable), disks/RAID, and mixed load (closer to real work and better at catching power dips).

Record conditions in advance: room temperature, chassis position (rack or bench), fan mode (auto/fixed), BIOS/firmware versions. Otherwise comparing factory and acceptance results will be hard.

Which metrics to record

To avoid disputes, record measurable facts, not just “passed”:

• maximum temperatures of CPU/GPU/chipset/drives and time to reach them
• frequencies under load and evidence of throttling (yes/no, at which temperature)
• errors (ECC, WHEA, I/O): counts and extracts from event logs
• reboots, freezes, GPU driver resets (if any)
• final verdict: passed for the given duration and scenario

For batches, a short mixed run of 15–30 minutes and 5–10 minutes of peak is often sufficient. For critical systems (government, finance, medical) plan 2–4 hours of mixed load and a separate disk run of at least 60 minutes to reach thermal plateau and reveal rare errors.

Server checks: management, sensors and power

Servers differ from PCs by having a separate management channel (BMC/IPMI), more sensors and often redundant power. If you don’t test these at the factory, incoming inspection may find a server “powers on” but is not manageable remotely or complains about a fan.

Start by recording versions. In the protocol list BIOS/UEFI version, BMC firmware version, CPU microcode version and driver versions for key devices (network adapters, RAID/HBA, chipset). These are facts “at FAT time”, not promises to update later.

BMC/IPMI and remote access

The check is simple but must be provable. Typically record that you:

• logged into the BMC web interface/console with a test account
• saw inventory (CPU/RAM/drives) and sensor readings
• checked the event log (SEL) and saved its state (empty or list of entries)
• performed remote power on/off and confirmed the command executed

In the protocol note: “BMC access: OK, method: web/KVM, response time, screenshot of Sensors + SEL dump (attached)”.

Sensors, fans and power

For sensors record baseline values, not just “normal/abnormal”. Log CPU and intake temperatures, fan speeds (RPM) and status (Normal/Warning). If the factory floor was hot, note room temperature and load duration.

Verify power according to configuration. If there are two PSUs, record both and test redundancy: disconnect one supply for 10–20 seconds — the server should continue operating without reboot and the event log should show the expected message. Also note input type (AC), presence of dual inputs and that cables/clips are installed.

Example wording for acceptance: “PSU1/PSU2: Present, Normal. Failure test: PSU1 disconnected — no interruption, SEL entry: Power Supply AC lost (expected), after restore — Normal.”

Common FAT mistakes that turn acceptance into a dispute

Conflicts arise when a protocol reads like “overall OK” but doesn’t allow the inspector to quickly repeat key steps and get comparable results. This is especially true if factory and customer conditions differ but the document doesn’t say so.

Typical mistakes:

• protocol not tied to a specific device: batch lists exist but no per-serial sheet
• missing serial numbers and P/N of key components (RAM, SSD/HDD, RAID controller, PSU)
• no clear Pass/Fail criteria: “checked” is written but failure conditions are not defined
• no start/stop times or durations: “stress test was run” without timestamps and parameters
• test conditions differ from acceptance conditions but are not documented (temperature, power, network, BIOS/firmware versions)

Another problem is lack of original evidence. Without logs, resolving disputes is hard. Minimum attachments: raw test logs (files), utility versions and run settings, responsible person and timestamp for the package. If agreed, add checksums for the final PDF and log archive so incoming inspection can confirm files weren’t altered.

Example: memory was run for 2 hours at the factory but ECC mode and BIOS version were not recorded. At acceptance a different power profile or higher temperature produces single correctable ECC events. Without logs and parameters the dispute is over how the test was done, not the failure itself.

Short checklist for incoming inspection: what to quickly verify

Incoming inspection should take minutes, not days. With a proper FAT, you confirm that what arrived matches the order and key tests were passed.

On each unit it’s usually sufficient to quickly verify:

• identification: model, serial number, delivery contents, stickers/seals match the specification and protocol
• memory: protocol shows amount, tool, duration and result “0 errors” (it’s important to see test time, not just “OK”)
• drives and RAID: attached SMART without critical attributes, no read/write errors; RAID level, composition and status (Optimal/Healthy)
• ports and network: declared interfaces are present; LAN showed link and speed (1G/10G)
• load and temperature: stress duration, completion criteria, no errors and recorded temperatures/throttling

Also check the protocol itself: date and place of testing, signatures, BIOS/firmware and software versions, attached logs. If the supplier manufactures and integrates equipment locally (e.g. at a factory in Kazakhstan), request batch/order numbers so the document unambiguously ties to your delivery.

If any item is missing, record it immediately as an acceptance remark — otherwise the “was/was not” dispute is almost inevitable.

Example scenario: delivering PCs and servers with acceptance without re-testing

A school receives a batch of 40 desktop PCs for classrooms, and the regional data center gets 2 rack servers and a set of drives for RAID. Incoming inspection wants to quickly confirm the delivery matches the order and nothing was damaged during transit. Nobody wants to rerun many-hour tests.

FAT depth differs by device. For workstations speed and repeatability matter: confirm configuration identity, port functionality and absence of obvious defects. For servers proof is more important: stability under load, RAID correctness, sensors, power and manageability.

It’s usually enough if the factory provides artifacts that can be checked in 15–30 minutes on site: a FAT protocol for each unit (or for a serial range of identical PCs) with date and test methodology version, exported logs (memory, SMART/drive tests, stress tests for servers) with PASS/FAIL, photos of nameplates and labels (serial number, model, seals, stickers on drives and controller) and a summary list for the batch.

Incoming inspection typically does 2–3 quick steps:

1. Compare serial numbers and basic configuration against the list.

2. Run a short check: for PCs — drive and selective USB/video; for servers — RAID status and sensors.

3. Confirm logs from FAT belong to that device (matching serial number/asset tag in the report).

If protocols and logs are consistent across the batch, acceptance is smooth: the inspector confirms key points and deep testing stays with the factory.

FAT protocol template: structure, fields and attachments

A clear protocol should read the same at the factory and at incoming inspection. Goal: every result is tied to a serial number and backed by logs, not by “checked”.

Recommended protocol structure

Keep the document concise but formal. Usually 4–6 pages per device is enough; the rest goes into appendices.

• Header: customer, contract/order, FAT site, date, protocol number, template version
• Device identification: model, serial number, inventory/asset tag (if any), completeness, BIOS/UEFI version, test environment composition
• Configuration: CPU, RAM (total and module composition), drives and RAID (level, composition, firmware), network adapters, PSU (for servers)
• Tests table: all checks in one place, unified row format
• Conclusion: Pass/Fail status, list of deviations (if any) and corrective actions (replacement, retest)
• Signatures: executor, QA/OTK controller, customer representative (if present)

How to format the test table and logs

Keep the same fields in every row of the table:

• Test: what was checked (e.g. RAM stress, SMART/surface scan, USB ports)
• Method: utility/procedure and version
• Parameters: size, mode, thresholds (e.g. allowable temperature, error criteria)
• Duration: actual execution time
• Result: Pass/Fail + short measurable summary (errors 0, bad-blocks 0, speed within agreed range)

Name logs consistently and tie them to serial numbers. Example: SN123456_S200_memtest_2026-01-31.log and SN123456_S200_summary.pdf. This is convenient for large batches and device lines.

Delivery to the customer usually consists of one PDF protocol and an archive of raw logs. Optionally include checksums for the PDF and log archive so incoming inspection can quickly verify package integrity.

Next step — agree the template and test set in writing once for a device series and procurement requirements. After that acceptance typically reduces to serial number and configuration checks and verifying PASS status in the table with selective log checks.

If you buy or supply equipment where local manufacturing, traceability and unified test regulations matter, discuss the FAT format with the manufacturer in advance. For reference: GSE.kz (gse.kz) as a technology manufacturer and system integrator in Kazakhstan usually works with protocol-driven factory tests and support, which eases acceptance in the public sector, education, healthcare and corporate projects.