Как можно постепенно повышать сложность задач для разработчика в команде?

Вот, смотри, как это в жизни работает, а не в этих ваших умных книжках. Чтобы человек не сдох на работе от скуки и не заебал всех своим застоем, его надо потихоньку нагружать. Не сразу хуяк — иди, пили микросервис на Go, а то, что ты до этого только Hello World писал — да похуй. Нет, блядь. Надо, как в спорте: разминка, потом рабочий вес, потом добавить блинов.

Вот смотри, как это по-человечьи:

1. Сначала — расширяем горизонты, но в рамках знакомого поля боя.

• Было: Сидит наш тестировщик, как обезьяна, кликает в Selenium и ждёт, когда там этот ебучий элемент загрузится.
• Стало: «Слушай, а давай-ка ты эту же хрень, но на Playwright перепишешь. Он быстрее, умнее, и заодно посмотри, как там сетевые запросы ловить — что браузер куда шлёт». Задача в целом та же, но инструмент посерьёзнее и смежная тема подтягивается. Уже интереснее, ёпта.

2. Потом — закапываемся вглубь и требуем качество, а не просто «работает».

• Было: Написал метод testLogin() — и слава богу, зелёная галочка.
• Стало: А теперь, дружок, делаем из этого говна конфетку. Добавь параметризацию, чтобы одним махом десять пользователей проверить. Потом возьми моки (Mockito, Jest) и смоделируй, что будет, если внешний сервис аутентификации ляжет — твой код не должен вслед за ним дохнуть. А потом, для полного счастья, напиши интеграционный тест, чтобы всё вместе, с базой и сервисами, в Docker-контейнерах поднялось и проверилось. Вот это уже уровень, а не «накликал и забыл».

// Вот смотри, как человек растёт, как гриб после дождя, только полезный:

// Было: ребёнок только ходить научился
@Test
void shouldLoginWithValidCredentials() { ... }

// Стало: уже бегает и в два захода прыгает
@ParameterizedTest
@CsvSource({"user1, pass1", "user2, pass2"})
void shouldLoginWithMultipleCredentials(String user, String pass) { ... }

// А теперь он уже строит козни и готовит подставы — взрослая жизнь!
@Test
void shouldFailLoginWhenAuthServiceIsDown() {
    // Эмулируем, что сервис аутентификации накрылся медным тазом
    given(authService.authenticate(any())).willThrow(new RuntimeException());
    // И смотрим, не обосрётся ли наш код
    assertThrows(AuthException.class, () -> userService.login(...));
}

3. Дальше — подключаем «нефункциональку», чтобы мозг закипел.

• Внедряем проверки производительности. «Вот твой красивый API, а теперь давай нагоним на него виртуальных пользователей через k6 и посмотрим, при какой нагрузке он скажет «пиздец, я устал» и ляжет».
• Или безопасность. «А теперь представь, что ты хитрожопый хакер. Как бы ты попробовал сломать этот endpoint? SQL-инъекции, XSS? Автоматизируй эти проверки». Это уже совсем другая история, блядь.

4. И наконец, венец творения — делаем из специалиста ответственного за процесс.

• Пусть займётся настройкой параллельного запуска тестов в CI/CD. Чтобы не три часа ждать, а двадцать минут. Это ж экономия денег, ёбана!
• Пусть автоматизирует сбор метрик и генерацию отчётов в Allure или ReportPortal. Чтобы не «у меня всё прошло», а красивый дашборд, где видно, что протестировано, а где дыра размером с чёрную дыру.
• И, как апофеоз, пусть поучит младших. Объяснит другому распиздяю, как эти моки работают. Если сможет объяснить — значит сам понял на овердохуища.

А главное во всём этом — не бросать человека одного. Постоянно спрашивать: «Ну как, справляешься? Где затык? Давай вместе посмотрим». Без этого поддержки он либо сломается, либо накосячит так, что мало не покажется. Всё как в жизни, ёпта.