Soak Testing

// Definition

Running the system at expected load for a prolonged period (hours to days) to surface memory leaks, connection exhaustion, and slow degradation that short tests miss.

// Why it matters

Soak testing holds moderate load for hours or days to surface slow-burn problems a short test can't: memory leaks, connection-pool exhaustion, log-disk fill, gradual latency creep. QA value is patience — these bugs are invisible in a 10-minute run and catastrophic in week-long production.

// How to test

A sustained load-tool run + monitoring, not a functional test:
  • hold steady moderate load (e.g. 60% of peak) for 8–24h+
  • trend memory, connections, disk, latency over time — flat = healthy
  • a rising memory line with no plateau = a leak to chase
  • confirm scheduled jobs / token refreshes survive across the window

// Related terms

• Load Testing

  Verifying system behaviour under expected production load. Confirms the application meets performance targets at typical concurrent-user counts before release.

• Stress Testing

  Pushing the system beyond its limits to find the breaking point and observe failure modes. Asks: where does this fall over, and how does it recover?

• Spike Testing

  Subjecting the system to sudden, sharp load increases to verify it can absorb traffic surges (flash sales, news mentions) without collapsing or losing data.