«Playwright сейчас модный, Selenium старый, Cypress удобный». Именно так чаще всего звучит выбор фреймворка на планировании — и именно поэтому команды потом полгода разгребают последствия решения, принятого за один созвон.

Я сам проходил этот выбор не один раз, и каждый раз он оказывался сложнее, чем «взять модное». Дальше — разбор архитектуры, реальных ограничений и того, во что выбор фреймворка выливается через год, когда тестов становится не 20, а 2000.

Есть карьерная история, о которой почти никто не рассказывает.

Ты уходишь на работу мечты… чтобы через месяц захотеть вернуть старую.

На собеседовании всё выглядело идеально: интересные задачи, сильная команда, адекватный руководитель, прозрачные процессы. Ты увольняешься с ощущением, что наконец‑то сделал правильный выбор.

А потом проходит несколько недель.

Новый руководитель оказывается сложнее предыдущего.

Процессы еще более хаотичными.

Обещания, которые звучали на интервью, не совпадают с реальностью.

И появляется мысль:

Я провёл несколько лет в роли Leadа нагрузочного тестирования. И если честно, долгое время это была специализация из разряда “да зачем оно надо, это ваше НТ, купим ещё серваков и железа клевого”. Сейчас всё изменилось. Расскажу почему.

Железо подорожало. И всё подходы перестали работать Ещё пару лет назад в компаниях была простая и рабочая логика: сервис начинает тормозить под нагрузкой, не беда, докидываем железо. CPU не справляется меняем на лучшее! Память кончается, add плашек или буст. Не дорого, быстро и предсказуемо.

Потом серверное железо резко подорожало. Развитие ИИ, санкции, курс $, логистика и всё это потянуло цены вверх. Но не важно почему, важнее что это произошло. И внезапно оказалось, что “докинуть железа” перестало быть дефолтным решением. Бюджеты компаний не резиновые, а проблемы с производительностью никуда не делись.

И вот тут команды начали задавать вопросы, которые раньше не задавали.

Новые вопросы, новые задачи Раньше вопрос звучал так: “Сколько серверов докупить?”

Сейчас он звучит иначе: “А насколько эффективно то, что уже есть?”

Это принципиально другая постановка задачи. И она требует принципиально другой работы.

Конкретно команды начали смотреть на вещи, которые раньше просто игнорировались:

Конфигурация. Один и тот же сервис на одном и том же железе может вести себя кардинально по-разному в зависимости от конфига. Размер пула потоков, таймауты, параметры GC, настройки connection pool — всё это влияет на производительность под нагрузкой. Раньше эти параметры часто оставляли дефолтными. Сейчас их начали трогать осознанно.