I'm not unrealistic - functional requirements are hardly ever complete, and they're almost always better than scalability and capacity planning.

Call me old fashioned, but I don't like messing around with production. I think you can reasonably scale down production environments and simulated wan networks packet loss/latency. I can't imagine a platform moderate importance not having some sort of benchmarking and scalability as part of their pre-prod pipeline automated acceptance criteria. It feels like this work would fall under that engineering role (again, performance test engineer or devops/sre).

Anyway, I think I chafe at the name more than anything. I know nonlinear dymanics, stress testing, queuing theory, et al and it just feels overly glib for what should be the most serious sort of activity a company considers.

If I may be pedantic for one moment for the sake of clarity:

> The more confident you are that your test environment matches your prod environment, the less you need this

I'd also add "workload" alongside "environment", which is often challenging to accurately simulate.

That's great, until your service scales to the point where it's not possible to simulate prod in test.

chaos testing can be part of SRE practice, its mostly around reliability of systems. I am not sure why someone in the comments is confusing it with functional testing or load testing.