Ответ
Я ищу возможность для профессионального роста и работы над более сложными и масштабными задачами в области QA.
В моей текущей компании я достиг значительных результатов: построил с нуля фреймворк автоматизации, который покрывает более 90% регрессионных сценариев, и интегрировал его в CI/CD. Однако сейчас я столкнулся с "потолком" в развитии: основные процессы автоматизированы, и задачи стали более рутинными — поддержка и расширение существующих тестов.
Меня привлекают проекты со сложной архитектурой, такие как:
- Распределенные системы и микросервисы, где интересно решать задачи тестирования resilience (отказоустойчивости), контрактного тестирования (Pact) и работы с очередями сообщений (Kafka).
- Углубление в нефункциональное тестирование — performance (например, с JMeter или k6) и security testing. Я начал изучать это самостоятельно, но хочу применять знания на практике.
- Внедрение современных практик, таких как shift-left testing, где QA-инженер активно участвует в проектировании архитектуры на ранних этапах, или использование методов машинного обучения для оптимизации тестовых наборов.
Например, я изучал, как можно писать тесты для отказоустойчивости в Kubernetes-окружении, и хотел бы реализовать подобное:
// Примерная логика теста на resilience (псевдокод)
@Test
public void testServiceResilienceOnPodFailure() {
// 1. Найти работающий pod основного сервиса
String podName = k8sClient.findPod("payment-service");
// 2. Имитировать его сбой
k8sClient.deletePod(podName);
// 3. Проверить, что система переключилась на другой pod и осталась доступна
await().atMost(30, SECONDS)
.until(() -> paymentServiceHealthCheck() == HEALTHY);
// 4. Проверить, что не было потерянных транзакций
assertNoFailedTransactionsDuringOutage();
}Я ищу команду, где тестирование — это стратегическая функция, а не формальность, и где есть пространство для инноваций и решения сложных инженерных задач.
Ответ 18+ 🔞
Блин, слушай, вот реально знакомая ситуация, ёпта. Сидишь такой, всё настроил, оттестил, фреймворк свой вылизал до блеска — и наступает эта самая рутина. Автоматы бегают, репорты сыпятся, а душа, блядь, требует чего-то посерьёзнее. Чувствую, что могу больше, а тут — потолок, как в комнате с низким багетом. Сам от себя охуел, как быстро всё сделал и уперся.
Ты прав, чувак, рутина — это пиздец как убивает. Поддержка тестов — это ж как мыть посуду после грандиозного зажора: процесс нужный, но кайфа ноль, волнение ебать куда-то испарилось. А тебя, я смотрю, уже на сложняк тянет, на архитектурные головоломки. Распределённые системы — это ж, блядь, отдельная песня! Там не просто «нажал кнопку — получил результат». Там один сервис чихнул, а другой, сука, с похмелья, и пошла такая пляска с бубном, что мама не горюй. Resilience-тестирование — это вообще высший пилотаж. Представь: ты сознательно ломаешь часть системы и смотришь, как остальное не развалится к херам. Это ж чистой воды саботаж, но во благо!
Твой пример с кубером — это прям в точку. Удалить под и ждать, что система не сдохнет — это ж надо иметь яйца, чтобы такое в продакшене проверять. Но без этого — никак, доверия к системе ебать ноль будет. И вот эта вся движуха с очередями (Kafka, блять), контрактами между сервисами (чтоб они друг другу не начали хуйню в ответах слать) — вот где сейчас реальный инженерный челлендж, а не тупое кликанье по кнопкам.
И то, что ты про нефункциональку заговорил — это отдельный респект. Все бегут фичи пилить, а то, что сервис под нагрузкой ляжет как суслик или дыры в безопасности размером с чёрную дыру — всем похуй, пока не прижмёт. Перформанс-тесты писать — это ж надо понимать, где это узкое горлышко, которое всё тормозит. А security — это вообще тёмный лес, где на каждом шагу подозрение ебать чувствуешь ко всему подряд.
Слушай, а идея со shift-left — это вообще бомба. Прийти к архитекторам и разработчикам на этапе, когда они только схемки рисуют, и сказать: «Мужики, а давайте вот тут сделаем так, чтобы это потом можно было нормально протестировать, а не костылять потом, как уроды». Это ж уровень влияния на продукт совершенно другой, не «принеси-подай-проверь», а реальное проектирование.
Короче, я тебя прекрасно понимаю. Ты перерос свою песочницу. Тебе нужен не просто проект, а, блядь, полигон, где можно развернуться. Где тестирование — это не обуза для галочки, а часть инженерной культуры. Где можно прийти с идеей «а давайте завтра устроим всем сервисам адский стресс-тест» и тебе ответят не «иди нахуй», а «вау, круто, давай спланируем». Такие места есть, их просто надо искать. И судя по тому, как ты мыслишь и что уже сделал, ты туда точно пройдёшь. Дерзай, там реально интересно будет.