EMZETT.Verification
In short: Checking whether a system, component or statement actually meets the expected requirements — in a hardware context, for example, checking whether a component is correctly detected, compatible and functional.
In more detail: Verification is to be distinguished from validation: verification checks “was it built right?” (does it meet the specification), validation checks “was the right thing built?” (does it meet the actual need). For hardware, part of verification runs automatically at system startup (POST — Power-On Self-Test).
In Depth
POST as automated hardware verification
At startup, a PC goes through the POST (Power-On Self-Test): the BIOS/UEFI checks in sequence whether the CPU, RAM, graphics card and other core components are detected and basically functional, before the operating system even starts. If a test fails, the system typically reports this via beep codes (whose exact sequence is coded differently depending on the BIOS manufacturer) or an error message on screen, even before a graphical interface is available — this is exactly why beep codes are so important: if the screen output itself is the problem (e.g. a defective graphics card), the beep sound is often the only available diagnostic information. This hardware verification runs again on every restart, so that, for example, newly installed or replaced RAM is immediately recognised, without needing separate manual configuration.
Verification vs. validation
Verification is to be cleanly distinguished from validation, a difference that’s also important outside the hardware world (e.g. in software development, quality management): verification checks “was it built right?” — does the result match the given specification? Validation, by contrast, checks “was the right thing built?” — does the result actually meet the real need, regardless of whether the specification itself made sense? A RAM stick, for example, can pass verification (it works exactly as specified) but still be unsuitable for the specific use case (validation fails), if, say, the capacity isn’t enough for the planned application.
Integrity and authenticity
Beyond pure existence and functionality checks, verification in a broader sense also includes checking the integrity and authenticity of components and firmware. Whether a downloaded firmware update really comes from the manufacturer is usually checked via a digital signature — the firmware is signed with the manufacturer’s private key, and the device verifies this signature with the corresponding public key before installation. If the check fails, the update is rejected, which prevents tampered or forged firmware from being installed.
Practical diagnostic tools
For verifying individual components beyond the POST, specialised diagnostic software exists: Memtest86 tests RAM for bit errors over hours using various test patterns, CrystalDiskInfo reads out the SMART values of SSDs/HDDs (operating hours, error counters, estimated remaining lifespan), and stress-test tools like Prime95 or FurMark verify whether the CPU or graphics card remain stable under sustained load, without crashes or overheating.
See also: Authenticity