A perfect observed score can still contain substantial uncertainty
If five prototypes pass a test, the observed failure count is zero. That is useful information, but it is a small window into the possible population. The units may share a material lot, machine setup, or hidden defect. The test may also omit the condition that causes failure in actual use.
NIST's reliability guidance explains why a lack of failures limits what can be learned about failure rates and mechanisms. A successful test can demonstrate that a configuration operated under particular conditions while providing little evidence for a broad numerical reliability claim.
State the observation plainly: five identified units completed the defined sequence without the specified failure. Avoid replacing that sentence with 100 percent reliable. The former lets a reader assess the evidence; the latter erases the sample size and exposure that determine its meaning.
A simple hypothetical probability calculation
Assume, only for illustration, that each independently selected unit has the same failure probability p in one defined test and outcomes are independent. The probability of observing no failures in n units is (1 − p) raised to n. If the true failure probability were 10 percent, five units would all pass with probability 0.9 to the fifth power, about 59 percent.
That means five passes would not be surprising even with a 10 percent underlying failure probability under this model. With thirty independent units, the probability of all passing at that same failure rate is about 4.2 percent. These calculations illustrate the effect of sample size; they are not a recommended test plan for every product.
Under the same binomial assumptions, a one-sided 95 percent upper bound after zero failures is 1 − 0.05 raised to the power 1/n. For thirty units it is about 9.5 percent. The bound is much less reassuring than the phrase thirty out of thirty might initially sound.
The formula does not repair nonrandom selection, dependent samples, an irrelevant test, or an unclear failure definition. It applies to a stated model of a defined event. Time-to-failure, repairable systems, wear-out, and repeated cycles may require different models.
Do not count cycles as independent products
A single latch cycled one thousand times provides information about that latch under that sequence. It does not equal one thousand independently manufactured latches each tested once. Repeated cycles share the same geometry, material, and manufacturing history, and wear can make successive outcomes dependent.
Likewise, ten parts from one carefully tuned prototype build may not represent variation across future production lots. Record the source and selection method. If a supplier hand-picked the best samples, the result addresses those samples rather than a random cross-section of production.
Separate unit count, cycles per unit, and accumulated exposure in the report. Each can matter, but combining them into one impressive total hides the structure of the evidence. A table with individual unit IDs and outcomes is more informative than a single aggregate number.
Use failures to learn, not merely to reduce a score
When a failure occurs, preserve the part and record when and how it happened. The failure mechanism can guide a design correction more effectively than adding more successful demonstrations. Distinguish a test-fixture failure from a product failure without discarding ambiguous events prematurely.
After a design change, identify the new configuration and the evidence that must be repeated. Do not pool old and new versions into one reliability estimate unless a justified analysis supports doing so. The revised version has different assumptions.
Accelerated testing can expose weaknesses, but translating a harsher test into ordinary service life needs an appropriate model. A higher load or temperature can introduce a different failure mechanism. More severe is not automatically more representative.
Choose the next study from the intended claim
If your immediate decision is whether a mechanism is worth refining, a small exploratory test may be sufficient. If you want to promise a service life, compare suppliers statistically, or release a consequential product, the evidence requirement is much greater. Define the claim first and obtain suitable statistical and engineering support.
Your report should identify the tested population, configuration, selection method, event or duration, failure definition, and all outcomes. If a confidence calculation is included, state the model and assumptions alongside it. Do not present a confidence level as a guarantee about every future unit.
The useful conclusion from a small zero-failure study is bounded progress: the tested units succeeded under these conditions, and these uncertainties remain. That is enough to guide a responsible next step without pretending that a prototype demonstration has measured a population perfectly.