Introduction
Optimizely is an experimentation platform that helps developers deliver personalized digital experiences. Product, engineering, data, and marketing teams from over 9,000 brands rely on Optimizely to build and run A/B tests.
To enable its customers to quickly and safely rollout and rollback code, Optimizely must deploy high-velocity releases without compromising on quality. But automated testing on their on-premise grid was highly ineffective, making it a significant blocker for the team. In addition to ongoing maintenance required to keep the grid up and running, ad hoc troubleshooting and capacity constraints were alarmingly common.
“We worried that if we didn’t provide advanced tools to our engineers, we might be sacrificing some aspect of our quality process,” says Brian. Accordingly, the frustrated team turned to a competitor cloud testing platform. But they continued to struggle because of the service provider’s unreliable infrastructure and frequent downtimes.
Looking for a more stable solution, the team switched to BrowserStack. The result? Improved quality, no maintenance overheads, and a happier team.

Engineers frustrated with the on-premise grid
Optimizely’s on-premise grid had several limitations, rendering it ineffective.
In the beginning, the team mainly ran headless browser tests and a limited number of browser-based tests. But when they began writing end-to-end tests for real browsers, they quickly discovered how complex and unreliable these test suites were compared to unit tests for headless browsers. Real end-to-end tests were more prone to failure and non-deterministic results. Creating this end-to-end test suite, therefore, required all available engineering bandwidth for several months.
But engineering bandwidth was also required to keep the on-premise grid up and running. Moreover, the on-premise grid was inefficient in highly parallelized test environments, forcing engineers to run tests sequentially. These bottlenecks, coupled with the added overhead of building and maintaining the on-premise grid, frustrated the engineers.
In fact, frustration levels were so high that an in-house metric was invented to monitor Developer Pain Index (DPI). “DPI is a mathematical function of the time it takes to run the entire test suite, times the average success ratio. The goal is to see DPI shrinking over time,” says Brian.