> This sounds really interesting and like good engineering (tm), would you mind sharing which company this was for? Maintaining good blackbox e2e tests and the

> This sounds really interesting and like good engineering (tm), would you mind sharing which company this was for? Maintaining good blackbox e2e tests and the infrastructure is one thing, finding time (and space in the roadmap) to do that and load test on top of that is a great engineering indicator IMO. You’re really hearing about a unique case. The engineering org there had basically no consistency across teams/projects. Every product team was independent and responsible for their own services. So different teams deployed their services to different infrastructure with different programming languages, different frameworks, different databases, different monitoring and logging solutions, and so on. I was in the QA org and was embedded as an SDET on a particularly well-functioning product team and had a lot of independence to solve problems as I saw fit with support from great forward-thinking devs. I got their e2e/integration tests to a point where it was super easy for devs to add at least some new tests themselves, which freed up some of my time to slowly build out a performance test. But, very few other teams were getting to the point of doing any non-trivial load testing. I tried evangelizing Locust a little bit, but there wasn’t enough demand for it without a turnkey solution - something a bit hard to make without much consistency across teams. Not to mention the culture and processes weren’t there to consolidate on a single solution anyhow. So, grass is always greener. That company’s engineering org has since been decimated by layoffs and outsourcing unfortunately.