ThreadQA | Олег Пендрак

Что выбрать: ручное или автоматизированное тестирование? Когда ты решаешь идти в тестирование, перед тобой по сути два варианта входа Можно сразу целиться в автоматизацию, а можно начать с ручного тестирования и прийти к автотестам чуть позже. Оба пути нормальные, просто подходят разным людям 1️⃣Путь первый — сразу в автотесты Это вариант для тех, кто не боится кода и хочет быстрее выйти на хорошие деньги Ты сразу учишь язык, например Java или Python, разбираешься в API и пишешь первые автотесты. Да, на старте тяжелее, потому что приходится грузить в голову больше нового Зато ты сразу попадаешь в ту лигу, где платят почти как разработчикам, и не теряешь время на промежуточную ступень 2️⃣Путь второй — через ручное тестирование Это более спокойный вход, особенно если ты пока совсем не дружишь с кодом Ты начинаешь с ручных проверок, понимаешь логику продукта, учишься думать как тестировщик и работать с багами. Порог входа тут ниже, и первую работу часто найти проще А уже потом, освоившись, ты потихоньку подтягиваешь код и переходишь в автоматизацию, опираясь на реальный опыт Какой путь выбрать? Если тебе ок с программированием и хочется быстрее к высокой зарплате — иди сразу в автотесты Если хочется мягкого старта и сначала почувствовать профессию — начни с ручного и двигайся к автоматизации по ходу Нет единственно правильной двери, есть та, которая подходит именно тебе Но важно понимать одно: куда бы ты ни зашёл, финальная точка всё равно автоматизация, потому что именно там и деньги, и спрос, и интересные задачи

Зарплаты в сфере тестирования Я часто общаюсь с людьми, которые только начинают думать насчет работы в айти, и почти у всех одна и та же установка, что туда берут только программистов со знанием высшей математики за плечами На самом деле нет, тестирование как раз отличный пример профессии, куда реально зайти без технического прошлого Тут важнее не диплом, а внимательность Чтобы найти баг, не нужно быть гением математики. Нужно замечать детали и любить разбираться, почему что-то работает не так, как задумано Я видел кучу ребят, которые пришли в тестирование из продаж, бухгалтерии и преподавания, и у них всё получилось Сколько платят? Я недавно смотрел свежую статистику по зарплатам в автоматизации тестировании за 2026 год, и вот реальные цифры по рынку 1️⃣ Джуниор получает от 120 до 180 тысяч 2️⃣ Мидл уже от 180 до 280 тысяч 3️⃣ Сеньор зарабатывает от 280 до 400 тысяч То есть даже на старте доход вполне ощутимый, а не работа за еду и строчку в резюме Ручное тестирование — это когда ты проверяешь продукт руками, кликаешь и смотришь, всё ли на месте Автоматизация тестирования — это следующий уровень, тут ты пишешь код на Java или Python, который проверяет продукт за тебя, прогоняет сотни сценариев за минуты и ловит баги без твоего участия И спрос на таких людей выше, и платят им заметно больше, чем ручным тестировщикам В автоматизации ты реально влияешь на продукт и ловишь баги до того, как их увидит живой пользователь Для меня это до сих пор смесь логики, любопытства и детективного азарта, когда сидишь и ищешь, где же на самом деле всё развалилось Если коротко, тестирование — это спокойный и честный вход в айти без выгорания на старте Порог входа тут ниже, чем кажется со стороны, а вот потолок по деньгам и росту заметно выше, чем многие думают

Кем работать в IT? Грейды Начинаем небольшую серию постов для новичков Грейд — это уровень квалификации специалиста, который отражает его опыт, навыки, степень самостоятельности и ответственность в работе Расскажу, как это выглядит на практике в автоматизации, и за что реально отвечает человек на каждой ступени 1️⃣Джуниор Это старт, и от тебя пока не ждут самостоятельности Ты пишешь простые автотесты по уже готовой структуре, чинишь упавшие сценарии, добавляешь проверки в существующие классы. Тебе дают понятную задачу, а ты её аккуратно закрываешь Главная зона ответственности джуна это не сломать чужое и научиться. Спрашивать тут нормально и даже нужно, никто не ждёт, что ты знаешь всё 2️⃣Миддл Это рабочая сила любого проекта, человек, который тащит основной объём задач Ты сам пишешь автотесты с нуля, понимаешь архитектуру фреймворка, разбираешься в API и UI, умеешь читать чужой код. Тебе кидают задачу общими словами, а ты сам решаешь, как её сделать Зона ответственности мидла это закрывать задачи самостоятельно и не дёргать старших по мелочам. Ты уже не задаёшь вопрос как, ты задаёшь вопрос зачем 3️⃣Сеньор Это человек, который отвечает не за отдельные тесты, а за подход в целом Ты проектируешь архитектуру автотестов, выбираешь инструменты, задаёшь стандарты, помогаешь младшим и видишь проблемы наперёд. К тебе идут, когда непонятно, как лучше сделать Зона ответственности сеньора это технические решения и качество всего автотестового хозяйства. Ты думаешь не про один тест, а про то, как будет жить весь проект через год 4️⃣Тимлид Тут начинается история уже не столько про код, сколько про людей Ты ведёшь команду автоматизаторов, распределяешь задачи, растишь ребят, проводишь созвоны один на один, общаешься с менеджментом и закрываешь то, что мешает команде работать. Код ты ещё пишешь, но уже заметно меньше Зона ответственности тимлида это люди и процессы. Чтобы команда была здоровой, мотивированной и стабильно выдавала результат, отвечаешь именно ты 5️⃣Техлид А это про техническое видение всего направления Ты определяешь, куда движется автоматизация в проекте или компании, какие технологии берём, как строится тестовая инфраструктура и куда мы идём в долгую. Ты тот, кто принимает крупные технические решения и отвечает за них Зона ответственности техлида это стратегия и архитектура на уровне всего продукта. Ошибка тут стоит дорого, поэтому и спрос высокий Грейд — это не про годы в профессии, а про уровень самостоятельности и масштаб задач Можно сидеть три года и остаться джуном, а можно за полтора дорасти до крепкого мидл Всё решает не время, а то, насколько большие задачи ты способен взять и довести до конца сам Джун учится и закрывает простое, мидл сам тащит задачи, сеньор отвечает за подход и архитектуру Дальше развилка, тимлид уходит в людей и процессы, а техлид в технологии и стратегию Это два разных пути роста, и оба классные, просто выбираешь, что тебе ближе, вести людей или вести техническую часть В следующем посте разберем примерные цифры по зарплатам в IT🤝

⚡️СПИСОК БАЗОВЫХ ТЕРМИНОВ ДЛЯ НОВИЧКОВ В IT Сохраняйте себе как шпаргалку, любые непонятные слова из следующих постов можно будет посмотреть здесь и понять, о чем речь Для удобства можно также использовать поиск на канале по ключевым словам Python — это язык про простоту и скорость старта. На нём пишут автотесты, скрипты, обработку данных, машинное обучение и бэкенд. Идеальный первый язык, потому что читается почти как обычный английский Java — это рабочая лошадка больших компаний. На ней делают серьёзный бэкенд, банковские и корпоративные системы, Android приложения и кучу автотестов. Чуть строже на старте, зато спрос огромный JavaScript — это язык всего, что крутится в браузере. Кнопки, анимации, интерактив на сайтах, это всё он. Сегодня живёт и на бэкенде через Node.js, так что закрывает и фронт, и сервер TypeScript — это, по сути, JavaScript с дисциплиной. Добавляет типы, чтобы ошибки ловились ещё до запуска. На больших фронтенд проектах его любят именно за порядок C# — это ответ от Microsoft, очень близкий по духу к Java. На нём пишут бэкенд, десктоп приложения под Windows и игры на движке Unity C++ — это язык про скорость и контроль над железом. Там, где важна максимальная производительность, игры, движки, нагруженные системы, берут именно его. Мощный, но требовательный к программисту C — это дедушка многих языков и основа низкоуровневого программирования. На нём пишут операционные системы и прошивки, где нужно общаться с железом напрямую Go — это современный язык от Google, заточенный под высокие нагрузки и облака. На нём делают быстрые сетевые сервисы и микросервисы, ценят за простоту и скорость работы Kotlin — это более удобная замена Java, особенно в мире Android. Сейчас это основной язык мобильной разработки под Android, и автотесты на нём тоже пишут Swift — это язык для всего эппловского. iPhone, iPad, Mac приложения делают именно на нём. Если тебя тянет в iOS, путь лежит через Swift PHP — это ветеран веб разработки, на котором держится огромная часть сайтов. Многие его ругают, но вакансий по нему всё ещё полно, особенно вокруг WordPress и старых проектов Ruby — это язык про удобство и удовольствие от написания кода. Известен в основном по фреймворку Rails, на котором быстро поднимают веб приложения Rust — это новая звезда про безопасность и скорость одновременно. Дарит производительность уровня C++, но защищает от целого класса ошибок с памятью. Учить тяжело, но он явно про будущее SQL — это не совсем язык программирования, а язык запросов к базам данных. Через него ты достаёшь, фильтруешь и меняешь данные. Тестировщику он нужен почти всегда Тачка — сервер на Linux в компании с доступом через консоль Дёрнуть ручку — это сделать запрос к API. Ручка это конкретный эндпоинт сервера, ты в него стучишься и получаешь ответ Покурить доку — это пойти почитать документацию. Звучит как отдых, но на деле ты сидишь и разбираешься, как работает библиотека или сервис Багу починить — это исправить ошибку в продукте. Баг это и есть та самая ошибка, из за которой что то работает не так, как должно Репа — это репозиторий, место где лежит код проекта. Обычно это GitHub или GitLab, туда ты заливаешь свои изменения Баг на фронте — это ошибка на стороне интерфейса, того что видит пользователь. Если ломается логика на сервере, говорят баг на бэке Джира — это таск трекер, где живут все задачи. В ней ставят задачи, двигают статусы и обсуждают, кто что делает Таска — это задача. Прилетела таска значит тебе дали что то сделать и завели это в трекере Тикет — это то же самое, что таска, просто другое слово. Чаще так называют задачу или обращение, особенно про баги БД — это база данных, где хранится вся информация продукта. Заказы, пользователи, статусы, всё это лежит именно там Залить — это отправить свой код в репозиторий. Залил изменения значит твой код теперь в общем проекте Смержить — это объединить свою ветку с основной. После мержа твои правки становятся частью общего кода Ветка — это отдельная копия кода, где ты спокойно работаешь, не ломая основную версию. Доделал, и потом мержишь обратно Ревью — это проверка твоего кода другим человеком перед мержем. Коллега смотрит, всё ли нормально, и оставляет комментарии Деплой — это выкатка кода на сервер, чтобы изменения увидели пользователи. Задеплоили значит новая версия уже работает Прод — это боевое окружение, то самое, которым пользуются реальные люди. Прод упал значит у пользователей сейчас всё сломалось, и это всегда стресс Стейдж и тест — это промежуточные окружения для проверок. Сначала катят туда, и только потом, когда всё ок, на прод Логи — это записи о том, что происходило в системе. Когда что то сломалось, первым делом лезут в логи искать причину Фича — это новая возможность в продукте. Фича тогл это переключатель, которым фичу можно включать и выключать без выката нового кода Хотфикс — это срочное исправление, которое катят вне очереди. Обычно когда на проде горит и ждать нельзя Мёржконфликт — это когда двое поменяли один и тот же кусок кода и система не знает, чью версию оставить. Приходится руками разруливать Ассерт — это проверка внутри теста, сердце всей автоматизации. Ты говоришь, я ожидаю вот такой результат, и ассерт сверяет ожидание с реальностью. Не сошлось, тест падает Флайки — это нестабильные тесты, которые то проходят, то падают без изменений в коде. Самая бесячая вещь в автоматизации, потому что им нельзя доверять и причину ловить тяжело Асинхронщина — это когда результат появляется не сразу, а с задержкой. Например, отправил запрос, а данные прилетают в базу или очередь через пару секунд. Тут нельзя проверять мгновенно, надо корректно дождаться Ретраи — это повторные запуски упавшего теста. Иногда их вешают, чтобы пережить случайные сбои, но это палка о двух концах, ведь ретраи легко маскируют настоящие флайки Атачменты — это вложения к отчёту о прогоне. Скриншоты, логи, тело запроса и ответа. Когда тест упал, именно атачменты помогают понять, что пошло не так, без них разбор это гадание Стактрейс — это след ошибки, цепочка вызовов, которая привела к падению. Выглядит страшно, но именно в нём прячется ответ, где и почему всё сломалось. Учись его читать, это супер навык Предусловия — это то, что нужно подготовить до теста. Создать пользователя, залить тестовые данные, выставить нужное состояние. Без них тест может упасть просто потому, что среда не готова Постусловия — это уборка после теста. Удалить созданные данные, вернуть систему в исходное состояние. Если этим пренебрегать, тесты начинают мешать друг другу и появляются те самые флайки Прогон — это запуск набора тестов целиком. Прогнали сьют значит выполнили все тесты и получили общий результат, сколько прошло и сколько упало ТМС — это система управления тест кейсами, test management system. Там хранятся все кейсы, и туда же часто складываются результаты прогонов, чтобы видеть общую картину покрытия Сьют — это набор тестов, объединённых по смыслу. Например, сьют на авторизацию или сьют на оплату. Удобно гонять не всё подряд, а нужную пачку Тест дата — это данные, на которых работает тест. Логины, пароли, тестовые карты, json для запросов. Чем чище и предсказуемее тест дата, тем стабильнее прогоны Грейд — это уровень квалификации специалиста, который отражает его опыт, навыки, степень самостоятельности и ответственность в работе

Пост для новеньких в блоге, небольшой рассказ обо мне👋 Всем привет, меня зовут Олег, сейчас я занимаю должность инженера Tech Lead QA Automation в компании Сбер Здоровье Простым языком: я отвечаю за качество продукта внутри команды, чтобы сервис работал надежно, без сбоев и зависаний, провожу собеседования, отбираю кандидатов и проверяю их работу В общей сложности уже больше 5 лет я работаю в сфере IT. Начинал джуном-автоматизатором, в VK дорос до тимлида, потом стал техлидом в Ozon, поработал сеньором в Ситидрайве Параллельно был наставником в Университете Иннополис и выступал на крупнейших IT-конференциях — Heisenbug, Ural Digital Weekend и Work Solutions. И весь этот опыт я тащу в видео, курсы и эфиры, чтобы людям не пришлось набивать те же шишки, что и мне За 5 лет вокруг канала ThreadQA удалось создать целую экосистему: ▶ YouTube-канал — 11 000+ ребят, которые хотят расти в QA 🎓 Образовательная платформа с курсами по Java, Python и iOS автоматизации 🔔 450+ выпускников моих курсов 🌟 200+ личных консультаций по стеку, архитектуре тестов и карьере 💬 Ламповый чат сообщества, где ребята помогают друг другу В этом канале вас ждет: — полезный контент и подробные ответы на ваши вопросы — гайды как найти работу в IT и все подводные камни — разборы собеседований и вопросы, которые задают в крупных компаниях — инсайты и ошибки, о которых не пишут в туториалах — прямые эфиры с общением и разбором ваших вопросов — лайф контент из моей жизни и работы ▶ YouTube канал: https://www.youtube.com/@threadqa 📌 Платформа с курсами и материалами: https://lms.threadqa.ru 💬 Чат сообщества (можно задать любой вопрос — отвечу я или ребята): @threadqa 💌 Связь со мной: @penolegrus Очень рад видеть вас здесь❤️

Автоматизация брокеров сообщений Расскажу на примере Kafka, как и когда это тестировать, так как это самый популярный брокер Сначала зачем это вообще нужно Во многих системах сервисы общаются не напрямую, а через очереди сообщений Один сервис кидает сообщение в топик, другой его забирает и что то делает. И если эта цепочка ломается, пользователь может вообще не увидеть свой заказ или уведомление. Поэтому такие потоки обязательно надо проверять Как подключаться к Kafka из тестов Тут не нужно ничего магического Есть обычная библиотека kafka-clients, через неё ты и подключаешься к брокеру прямо из автотестов. Поднимаешь продюсера или консьюмера, указываешь адрес брокера и нужный топик, и дальше работаешь руками кода 1️⃣Сценарий первый, проверяем консьюмером Это случай, когда тебя интересует, что система сама что то положила в топик Ты дёргаешь какое то действие в приложении, например создаёшь заказ через API, а потом своим консьюмером читаешь топик и проверяешь, что туда прилетело нужное сообщение с правильными данными То есть ты выступаешь читателем и убеждаешься, что система действительно отправила событие, а не просто сделала вид 2️⃣Сценарий второй, отправляем продюсером А тут наоборот, ты сам кидаешь сообщение в топик Это нужно, когда ты хочешь проверить, как система реагирует на входящее событие. Ты своим продюсером отправляешь сообщение, а потом смотришь на результат, например что в базе появилась новая запись или сменился статус заказа Здесь ты как бы имитируешь соседний сервис, который в реальности шлёт эти события Как понять, какой сценарий выбирать Всё зависит от того, что ты проверяешь, вход или выход Если тебя интересует, что система отправляет наружу, ты читаешь консьюмером. Если интересует, как система обрабатывает входящее, ты отправляешь продюсером. По сути ты просто встаёшь с нужной стороны очереди Пара важных моментов на практике Не забывай про таймауты при чтении, потому что сообщение прилетает не мгновенно, и тест должен подождать, а не сразу падать Ещё аккуратнее с тем, откуда читать топик, чтобы не зацепить старые сообщения от прошлых прогонов. И лучше использовать отдельные тестовые топики, чтобы не мешать чужим данным Тестировать Kafka не страшно, всё сводится к двум ролям Когда проверяешь, что система отправила событие, ты читаешь консьюмером. Когда проверяешь реакцию на входящее, ты шлёшь продюсером. А подключаешься ко всему этому через обычный kafka-clients, и никакой магии тут нет

Вопрос от подписчика: «Какие quality gates используются на практике в автотестировании и как их настраивать?» Quality gate простыми словами — это набор условий, которым должна соответствовать сборка, чтобы пройти дальше по пайплайну Если хотя бы одно условие не выполнено, пайплайн краснеет и не пускает изменения в следующий этап. По сути это автоматический контролёр на входе 1️⃣Гейт первый, линтер и SonarQube Всё начинается прямо в репозитории разработки, ещё до всяких тестов Сначала прогоняется линтер и SonarQube, чтобы посмотреть на качество написанного кода и поискать дубликаты. Если кода грязный или дублей слишком много, гейт не пускает мердж Настраивается это набором правил в Sonar, где ты задаёшь свои пороги под проект 2️⃣Гейт второй, code coverage Дальше смотрим, насколько код покрыт юнит тестами Например, не меньше определённого процента покрытия, иначе гейт краснеет. Для Java это обычно JaCoCo, и порог прописывается прямо в конфиге сборки Важно не гнаться за цифрой ради цифры, покрытие должно отражать реальную проверку логики, а не накрутку ради галочки 3️⃣Гейт третий, SAST и DAST После этого подключается анализ на уязвимости SAST смотрит на код статически и ищет дыры прямо в исходниках, а DAST проверяет уже запущенное приложение со стороны, как это сделал бы атакующий. Если находятся критичные уязвимости, дальше двигаться нельзя 4️⃣Гейт четвёртый, API и UI тесты Только теперь, когда код чистый, покрытый и проверенный на безопасность, запускаем обычные автотесты Сначала API тесты, потому что они быстрее и стабильнее, а за ними UI на ключевые сценарии. Если падает что то критичное, сборка не проходит 5️⃣Гейт пятый, процент флаки тестов И в самом конце смотрим на стабильность прогонов Если процент флакающих тестов выше нормы, это сигнал, что результатам нельзя доверять. Такой гейт настраивается через аналитику в Allure или похожих инструментах Как это всё внедрять на практике Начинай с малого, не вешай сразу все гейты, иначе команда взвоет и начнёт их обходить Сперва линтер и Sonar, потом покрытие, потом анализ безопасности, потом тесты и в конце контроль флаки. Каждый порог обсуждается с командой, чтобы он помогал, а не превращался в формальную преграду Если коротко, Quality gates — это автоматические правила, которые не дают сырому коду уехать дальше Сначала качество кода, потом покрытие, потом безопасность, потом тесты и в конце стабильность прогонов. Главное выстраивать их под реальность проекта, а не копировать чужие пороги вслепую

Вчера был на рыбалке, открываем сезон🎣 В последнее время редко удается выбраться на природу, обычно каждый день начинается и заканчивается работой... У кого как проходят выходные? 👇

Какой язык выбрать для автотестов? Разберём еще один частый вопрос: «С чего лучше начать: Python, Java, JS или вообще что-то другое?» Здесь есть два супер-адекватных ориентира: 🔘Востребованность на рынке (чтобы было кому продать свои навыки) 🔘Как лично тебе это заходит (чтобы не стошнило через месяц) Языки по-разному ложатся на наши мозги, и это нормально, кого-то прям воротит от Python: эти отступы, непонятно где какие типы, нет жесткой структуры А кто-то искренне не понимает, как вообще можно жить в Java, где ради вывода одной строчки нужно построить целый завод с абстрактными фабриками И на самом деле оба варианта — ок, но если язык тебя бесит с первых дней, ты его просто забросишь, вот и всё Я сам искренне люблю Java. За её предсказуемость, строгую структуру и просто вагон готовых инструментов под автоматизацию. А вот в Python лично меня всегда напрягала вечная возня с окружением: эти venv, конфликты версий, внезапно отваливающиеся либы и тд... Но повторюсь, это чисто моя вкусовщина, у вас может быть с точностью до наоборот Также важно отметить, что мы учим язык не ради красивого кода на экране, а чтобы нас наняли. Поэтому открываем http://hh.ru и смотрим, какой стек сейчас в топе. Для QA Automation самый безопасный и железобетонный выбор на сегодня — это Java или Python. Берёте любой из них — и точно не промахнётесь мимо рынка И самое главное Языки похожи друг на друга куда сильнее, чем кажется новичкам. Меняются только скобочки и ключевые слова, а фундамент остаётся один. Как только ты понял, как работают классы, переменные и циклы — ты выучил не «Джаву» или «Питон» — ты научился программировать Так что не делайте из выбора языка вопрос жизни и смерти. Берите тот востребованный вариант, который вас визуально не бесит, и просто начинайте писать код. Ваш прогресс определяет не идеальный выбор инструмента, а банальные часы практики Напишите в комментариях на каком языке вы написали свой первый Hello World👇

Вопрос от подписчика: «Как вы видите идеальный пайплайн автотестов интегрированных в CI/CD?» Вопрос классный, по ответу сразу будет видно, кто реально гонял тесты в бою. Расскажу, как выглядит картина мечты в моей голове 1️⃣Свой стенд на каждую ветку В идеале под каждую ветку поднимается отдельный изолированный стенд со своей базой, своей Kafka и всей нужной инфраструктурой Так тесты разных веток не мешают друг другу, и ты проверяешь именно свои изменения 2️⃣Подмена интеграций через WireMock Часть внешних сервисов неудобно дёргать по настоящему, поэтому их закрываем заглушками через WireMock Это делает прогон стабильнее, и тесты не падают из за того, что чужой сервис лёг 3️⃣Правильный порядок прогона Сначала прогоняются юнит тесты проекта, потому что они быстрые и ловят поломку раньше всех Когда стенд готов и юниты прошли, триггерится отдельный пайплайн с репозиторием автотестов, а ссылки на стенд прокидываются через env файл Дальше идут API тесты, а за ними UI на ключевые сценарии 4️⃣Отчёт и обратная связь После прогона генерируется Allure отчёт, и в мессенджер летит уведомление с результатами А ещё бот отписывается прямо в задачу, чтобы статус прогона и история проверок лежали там же, где и обсуждение тикета Идеальный пайплайн — это изолированные стенды, честная подмена интеграций, правильный порядок прогона и понятная обратная связь в конце Когда всё это собрано вместе, релизы перестают быть страшными, и ты наконец перестаёшь чинить CI в пятницу вечером

Рабочее место айтишника😁 Скоро, кстати, буду делать новый полезный видос на ютуб канал про собесы Залетайте, кто еще не там: https://www.youtube.com/@threadqa

Найм в 2026: битва нейросетей и почему твоё резюме никто не читает Сегодня поговорим про актуальную для огромного большинства людей боль — как вообще пробиться на собес в 2026 году Я вижу что для многих знакомая история, когда неделю вылизываешь резюме, откликаешься на несколько сочных вакансий в первые минуты, а в ответ тишина Или прилетает автоотказ через 10 минут, а ты сидишь, загоняешься и думаешь: «да что со мной не так-то?!» Спойлер: с тобой всё хорошо, просто сама система сломалась Смотрите, что сейчас происходит на рынке: кандидаты массово генерят резюме нейронками, подгоняя опыт под вакансию буква в букву. Компании в ответ генерят вакансии теми же нейронками. На одну позицию прилетает по 500 откликов в час Получается сюр: ИИ пишет резюме → ИИ пишет вакансию → ИИ фильтрует отклики. Бездушные алгоритмы режут по ключевым словам и даже за отсутствие 3-4 лет опыта в резюме Неважно был ли опыт 3 года в каком нибудь Яндексе или Озоне, где очень сильная прокачка и чаще всего 1 год проходит за 3 месяца Забавно то, что до живого человека твоя анкета чаще всего просто не доходит. Откликаться на hh вслепую сейчас — это как кричать в бетонную стену За годы поисков и найма ребят в свои команды я понял одну главную вещь: в 2026 году решает НЕ идеальное резюме, а нетворкинг Если хотите реальных собесов, а не игры в лотерею с автоотказами, вот три рабочих схемы: 1️⃣ Чаты и профильные комьюнити. Почти везде сейчас есть бонусы за рекомендацию. Находите человека из нужной компании, адекватно знакомитесь, просите закинуть резюме по рефералке. Вуаля — его смотрит живой HR. Эта схема сейчас работает лучше всего 2️⃣ Стучаться в личку рекрутерам. Только без полотен текста и душного «здравствуйте, я высокомотивирован» 🫠 Коротко и по делу: кто ты, твой стек, что ищешь, чем будешь полезен. Да, 9 из 10 проигнорят. Но десятый ответит, а тебе по факту и нужен всего один нормальный контакт 3️⃣ Качать LinkedIn. Да, возни с ним сейчас много, понимаю. Но именно там рекрутеры всё ещё хантят руками. Адекватный профиль + пара живых постов про свой реальный опыт дают выхлоп круче, чем сотня откликов в никуда И самое важное правило напоследок: Не пытайтесь накручивать опыт в резюме ради прохождения фильтров. На техническом интервью эта магия рассеивается за 10 минут. Кандидат начинает сыпаться на базе, не может обосновать «свои же» решения и плывёт в проектах. Опытный лид палит фальшь моментально, и это всегда выглядит супер неловко Лучше честно показать крепкого мидла и уверенно защитить свой опыт, чем нарисовать себе сеньора и позорно сгореть на первом же вопросе: «А почему выбрали именно этот подход?» Расскажите в комментариях как у вас сейчас дела с поисками👇

ИИ оставит тестировщиков без работы? Хочу сегодня затронуть популярную тему в интернете, про которую многие спрашивают и в личных беседах В тематических чатах можно увидеть сообщение по типу: «А нафига мне вообще учить автотесты, если скоро ChatGPT всё будет писать за меня? Я вообще буду нужен?» Я думаю для многих это знакомое чувство. Открываешь ленту, а там все говорят: «Нейросети убьют QA!». Сидишь, ковыряешь Java, потеешь над своим первым фреймворком, а внутренний голос шепчет: «Бро, а не зря ли мы тут убиваемся? Может, поезд уже ушёл?» Я сам не раз ловил эти мысли. Так что сейчас разберёмся как есть, без лишнего хайпа и паники Скажу прямо, как человек, который пять лет рулит автоматизацией и решает, поедет завтра релиз или нет: нейросеть вас не заменит И дело вообще не в том, что она пока «глупенькая» или не знает паттернов. Дело в одной фундаментальной штуке, про которую все почему-то забывают — в ответственности ИИ может за пять секунд накидать вам красивый, аккуратный и вроде бы даже рабочий тест. Но если завтра в проде стрельнет критичный баг и компания потеряет миллионы — кто пойдёт краснеть перед бизнесом? Кто будет в 3 часа ночи с красными глазами разбираться, почему всё упало? Кто возьмёт на себя решение: «Всё, стопаем релиз, откатываемся»? Нейросеть ничем не рискует. Ей вообще пофиг. А вы — рискуете. И платят вам именно за это: за умение брать ответственность и принимать сложные решения ИИ не понимает контекста вашего бизнеса. Он не сидел с вами на созвоне, где продакт бил кулаком по столу и говорил: «Вот эта фича — критичная, остальное подождёт» Он не чувствует, где в системе тонкий лёд, потому что не он её строил. Он не придёт к разрабу со словами: «Слушай, у нас тут архитектурная бомба заложена, давай переделывать» Это всё — чисто человеческая история. Это про инженерное мышление, а не про генерацию строчек кода Поэтому моя позиция тут железобетонная: ИИ — это крутой инструмент, а не замена. Мощный, быстрый, экономящий кучу часов помощник Я и сам каждый день юзаю нейронки: накидать болванку, разобрать душный легаси-код, скинуть с себя рутину. Но за рулём — я. Решения принимаю — я. И по шапке за косяки тоже получаю я 😅 📲И вот главная мысль: в этой гонке работу потеряют не люди, которых заменит ИИ. Работу потеряют те, кто *НЕ умеет* пользоваться ИИ, потому что их легко обойдут те, кто *умеет*. Вот и вся математика Так что выдыхаем, не паникуем и продолжаем кодить. Учитесь так, чтобы стать тем самым инженером, который уверенно управляет инструментами, а не трясётся, что они его заменят Работаем🤝

Меня часто спрашивают в личке: «Олег, а как вообще вкатиться в автотесты с нуля? С чего лучше начать?» И каждый раз, когда читаю такой вопрос, я вспоминаю себя в 2020-м. Я тогда был джуном автоматизатором, смотрел на сеньоров как на каких-то магов и искренне думал, что для этого нужен какой-то особый склад ума Спойлер: не нужен. Нужны только система и немного упрямства Поэтому давайте по-честному разложу, как я бы заходил в автоматизацию сегодня, если бы начинал заново: 1️⃣Первое — выберите ОДИН язык и не распыляйтесь Java или Python — оба отличные, вакансий полно под каждый. Главная ошибка новичков: метаться между «а может Kotlin», «а может сразу JS» Нет, берёте один и качаете его до уверенного уровня: переменные, циклы, ООП, коллекции. Без базы программирования автотесты — это карточный домик 2️⃣Второе — не учите фреймворки в вакууме Я видел десятки ребят, которые месяцами читали про Selenide и Rest Assured, но не написали ни строчки. Откройте любой сайт и напишите тест, который проверяет логин Пусть кривой, пусть с хардкодом — но рабочий. Один написанный тест даёт больше, чем десять прочитанных статей 3️⃣Третье — учитесь читать чужой код и не бойтесь GitHub Найдите открытый проект с тестами, разберите, как там всё устроено. Сначала будет каша в голове — это нормально Помню, как я впервые открыл чужой фреймворк и закрыл его через минуту в ужасе. А через полгода уже писал такой же 4️⃣И четвёртое, самое важное — не сидите в одиночку Моя главная боль в начале пути была именно в том, что спросить было не у кого. Сейчас всё иначе: есть чаты, есть менторы, есть сообщества, где за пять минут разберут твою ошибку, на которую ты убил бы три дня Не повторяйте моих шишек — задавайте вопросы Платформа с курсами и материалами: https://lms.threadqa.ru Связь со мной: @penolegrus

Друзья, всем еще раз привет👋 В комментариях можете написать свои вопросы и темы для разбора, с чем у вас возникают сложности в работе, что вам интересно узнать) Сделаю для вас полезные постики и разберу самые важные темы👇

Всем привет, меня зовут Олег Пендрак, и это мой личный канал👋 В далеком 2020 году я начинал свою карьеру в автоматизации тестирования и у меня не было наставника. Думаю, многие узнают себя — ты единственный на проекте, кто пишет автотесты, спросить не у кого, информации в интернете почти 0, чатов в телеге — единицы. Сидишь, гуглишь и многое не понимаешь В какой-то момент я просто записал своё первое видео на YouTube. Потом второе, третье. Оказалось, кому-то это реально полезно — подписчики начали расти, я завёл ламповый чат в телеге, чтобы ребята могли общаться и помогать друг другу Помню, как мне написал подписчик и попросил помочь с проектом. Для меня это был шок — у меня тогда было всего 300 подписчиков, какая там «экспертиза». Я помог разобраться с API-тестами, а он сказал, что я хорошо объясняю простыми словами. Эти слова меня прям зацепили и подтолкнули продолжать Сейчас на YouTube больше 11 000 подписчиков, я провёл сотни консультаций, выпустил курсы, но по сути это всё то же хобби, которое приносит громадное удовольствие Также параллельно удалось заиметь бэкграунд в найме и не только: Больше 5 лет в QA Automation. Начинал джуном-автоматизатором, в VK дорос до тимлида, потом стал техлидом в Ozon, поработал сеньором в Ситидрайве и сейчас техлид в Сбер Здоровье — компаниях, где автотесты решают, поедет завтра релиз или нет Параллельно был наставником в Университете Иннополис и выступал на крупнейших IT-конференциях — Heisenbug, Ural Digital Weekend и Work Solutions И весь этот опыт я тащу в видео, курсы и эфиры, чтобы людям не пришлось набивать те же шишки, что и мне, я всегда хотел помогать и обучать, чтобы по максимуму облегчить этот трудный путь своей аудитории За 5 лет вокруг канала ThreadQA удалось создать целую экосистему: ▶ YouTube-канал — 11 000+ ребят, которые хотят расти в QA 🎓 Образовательная платформа с курсами по Java, Python и iOS автоматизации 🔔 450+ выпускников моих курсов 🌟 200+ личных консультаций по стеку, архитектуре тестов и карьере 💬 Ламповый чат сообщества, где ребята помогают друг другу В этом канале я буду делиться: — полезными и объемными постами по темам IT — реальными кейсами с рабочих задач — разборами собеседований и вопросами, которые задают в крупных компаниях — инсайтами и ошибками, которые обычно не пишут в туториалах — анонсами и стартами продаж курсов и менторских потоков ➕БОНУС: — прямые эфиры с общением и разбором ваших вопросов — лайф контент из моей жизни и работы ▶ YouTube канал: https://www.youtube.com/@threadqa 📌 Платформа с курсами и материалами: https://lms.threadqa.ru 💬 Чат сообщества (можно задать любой вопрос — отвечу я или ребята): @threadqa 💌 Связь со мной: @penolegrus Очень рад видеть вас здесь❤️