Software Reliability Growth Model

Testing Campaign

Ultimate defect count a 150

Detection rate b (per hour) 0.020

Test-clock speed 12 h/s

Live Readouts

Test time t

0.0 h

Defects found N(t)

Model m(t)

0.0

Discovery rate λ(t)

0.00 /h

Estimated remaining defects (a − m(t))

150.0

How it works

The Goel-Okumoto model treats defect discovery during testing as a non-homogeneous Poisson process (NHPP). The expected cumulative number of defects found by test time t is:

m(t) = a · (1 − e^(−bt))
λ(t) = dm/dt = a·b·e^(−bt)

where a is the total number of defects the process would eventually uncover given infinite testing, and b is the per-defect detection rate. λ(t) — the instantaneous discovery intensity — starts at a·b and decays exponentially as the easy bugs get found first, exactly the diminishing-returns curve real QA teams see.

A process with mean function m(t) is statistically equivalent to drawing a total defect count N ~ Poisson(a) once, then giving each of those N defects an independent discovery time ~ Exponential(b). That is exactly how this simulator seeds a run: it samples the defects up front and reveals each one at its sampled time as the test clock advances.

Orange bars — the actual (stochastic) cumulative defect count per time bin, one run of the random process.
Blue curve — the theoretical model m(t) the bars should fluctuate around.
a slider — raises or lowers how many defects this codebase ultimately contains.
b slider — how fast testing finds them; a mature test suite has a higher b.

This is the same class of model (Goel-Okumoto, 1979) used in real software reliability engineering to decide when a build is stable enough to ship, and connects directly to the article's defect-density idea: density is just m(t) normalized by codebase size.

Actual cumulative defects (bars) Model m(t) (curve) Test-clock playhead

⚠ Couldn't load the 3D engineThree.js failed to load from the CDN. Check your connection and reload.