Stress Testing

// Definition

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?

// Why it matters

Stress testing pushes past expected load to find the breaking point and — more importantly — how the system fails. Does it degrade gracefully (shed load, queue, 503 cleanly) or fall over (cascading timeouts, data corruption)? QA cares because the failure mode determines your incident severity.

// How to test

Like load testing, this is a load-tool job. The stress-specific design:
  • ramp beyond peak until something breaks — find the saturation point
  • observe the failure mode: graceful (clean 503 + recovery) vs catastrophic
  • verify recovery: after load drops, does it return to baseline unaided?
  • watch for data integrity issues under partial failure (the dangerous ones)

// Related terms

• Load Testing

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

• 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.

• Soak Testing

  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.