Нагрузочное тестирование — это долго и дорого и это проблема. Почему так?

Бизнесы растут, нагрузки растут, а вот подходы к нагрузочному тестированию почти не развиваются. И проблема не только в людях, но и в самих подходах.

Типичная ситуация: умеем в продуктовую разработку, пока что не очень умеем в нагрузочное тестирование, давайте тогда работу с нагрузкой строить по принципам продуктовой команды. Наймём в каждую команду по нагрузочнику (если сможем), вместе с разработчиками и тестировщиками они все будут T-shaped, в едином продуктовом контексте помогать друг другу.

Вот только такой подход имеет обратную сторону: если команд и продуктов несколько, то каждый нагрузочник будет “вариться в собственном соку”. С ростом числа команд во весь рост встанут проблемы шаринга знаний между юнитами и найма новых нагрузочников. А еще это дорого.

Какие есть альтернативы? Давайте набирать не много людей, а много знаний. Сделаем полную автоматизацию и nohands-решения, чтобы любой человек в команде (разработчик, тестировщик) мог понять идею и запустить весь нужный инструментарий. Давайте работать с нагрузочным тестированием как с сервисом.

В докладе расскажу о нашем опыте в Самокате — как мы строим PerfOps-команду. Расскажу о концепции, подходе к её реализации, инструментарии и процессе внедрения сервисной модели для нагрузочного тестирования.

Надеюсь, доклад будет интересен
* стейкхолдерам нагрузочного тестирования: как со стороны разработки, так и бизнеса — оценить плюсы и минусы сервисной модели для работы с нагрузкой, примерить эту модель на специфику своего бизнеса;
* а ещё ИТ-инженерам: надеюсь, всё большему их числу предстоит пользоваться PerfOps-инструментарием в ближайшем будущем.