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

Насколько изменились собесы на Automation QA с приходом AI? У многих сейчас ощущение, что планка как будто понизилась. Раньше нужно было реально быть сильным по хардам, чтобы спокойно проходить интервью А сейчас вроде можно быть обычным мидлом, но быстро закрывать пробелы через Claude или ChatGPT прямо в работе

Типа не знаешь что-то, закинул вопрос в нейронку, через 5 минут получил решение и пошел дальше

И у многих возникает логичный вопрос: интервьюеры вообще начали учитывать это или нет? Может сейчас уже не так важно помнить детали и можно спокойно добирать через AI? Или наоборот требования стали еще выше? На практике я вижу скорее второй вариант, спрашивать стали больше и копать стали глубже Потому что нейронка сегодня может наклепать вам вообще что угодно. И самая большая проблема в том, что она почти всегда будет соглашаться с вашим решением, даже если оно кривое Даже если архитектура слабая. Даже если код через месяц поддержки превратится в мусор. AI очень редко скажет вам что вы вообще идете не туда Поэтому сейчас на собесах все чаще пытаются понять, не может ли человек что-то сгенерировать, а понимает ли он почему решение сделано именно так Почему выбрал такой подход, почему использовал этот паттерн, какие у решения минусы, что будет через полгода поддержки

Потому что сгенерировать код сегодня может почти любой, а вот объяснить его уже сильно сложнее

Плюс сильно изменился сам рынок, сейчас огромное количество резюме пишется через AI, вакансии тоже часто генерятся через AI Люди массово накручивают опыт, переписывают проекты и превращают обычный CRUD в «высоконагруженную микросервисную платформу» И из-за этого подбор стал намного жестче Потому что никто не хочет брать человека, который красиво рассказывает про Junit Extension, Playwright и архитектуру фреймворка, а потом не может объяснить, зачем нужны ассерты или чем API тест отличается от UI теста Раньше иногда могли взять человека авансом, типа нормальный парень, по ходу разберется

Сейчас так рискуют сильно реже, потому что поток кандидатов огромный, а фейковых «сеньоров» стало в разы больше

И вот на этом фоне интервьюеры наоборот начали внимательнее смотреть на базу Насколько быстро человек ориентируется. Как отвечает на простые вопросы. Есть ли у него реальный опыт. Понимает ли он что делает или просто пересказывает ответы нейронки Поэтому AI скорее не упростил собесы, а сделал их жестче для тех, кто пытается пройти только за счет красивых ответов И при этом AI очень помогает тем, кто уже в теме. Потому что сильный инженер с нейронкой действительно начинает работать быстрее Но нейронка не заменяет понимание, она просто ускоряет человека, который уже умеет думать

Почему начинать работать в IT нужно именно сейчас? Очень легко убедить себя, что момент уже упущен, рынок перегрет, нейронки скоро всех заменят, а на одну вакансию приходит тысяча человек Поэтому лучше ещё немного подождать и посмотреть, что будет дальше Только проблема в том, что через год стартовать легче не станет, технологий будет ещё больше, требования продолжат расти

А люди, которые начали учиться сегодня, уже будут писать проекты, проходить собесы и получать первый реальный опыт

В IT почти никогда не бывает идеального момента, когда конкуренции нет, работодатели готовы брать всех подряд, а для работы достаточно посмотреть несколько роликов на YouTube Зато сейчас есть огромное количество инструментов, которые помогают учиться быстрее, разбирать ошибки, тренироваться перед собеседованиями и писать код

Поэтому путь, который раньше занимал несколько лет хаотичных попыток, сегодня можно пройти намного быстрее, спокойнее и системнее

Главная проблема большинства новичков вообще не в отсутствии способностей, а в том, что они не понимают, за что хвататься Сначала человек открывает Java, потом прыгает в Selenium, через неделю пытается учить Docker, сохраняет сотню статей про API и в итоге просто выгорает от ощущения, что нужно знать вообще всё на свете У меня в своё время было примерно так же, поэтому новый курс Java QA Automation 2026 я строил вокруг конкретного маршрута, где не нужно самостоятельно угадывать, какую тему учить следующей и достаточно ли уже знаний для практики Мы начнём с базы Java, постепенно перейдём к UI и API-автоматизации, разберём базы данных, Kafka, Docker, CI/CD и взаимодействие микросервисов через REST, SOAP, GraphQL, gRPC и вебхуки Вы будете не просто повторять отдельные команды за преподавателем, а собирать полноценный проект и понимать, как все эти технологии связаны между собой на реальной работе К каждому модулю будут конспекты, квизы и домашние задания с проверкой, а сами видео в среднем идут по 30–50 минут, без растягивания простых тем и многочасовой воды

Курс не решит всё за вас и не загрузит знания в голову одной кнопкой, но он закроет главные проблемы, из-за которых люди годами топчутся на месте: отсутствие плана, нехватку практики, страх перед кодом и непонимание того, как выглядит современный проект изнутри

Самое сложное в переходе в IT — не написать первый автотест, а перестать ждать момента, когда вы внезапно почувствуете себя полностью готовыми Потому что готовность обычно приходит не до старта, а уже в процессе, когда вчера вы боялись открыть IDE, а сегодня сами находите ошибку, чините тест и понимаете, что всё это было не настолько страшно Если вы давно думаете о переходе в автоматизацию, то через несколько месяцев вы в любом случае окажетесь в одной из двух точек: 1️⃣Либо снова будете планировать начать 2️⃣Либо уже будете писать код и двигаться к новой работе Выбор здесь довольно простой🤝

Часто бывает когда менеджеры не особо разбираются в технической части, но просят написать автотест на что то, когда руками это посмотреть в разы быстрее🤠🤠

📲Нужно ли хорошо знать Java, чтобы начать писать автотесты? Когда ручной тестировщик впервые открывает программу обучения по автоматизации, у него часто начинается лёгкая паника Потому что там внезапно появляются классы, объекты, коллекции, интерфейсы, лямбды и ещё куча слов, которые вообще ничего не говорят человеку без опыта в разработке После этого многие делают вполне логичный вывод: сначала нужно несколько лет изучать программирование, стать почти полноценным Java-разработчиком и только потом осторожно переходить к Selenium или Rest Assured Я тоже раньше думал, что перед первым нормальным автотестом нужно выучить язык чуть ли не полностью Поэтому постоянно откладывал практику и пытался запомнить огромное количество вещей, которые на том этапе мне вообще не были нужны

В итоге я мог что-то рассказать про теорию, но когда нужно было самостоятельно написать тест, разложить код по классам или понять причину ошибки, начинался тот самый тупняк перед монитором, который знаком почти каждому новичку

🔧Потом я понял простую вещь: автоматизатору действительно нужно знать Java, но ему не надо ждать, пока он станет гуру языка Ведь большая часть понимания приходит именно во время работы с реальными тестами Ты изучил методы и сразу используешь их в проекте, разобрал коллекции и применил их для тестовых данных Дошёл до исключений и наконец понял, что означают ошибки, которые раньше просто копировал в нейронку или поиск Когда теория сразу привязана к практике, Java перестаёт выглядеть как бесконечная стена из непонятного синтаксиса Потому что ты видишь не просто очередную конструкцию языка, а конкретный инструмент, который помогает решить твою задачу ⚡️В новом курсе мы НЕ БУДЕМ сначала несколько месяцев учить абстрактную Java, а потом внезапно пытаться вспомнить всё это при написании автотестов Темы будут идти вместе с практикой и постепенно собираться в полноценный рабочий проект

Главная задача не в том, чтобы зазубрить каждый встроенный метод и отвечать как документация, а в том, чтобы научиться читать код, писать свои решения, разбираться с ошибками и спокойно объяснять, почему ты сделал именно так

Если сейчас код выглядит для вас какой-то магией, это вообще не значит, что вам не место в автоматизации У каждого человека, который сегодня уверенно пишет тесты, когда-то не запускался обычный Hello World и забывал ставить точку с запятой в конце строчки

День успешного техлида начинается с качалки💪 Встал рано утром, раскидал все рабочие задачки, провел созвон, написал еще пару уроков для нового курса и поехал ебашить Сколько насчитали?😁

Go — это вообще не Java Первое время я писал код так, будто это Java, и конечно же это работало вообще не так, как я привык В Go совершенно другой подход: структуры, слайсы, горутины, каналы, интерфейсы, gRPC, protobuf-контракты Много вещей, которые в Java за тебя делает Spring, а вот здесь нужно понимать самому и копаться вглубь На Java ты подключаешь Spring, используешь JDBC Template для работы с базой данных и куча вещей просто работает благодаря аннотациям по типу Service, Controller, Bean, Component А в Go нет этой магии Тебе нужно понимать, что происходит внутри, как работают запросы к базе, как устроены соединения, кеши и вся инфраструктура вокруг Очень сильно помогали коллеги, особенно с SQL Потому что постепенно я начал разбираться не просто в написании кода, а в том, как реально работают backend-системы

Пришлось изучать индексы, репликацию баз данных, проблемы с Kubernetes, когда одновременно запускаются несколько экземпляров микросервиса и у них разный кеш, и еще кучу вещей, о которых раньше я даже не думал

Со временем я втянулся Начал проектировать новые микросервисы, помогал делать quality gates для CI/CD, которые ограничивали пропуск тестов, если покрытие было ниже нужного уровня А моей самой большой задачей был большой парсер и конвертер REST → gRPC → GraphQL

Проблема была в том, что система собирала информацию о тестах из разных микросервисов, а один и тот же функционал мог быть реализован совершенно по-разному

Нужно было каким-то образом все это находить, сопоставлять и приводить к единой структуре Приходилось парсить Swagger с сотней микросервисов, разбираться с контрактами и строить систему, которая могла бы все это связывать между собой Обрабатывать через Kafka сообщения при обновлении как раз спецификаций, также через Redis кешировать тяжелую информацию по нагрузке на ручки по RPS Это был настоящий взрыв мозга, но одновременно было очень интересно И вот спустя время я начал ловить себя на мысли, что как будто автотесты мне все-таки ближе

Сначала я думал, что это обычная усталость. Новый язык, новая команда, много сложных задач — такое бывает Но даже после отпуска это чувство никуда не ушло Я понял, что backend постепенно начинает затягивать меня туда, куда я не хочу идти

Мне нравится разбираться в технических вещах, строить системы и решать сложные задачи, но именно разработка большого backend уже не приносила того удовольствия В итоге я честно поговорил с лидом и сказал, что меня больше не драйвят задачи и в целом направление backend на Go И он нормально к этому отнесся Сказал, что это абсолютно нормально, потому что иногда нужно попробовать что-то новое, чтобы понять, твое это или нет И на самом деле этот опыт был для меня очень полезным Я понял, как устроены backend-системы изнутри, поработал с Go, gRPC, Kubernetes, базами данных и кучей технологий, которых раньше не знал Но в какой-то момент понял, что это просто не мое направление После этого я уволился и примерно полгода не работал Про мой проект можно посмотреть доклад с конференции Heisenbug, там мой тимлид на тот момент делился успехами: https://www.youtube.com/watch?v=f3hIKCeuqzE (на 41:32 минуте можно увидеть меня на презентации)

После того, как я решил уйти из VK и закончить с тимлидством, я понял, что хочу попробовать плавно перейти в разработку Полностью уходить в обычный backend мне было страшновато, потому что у меня весь опыт был связан с автоматизацией, поэтому решил посмотреть в сторону SDET По сути SDET — это разработчик инструментов для тестирования Ты не просто пишешь автотесты, а делаешь библиотеки, микросервисы для генерации тестовых данных, дашборды и другие внутренние инструменты, которые помогают тестировщикам быстрее и эффективнее работать Мне показалось, что это хороший вариант, потому что с одной стороны я остаюсь рядом с тестированием, а с другой начинаю больше заниматься разработкой

Решил зайти на сайт Ozon и посмотреть, какие у них есть вакансии

Там было две позиции SDET инженера 1️⃣ Первая была полностью про инфраструктуру, где нужно было быть ближе к DevOps: CI/CD, окружения, внутренние инструменты и всякие процессы вокруг тестирования 2️⃣ А вторая была команда Test Impact Analysis, и вот она меня заинтересовала намного сильнее Там нужно было писать чистый backend на Go и заниматься глубокой математикой и хешированием связей, системой аналитики покрытия тестов У Ozon Bank было около 10 тысяч тестов, и запускать их все после каждого изменения было просто неэффективно, потому что многие тесты пересекались между собой

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

Плюс там были метрики, аналитика запусков и оптимизация скорости прохождения тестов Меня больше всего зацепило именно то, что это был backend и новый язык До этого у меня был только Java Spring, а Go я вообще никогда серьезно не трогал Я вспомнил, что на конференции Heisenbug познакомился с одним парнем из Ozon и решил ему написать, чтобы попробовать попасть на собеседование через рефералку В итоге мы созвонились, он рассказал подробнее про команду и чем они занимаются. И чем больше он рассказывал, тем интереснее мне становилось

Но самое забавное было дальше

Я прохожу скрининг, мне назначают техническое интервью и оказывается, что этот парень — тимлид той самой команды Сначала было немного необычно, потому что ты вроде бы идешь на собеседование к человеку, с которым уже успел пообщаться, но в итоге все прошло хорошо Я справился с техническими вопросами, решил лайвкодинг на максимальную оценку и прошел дальше На финале была уже более интересная задача Мне нужно было спроектировать rate limiter для ограничения сетевых запросов по gRPC и рассказать, как это все тестировать И вот тут я знатно прифигел Проблема была в том, что запросы выполняются не всегда одинаково Например, если поставить ограничение в 3 запроса в секунду и запустить 5 потоков, которые одновременно пытаются отправить запрос, то нельзя заранее сказать, какие именно потоки успешно пройдут Может пройти первый, третий и пятый, а может второй, четвертый и первый

Все зависит от времени выполнения и нагрузки, так как запросы идут не детерминировано

Я тогда думал, что задача достаточно сложная и вообще нет понимания что делать с этим, но я начал рассуждать и с небольшими подсказками смог довести решение до конца После этого мне показывают офер, дают грейд ведущего инженера и я соглашаюсь Для меня это был полностью новый этап Новая команда, новый язык, backend вместо автоматизации и куча вещей, о которых я раньше даже не задумывался После недели онбординга мне дают первую задачу — написать новый фильтр для ручки, которая получает все тесты выбранного микросервиса И неожиданно я достаточно быстро с ней справился Начал разбираться в проекте, понимать логику системы и в целом мне это даже начало нравиться Но потом началась самая сложная часть... давайте наберем 50 👨‍💻 и опубликую продолжение истории

📲Что будет в моём новом курсе по Java QA Automation? Когда я только начинал автоматизировать, казалось, что достаточно выучить Java, Selenium и научиться писать пару UI-тестов Но на реальном проекте быстро выясняется, что приложение — это не только кнопки в браузере, а куча микросервисов, баз данных, очередей и внешних систем, которые общаются между собой по разным протоколам

В одном месте будет REST, в другом SOAP, где-то GraphQL или gRPC, а часть процессов вообще уйдёт в Kafka или вебхуки

И если автоматизатор умеет только кликать по UI, то в 2026 году этого уже откровенно мало Именно поэтому в новом курсе мы будем работать не с отдельными примерами, а с полноценным приложением, где есть UI, backend, база данных, платежи, внешние интеграции и асинхронные события Разберём REST, SOAP, GraphQL, gRPC, Kafka, вебхуки, PostgreSQL и моки через WireMock, чтобы вы понимали не только как написать тест, но и как проверить всю цепочку взаимодействия между сервисами

При этом всё начинается с базы Java, поэтому не нужно заранее быть разработчиком или уметь собирать фреймворки с нуля

Постепенно дойдём до Selenide, REST Assured, JUnit, Docker, GitLab CI, Allure и полноценного проекта, который можно будет нормально показать на собеседовании У меня получилось сделать не очередной курс, где вы просто повторяете код за преподавателем, а максимально понятный маршрут от ручного тестирования до автоматизации на уровне современных микросервисных проектов Потому что сейчас работодателям нужен не человек, который знает несколько команд Selenium, а инженер, который понимает, как устроена система и умеет проверить её целиком

⚡️СПИСОК ПОЛЕЗНЫХ ПОСТОВ Собрал для вас все полезные материалы с канала в одном посте, сохраняйте себе в избранное, чтобы не потерять — Информация обо мне — С чего начать в автотестах — Мои мысли насчет значимости ИИ в 2026 году — Как пробиться на собес в 2026 году — Идеальный пайплайн автотестов интегрированных в CI/CD — Какой язык выбрать для автотестов — Автоматизация брокеров сообщений — Список базовых терминов — Грейды в IT — Ручное или автоматизированное тестирование? — Пошаговый план как начать в IT с нуля — Почему стоит выбрать Java — Список библиотек в автотестах — С чего начинать автоматизацию тестирования на новом проекте — Что автоматизировать, а что нет? — Где практиковаться искать локаторы для UI автотестов и писать API тесты — Снимаем напряжение по поводу собесов по автотестам — Главный парадокс собесов — Испытательный срок: как не уволить самого себя от страха — Правильная архитектура API тестов — Как Allure-отчёт отличает джуна от крепкого мидла — Чем занимается Tech Lead QA Automation? — 1 часть моего пути — Выгорание в моей жизни — Как сделать универсальные стабильные тесты под IOS и Android — Одобряю ли я ИИ тулзы для прохождения собесов — ОТЗЫВЫ УЧЕНИКОВ

Одобряю ли я ИИ тулзы для прохождения собесов? Сейчас есть куча сервисов и расширений, которые помогают проходить собесы Они могут подсказывать ответы, анализировать экран, генерировать код в реальном времени и вообще делать вид, что собес можно пройти без подготовки Со стороны кажется, что это халява полная: включил утилиту и пошел спокойно проходить технический собес, при демонстрации экрана ее не видно и все работает по верх экрана Но на практике все работает сильно хуже

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

Потому что инженер с опытом не будет секунд 40 думать над вопросом уровня «какие коллекции есть в Java» Он сразу скажет про ArrayList, LinkedList, Stack и еще сам начнет объяснять где что лучше использовать То же самое с кодом, я часто даю максимально кривой UI тест без page object, без ассертов, с локаторами прямо в тесте и без нормальной структуры И прошу просто прокомментировать, что тут можно улучшить

Человек, который реально работал с автоматизацией, сразу скажет, что локаторы надо выносить отдельно, почему вообще тест без ассертов, и почему тестовые данные захардкожены и вообще код надо нормально разделять

Потому что он такое видел уже сотни раз А когда кандидат сидит минут пять, смотрит в экран и начинает очень аккуратно выдавать очевидные вещи, то сразу понятно что он либо гуглит, либо ждет ответ от нейронки Поэтому все эти ИИ помощники чаще всего палятся именно на базовой теории и простых практических задачах

С лайвкодингом та же история, нейронка может выдать идеальное решение поверх экрана

И вот человек начинает его переписывать, потом ловит банальную ошибку импорта или вообще не может объяснить, что делает встроенный метод в стримах к примеру или как работает лямбда И на этом все обычно заканчивается Потому что на собесе смотрят не только на финальный код. Смотрят как человек думает, как объясняет свои решения, как отвечает на уточняющие вопросы и насколько уверенно ориентируется в теме

Нейронка может подсказать ответ, но она не может за 5 минут дать тебе реальный опыт

При этом я не считаю, что нейронки это зло. Для подготовки к собесам это вообще отличный инструмент Можно гонять теорию, разбирать задачи, тренировать лайвкодинг и просить объяснить сложные темы простым языком Но использовать ИИ как костыль прямо во время собеса — это обычно плохая идея Потому что если ты вообще не понимаешь про что говоришь, то это вскрывается почти сразу А если нормально шаришь в теме, то тебе эти помощники особо и не нужны

📲Друзья, объявляю обновленную дату выхода нового курса Здоровье уже получше, заканчиваю последние уроки и довожу все детали до идеала Старт продаж — 6 августа 18:00 мск

Как плавно перейти от автотестирования к лидству и понять, твое это или нет? Я сам об этом думал, еще когда работал в VK обычным инженером по автоматизации мобилок Периодически ловил себя на мысли, что вроде интересно попробовать тимлидство, но одновременно понимал, что это бесконечные созвоны, решение конфликтов, ответственность за людей и иногда необходимость быть жестким А я вообще не такой человек по характеру И в какой-то момент мне пишет Яндекс и предлагает пойти лидом в Яндекс Драйв по мобильной автоматизации Звучало интересно, плюс команда небольшая и казалось, что это хороший вариант, чтобы попробовать себя в новой роли

Я прошел скрининг, техничку, финал и в целом все прошло нормально

Потом мне показывают офер, но по зарплате разница с моей текущей работой была вообще незначительная Думаю ладно, зато попробую что-то новое Прихожу к своему тимлиду в VK, показываю офер, и говорю, что собираюсь уходить. И тут начинается самое интересное Меня начали удерживать вообще все. Сначала тимлид, потом руководитель отдела, потом лиды соседних команд

И самое забавное, что отговаривали не от лидства, а именно от Яндекса

Потому что у нас куча людей была бывшими сотрудниками Яндекса и отзывы были далеко не самые приятные Постоянные переработки, бардак в процессах, жесткое руководство и куча внутренних библиотек, которые кроме Яндекса особо нигде не нужны Сначала я думал, что это просто стандартный процесс удержания, но когда тебе одно и то же начинают говорить люди, с которыми ты даже особо не общался, начинаешь задумываться

И в какой-то момент руководитель отдела предлагает мне стать лидом внутри своей же команды

На тот момент команда разрасталась и нас разделяли на две подкоманды отдельно ручников и отдельно автоматизаторов И это на самом деле был идеальный вариант Потому что сразу прыгать лидом в новую компанию это реально тяжело. А тут ты уже знаешь людей, процессы, проект и можешь спокойно попробовать себя в новой роли без жесткого стресса В итоге я согласился. Мне подняли зарплату до уровня офера Яндекса и спустя месяц официально назначили тимлидом Дальше началась вообще другая работа Куча внутренних курсов, тренинги, работа с молодыми лидами, разбор конфликтных ситуаций, встречи с менеджментом Потом тебя начинают добавлять на миллион созвонов, где половину времени ты просто сидишь для галочки Плюс постоянные 1-1, контроль нагрузки команды, помощь людям по развитию, оценка сотрудников и умение иногда говорить «нет», даже если сам не особо согласен, потому что сверху уже приняли решение

И вот спустя примерно полгода я понял, что тимлидство вообще не для меня

Мне гораздо интереснее техническая часть. Сидеть копаться в инфраструктуре, автоматизации, коде и спокойно заниматься инженерной работой, а не держать в голове миллион процессов и чужих проблем И это нормально, потому что тимлид это не “следующая ступень развития” для каждого инженера — это просто другая работа Кто-то кайфует от менеджмента, общения и решения вопросов. А кто-то хочет спокойно расти как сильный инженер И самое важное, что зарплаты у хорошего сеньора и лида очень часто плюс-минус одинаковые. Просто задачи совершенно разные После этого я ушел в Ozon уже в разработку, но это уже другая история...

📲Друзья, запуск нового курса переносится Слег с температурой и насморком, осталось записать несколько уроков, чуть-чуть не успел... О новой дате сообщу чуть позже🤝

Мотивация вам на ночь, ребята Пришел свеженький отзыв от одного из учеников — Максима, он работал в сфере продаж и в один момент наткнулся на мои видосики на ютубе После изучения информации в видео, Макс пришел на консультацию, приобрел несколько курсов и буквально за 1-2 недели поисков нашел хорошую работу в IT В итоге за 3 года Максим заработал больше, чем за 7-8 лет до этого, уже купил недвижимость и улучшил качество жизни для себя и своей семьи Такие истории всегда очень мотивируют меня продолжать работать и стараться давать пользу людям, облегчить их путь в IT и найти высокооплачиваемую работу И для вас это очередной пример, что можно просто прийти даже из совершенно другой сферы и стать тем самым айтишником😁 Работаем🤝

Можно ли самостоятельно выучить автоматизацию по бесплатным материалам? В теории — вообще без проблем, сейчас на YouTube, в статьях и документации можно бесплатно найти почти всё: Java, Selenium, REST Assured, SQL, Git, Docker, CI/CD и ещё сотню вещей, которыми пользуются автоматизаторы Со стороны кажется, что покупать обучение вообще нет смысла, потому что достаточно открыть плейлист, спокойно пройти уроки и через несколько месяцев уже рассылать резюме на позицию automation QA

Но на практике большинство людей застревают не потому, что им не хватает информации, а потому что этой информации слишком много и она почти нигде не собрана в адекватный маршрут

Сегодня ты смотришь часовое видео про коллекции в Java, завтра случайно находишь ролик про паттерн Page Object, а потом кто-то говорит, что без Docker сейчас никуда А ещё через день ты уже пытаешься понять Jenkins, хотя до сих пор не можешь уверенно написать обычный тест без копипасты

У меня тоже был период, когда я сохранял десятки статей и курсов, открывал по двадцать вкладок и постоянно чувствовал, что вот ещё немного посмотрю — и наконец-то буду готов начать делать свой проект

Только готовность почему-то не наступала, потому что просмотр уроков очень легко спутать с реальным прогрессом Ты вроде бы занят полезным делом, но как только закрываешь видео и остаёшься один на один с кодом, становится понятно, что половину материала ты вообще не можешь применить Самое важное в обучении — не просто услышать новую тему, а сразу понять, где она используется, попробовать написать код самому, словить несколько ошибок, разобраться, почему всё сломалось, и только после этого двигаться дальше Именно поэтому в новом курсе, о котором я говорю в последнее время, я постарался максимально убрать это вечное метание между технологиями Метание, когда человек сегодня учит одно, завтра другое, а через месяц уже не помнит, зачем и с чего вообще начинал Будет конкретная последовательность, практика после тем и постепенная сборка проекта, чтобы знания не оставались где-то в заметках, а превращались в рабочий код, который можно открыть, объяснить и показать на собеседовании

Бесплатные материалы — это круто, и я сам постоянно ими пользуюсь, но без плана они легко превращаются в бесконечное потребление контента, где ты вроде бы учишься каждый вечер, а до реального перехода в автоматизацию почему-то вообще не приближаешься

В IT редко выигрывает тот, кто посмотрел больше всех роликов, обычно выигрывает тот, кто перестал бесконечно готовиться и начал регулярно писать код руками

Вопрос от подписчика: «Как сделать универсальные стабильные тесты под IOS и Android» Если коротко, человек тестит гибридное Flutter приложение, тесты на Java через Appium с Flutter Integration Driver Проблема в том, что на Android можно достучаться до натива и юзать flutterKey и xpath, а на iOS натив толком не работает, только flutterKey, и есть страх, что на реальном устройстве всё сломается Как я подхожу к задаче единых тестов на обе платформы: Сначала про корень проблемы Боль не в самом Flutter, а в том, что локаторы на двух платформах разные

Если пытаться писать общий тест и внутри него постоянно писать условия на проверку, мы на iOS или на Android, то код быстро превращается в кашу

Поэтому различия платформ надо спрятать в одном месте, а не размазывать по всем тестам 1️⃣Фабрика Appium драйвера Создание драйвера выносим в отдельную фабрику, например AppiumDriverFactory Она смотрит на окружение, читает платформу из конфига или переменной, и сама собирает нужные capabilities

Для Android отдаёт драйвер с одними настройками, для iOS с другими, а тест вообще не знает, на чём он сейчас бежит

Тесту прилетает уже готовый драйвер, и вся платформенная грязь остаётся внутри фабрики 2️⃣Кастомные аннотации на локаторы Дальше самое вкусное, делаем единый Page Object на обе платформы Создаём свои аннотации, например @AndroidLocator и @iOSLocator, и вешаем их на одно и то же поле элемента

В Android аннотации кладёшь xpath или нативный локатор, в iOS кладёшь flutterKey

Получается, что элемент описан один раз, но сразу с двумя адресами под каждую ОС Как это связывается вместе Нужен небольшой обработчик, который при инициализации Page Object смотрит на текущую платформу

Он читает аннотации поля, берёт локатор именно для активной ОС и подставляет его в элемент

По сути это твоя версия PageFactory, только заточенная под Flutter и две платформы сразу В итоге в тесте ты просто пишешь loginButton.click(), а под капотом сам подставился нужный локатор Что делать с разницей возможностей на iOS Раз на iOS реально живёт в основном flutterKey, строй стратегию вокруг него как основного способа поиска

Договорись с разработчиками, чтобы ключевые элементы получали стабильные flutterKey прямо в коде приложения

Это снимает большую часть боли, потому что ключ не зависит от вёрстки и не плывёт между релизами Про страх с реальным iOS устройством Симулятор и реальное устройство действительно ведут себя по разному, тут опасения справедливы

Поэтому критичный прогон обязательно гоняй хотя бы иногда на реальном девайсе, а не только на симуляторе

Лучше один раз увидеть проблему в CI на ферме устройств, чем поймать её уже в проде Единые тесты на iOS и Android — это не про общий локатор, а про общий интерфейс и спрятанные различия Фабрика драйвера прячет настройки платформы, кастомные аннотации прячут разные локаторы, а page object и тест остаются едиными Опирайся на flutterKey как на самый надёжный якорь и проверяйся на реальных устройствах, тогда гибридный Flutter перестаёт быть для тебя проблемой

Заканчиваю создание нового курса🔥 С уверенностью могу сказать, что это самое лучшее и масштабное, что я в принципе создавал Максимальный концентрат пользы, практики и эффективных инструментов Очень удобная структура, которая позволяет закрыть весь ваш путь от первых строк кода до уверенного собеседования и нормальной работы на проекте Старт продаж — 1 августа в 18:00 мск, ждите🤝

✍️ МОЙ ПУТЬ l ЧАСТЬ 5 VK, Ozon, Ситидрайв, СберЗдоровье И вот заключительный пост серии, про то, почему я несколько раз осознанно начинал почти с чистого листа 2024 год. В VK я проработал аж 3 года и в один момент уперся в потолок по развитию, а параллельно компания начала перетряхивать структуру, сокращать целые отделы и сворачивать рекламное направление Стало понятно, что пора двигаться дальше, пока это не решили за меня другие люди Тут я вспомнил, что на том самом Heisenbug познакомился с ребятами из Ozon, и написал одному парню, который оказался тимлидом в одной из sdet команд Они как раз искали сильного инженера на go, и я подумал, что это отличный шанс попробовать что-то новое и углубиться в технику уже со стороны бэкенда Собес был из трёх технических этапов, я прошёл их довольно легко и получил грейд ведущего инженера. В первый же день познакомился с командой, где все были примерно моего возраста, и это был вайб настоящих друзей, простые созвоны без напряга и очень сильная техническая атмосфера Ребята там реально превосходили меня по знаниям, и мне это даже нравилось, появился спортивный интерес и понятное направление для роста, ведь практики на go у меня раньше не было В Ozon я проработал год, делал дашборд для управления тестами и сбора метрик по нагрузке на ручки, занимался маппингом grpc в rest и обратно Проект был реально необычный, я узнал кучу нового, но в какой-то момент поймал себя на мысли, что автотесты мне всё-таки ближе, а чистая разработка перестала по-настоящему зажигать Тогда я сказал лиду, что ухожу в свободное плавание и хочу делать что-то своё. Уволился я в мае, устроил себе настоящие летние каникулы и почти полгода не работал, катался по конференциям и мероприятиям, начал пилить собственную lms-платформу для обучения автоматизации и параллельно менторил ребят 2025 год. Когда сидеть без дела надоело, я вышел на рынок и устроился в Ситидрайв сеньором-автоматизатором фулстеком. Команда классная, проект интересный, вроде всё супер, но снова всплыло то же самое ощущение, что мне ближе именно автотесты, инфраструктура и прокачка технических навыков Заставлять себя любить другое это примерно как гнать человека на футбол, когда он всю жизнь кайфует от баскетбола Через пять месяцев меня позвали в СберЗдоровье техлидом направления, заниматься инфраструктурой, прокачивать ручных тестировщиков и помогать им осваивать автотесты, проводить кодревью для смежных команд Вот тут я наконец понял, что это ровно то, чем мне всегда нравилось заниматься, плюс зарплату предложили в разы выше всех предыдущих мест Если собрать весь этот путь в одну картинку, то за пять лет я прошёл дорогу от зелёного джуна до техлида направления и поднял доход примерно в двадцать раз от стартового И вот что хочу сказать напоследок: эти двадцать раз случились не потому что мне повезло, а потому что за каждым переходом стояли риск, ошибки и готовность снова начинать почти с нуля Карьера это вообще не движение по прямой, иногда нужно несколько раз сменить направление и не побояться перемен, чтобы наконец-то найти своё место И я чертовски рад, что в конечном итоге все получилось. Работаем🤝

Почему многие годами хотят перейти в автоматизацию, но так и остаются в ручном тестировании? Я постоянно вижу одну и ту же историю: человек уже нормально шарит в тестировании, умеет находить сложные баги, понимает продукт, общается с разработчиками и тд Но как только речь заходит про Java и автотесты, он почему-то снова чувствует себя абсолютным новичком Вроде бы мотивация есть, зарплату хочется выше, да и ручные регрессы уже откровенно достали Поэтому человек открывает курс по Java, смотрит несколько роликов про Selenium, потом пытается разобраться с API, Git, Docker и ещё десятком технологий, которые внезапно оказываются нужны автоматизатору Через пару месяцев в голове уже лежит куча разрозненной информации, но написать нормальный проект с нуля всё ещё не получается, из-за чего появляется ощущение, что автоматизация просто не для тебя У меня в своё время было примерно так же, я пытался изучать всё подряд и постоянно думал, что мне не хватает ещё одного курса, ещё одного ролика или ещё одной статьи, после которой наконец-то всё сложится в голове Но проблема была вообще не в количестве информации, потому что её и так вокруг дофига, проблема была в том, что никто нормально не объяснял, в каком порядке всё это учить и как отдельные технологии соединяются в реальной работе Можно знать команды Selenium, но не понимать, как правильно разделить код, куда вынести локаторы, как работать с тестовыми данными и что делать, когда у тебя уже не пять тестов, а несколько сотен

Можно выучить синтаксис Java, но зависнуть перед пустым проектом, потому что одно дело решать задачки на циклы, а совсем другое — собирать полноценный тестовый фреймворк, который не стыдно показать на собесе или использовать в команде

Именно поэтому в своем новом курсе я хочу дать не очередную свалку из уроков, после которой человек остаётся один на один с пустой IDE А максимально понятный маршрут от базы Java до нормального проекта с UI, API, инфраструктурой и всем тем, с чем автоматизатор реально сталкивается на работе Автоматизация — это не какая-то закрытая каста для людей, которые писали код с десяти лет Это обычный навык, который можно освоить, когда тебе не кидают всё сразу, а последовательно объясняют, что ты делаешь, зачем ты это делаешь и как это потом пригодится в работе Если вы давно думаете о переходе, но постоянно откладываете из-за страха перед кодом, то не надо заранее ставить на себе крест, возможно, вам просто всё это время не хватало нормальной системы.

Автоматизация тестирования в идеальном мире: — пишем автотесты до релиза — спокойно деплоим — спим без тревоги Автоматизация тестирования в реальном мире: 1. Выпускаем релиз. 2. Ловим баг в проде. 3. Получаем сообщение: «Срочно починить!» 4. Чиним 5. На ретро слышим сакральную фразу: «Надо обязательно покрыть это автотестом» И так пополняется коллекция автотестов, каждый из которых хранит память о чьей-то бессонной ночи, горячем фиксе и сообщении в рабочем чате: «Кто это вообще пропустил?» 🧐 Самое забавное, что многие автотесты появляются не потому, что команда заранее всё предусмотрела, а потому что прод уже преподал очередной дорогостоящий урок Прод — лучший автор тест-кейсов, правда, очень дорогой