Мы возвращаемся с новым форматом QAчественного общения — антимитапом для тестировщиков.
Когда: 27 марта Где: Санкт-Петербург, offline only
В этот раз сделали два зала и два настроения:
🔥 Test core Пространство вызовов, острых тем и адреналина. Сарказм приветствуется, личные нападки — запрещены.
Будут холивары: «Hard Skills для QA — это про инструменты или про понимание систем?», «Как меняется профессия QA с приходом AI».
💆♀️ Debug Зал для размышлений и рефлексии. Здесь не доказывают, а задаются вопросами и делятся гипотезами. Тот самый safe space, чтобы подумать о будущем QA.
Будут дискуссии: «Как принять свою роль и стать хорошим тестировщиком», «ИПР: развитие специалиста — это задача компании или специалиста?».
Вы сами выбираете маршрут. Можно передвигаться между залами и собирать инсайты с двух полюсов или остаться в одном пространстве и погрузиться в его формат.
Playwright в 2026: новый стандарт UI‑автоматизации
На протяжении последних нескольких лет Playwright из альтернативного инструмента превратился в де‑факто стандарт для UI‑автоматизации в современных веб‑приложениях.
Основная причина тому — архитектурный сдвиг. В отличие от Selenium, который опирается на WebDriver и добавочный слой взаимодействия с браузером, Playwright работает напрямую через DevTools‑протокол. Это устраняет лишние абстракции и снижает накладные расходы на взаимодействие.
На практике это дает три ключевых эффекта:
Стабильность
Встроенный механизм auto‑waiting и синхронизации с состоянием DOM значительно снижает количество flaky‑тестов. Инженеру больше не нужно вручную управлять ожиданиями и обрабатывать race conditions.
Производительность
Благодаря прямому взаимодействию с браузером и встроенной поддержке параллельного выполнения, Playwright демонстрирует более быстрый feedback loop в CI/CD пайплайнах.
Developer Experience
Инструмент предоставляет полноценный набор средств чуть ли не из коробки: trace viewer, codegen, network interception, изоляция через browser contexts. Это снижает порог входа и ускоряет разработку тестов.
При этом важно понимать: Playwright не является «серебряной пулей». Он не делает плохую архитектуру тестов хорошей, не отменяет необходимость в грамотной декомпозиции сценариев, и не заменяет стратегию тестирования.
Но в условиях 2026 года, где доминируют SPA, асинхронные интерфейсы и требования к скорости CI, Playwright лучше соответствует реальным условиям эксплуатации.
Вывод: если вы проектируете систему автоматизации с нуля — Playwright является рациональным выбором по умолчанию.
Если у вас уже есть зрелая Selenium‑инфраструктура — решение о миграции должно приниматься на основе метрик (flaky rate, время выполнения, стоимость поддержки), а не трендов.
Что почитать начинающим тестировщикам: 6 материалов для погружения в тестирование
Привет, Хабр! Мы приготовили подборку, которая поможет глубже погрузиться в тестирование. Внутри — обзоры профессиональной литературы, популярных инструментов и библиотек, а также советы от команды Selectel. Бонус — бесплатный курс по мобильному тестированию от опытных тестировщиков.
Android-эмуляторов — десятки. Чтобы вам было проще выбрать, мы сравнили восемь популярных решений. Разобрали особенности каждого и объяснили, для каких задач они подходят.
Мобильное тестирование — это не просто «веб в миниатюре», а отдельный мир со своей архитектурой, устройствами, операционными системами и ограничениями. В статье рассказали об особенностях мобильных платформ, с которыми тестировщики сталкиваются на практике.
Бесплатный курс от экспертов Selectel, Ozon, Спортс" и не только. Он подходит как новичкам, так и практикующим тестировщикам, которые хотят систематизировать знания. На начало марта доступна первая часть курса, но совсем скоро появится и вторая.
Тестирование — кропотливый труд, особенно для начинающих специалистов. Но задачу можно упростить, если прокачать знания и внедрить подходящие инструменты.
Мало стартового набора? Держите дополнительную порцию интерактивных тренажеров, баз знаний, книг и курсов — проверенных ресурсов, к которым можно возвращаться в любой момент.
Если вы устали от бесконечных циклов «получить приложение → найти баг → отправить на доработку → повторить», предложите команде AI-инструменты для прототипирования. В статье рассказали, как мы используем этот подход.
44 собеса за месяца — Жив ли рынок QA/AQA на самом деле?
Календарь AQA собесов за декабрь
Последний год в IT регулярно обсуждают одну и ту же тему — рынок стал сложнее. Вакансий меньше, требования выросли, конкуренция усилилась.
Особенно часто это можно услышать от специалистов из QA/AQA: Мол, тестирование переполнено, вакансий мало, а найти новую работу стало почти нереально.
Я давно консультирую ребят в сфере QA и автоматизации тестирования (AQA) и регулярно наблюдаю, как специалисты выходят на рынок. Поэтому иногда вижу довольно наглядные примеры того, как ситуация выглядит на практике.
Как раз недавно один из ребят показал в нашем чатике свой календарь собеседований за декабрь — этот календарь приложил выше.
И, честно говоря, даже меня это немного удивило. За месяц у него набралось 44 собеседования.
Причём: Во-первых, всё это происходило параллельно с основной работой. Человек не уходил в отпуск и не ставил поиск работы на полный день — все интервью проходили между рабочими задачами.
Во-вторых, это был декабрь. Если смотреть на рынок найма в IT, конец года традиционно считается не самым активным периодом: компании закрывают бюджеты, команды уходят в отпуска, процессы замедляются.
Тем не менее календарь получился очень плотным.
Иногда у него было по несколько интервью в день: HR, технички, финалки, снова HR.
А если представить его лицо 11го декабря — то лучше не надо)
P.S. Выходил на рынок он как Fullstack QA/AQA, если что. В ручном тестировании естественно ситуация похуже. Но наверное основной моей задачей и являлось помочь ему с этим переходом (QA->AQA), т.к. именно тут наилучшая конверсия для QA.
И что по итогу? Оправдались ли такие усилия?
Думаю, всем это тоже будет интересно. Стоило ли оно вообще того.
Вы реально думаете, что человек, который проходил по 6 собесов в день, мог не добиться своего?)
Всё-таки в подобной ситуации очень быстро прокачиваются навыки интервью. С каждым новым собеседованием ответы становятся точнее, технические вопросы разбираются быстрее, а уверенность растёт.
В итоге этот кандидат получил 6 офферов.
Один из них оказался особенно сильным — около 490 000 рублей gross для позиции в автоматизации тестирования.
На мой взгляд, это хороший пример того, как сейчас устроен рынок.
Да, он действительно стал сложнее. Да, требования выросли.
Но при этом рынок далеко не мёртв. Он просто стал требовательнее к кандидатам.
Те, кто активно выходят на рынок, много собеседуются, анализируют обратную связь и продолжают двигаться дальше — как правило, всё равно получают результат.
А те, кто не пытается, чаще находят объяснение, почему сейчас «не время».
Поэтому, когда в очередной раз услышите, что рынок QA/AQA окончательно умер, просто вспомните календарь из 44 собеседований за один месяц.
Спасибо, что дочитали пост до конца! Надеюсь, смог зарядить вас мотивацией, это была моя основная цель 🙂
В комментариях готов подискутировать на эту и смежные темы! Ну а в своем блоге Telegram также пишу про тестирование и автоматизацию, иногда затрагивая и общие темы развития в сфере IT. Всегда рад новым читателям!)
Русский FAANG: карьерный буст или выгорание за 400к? Что выбрать QA/AQA
В русском IT регулярно всплывает формулировка «русский FAANG» и многие хотят туда попасть. В этом посте на основе своего опыта разберу, стоит ли оно того.
Начнем с того, что каждый под словосочетанием русский FAANG подразумевает разное. Есть как минимум: 1. ВАСЯ: ВК, Альфа, Сбер, Яндекс 2. МЯСОВАТА: Mail (VK), Яндекс, Сбер, Озон, Валдберрис, Авито, Теле2, Альфа 3. Мой любимый - ОБОСРАЛСЯ: Озон, Билайн, ОККО, Сбер, Рамблер, Атол, ЛамодаТех, Совкомбанк, Яндекс
В целом есть множество различных вариаций и аббревиатур, но нет одной единственно правильной. Почему - везде есть свои проблемы и преимущества. Всё в большей степени зависит от проекта. Внутри одной и той же компании может быть и круто, и очень плохо. Поэтому и нет четкого списка "топ компаний", все оценивают по разным критериям.
Так стоит ли QA/AQA и другим стремится в ВАСЯ или можно ограничится ОБОСРАЛСЯ или даже обычными мелкими компаниями / стартапами?
Чего стоит попасть туда (насколько это сложно)
У многих есть ощущение, что российский бигтех - это нечто недосягаемое. Почти как западный FAANG.
Если говорить про автоматизацию тестирования и смежные роли, картина выглядит иначе. Я скажу больше, выходя на рынок как AQA - вы с большей долей вероятности попадете именно в бигтех.
Автоматизация сегодня - одна из самых востребованных зон в крупных компаниях. Большой продукт, частые релизы, много интеграций - без автотестов это сложно поддерживать.
Плюс последние годы усилили тренд на оптимизацию затрат. Ручное тестирование постепенно сокращается, а автоматизация растет. Считается, что один AQA может закрывать задачи нескольких QA.
Поэтому спрос на автоматизаторов в бигтехе стабильно высокий. И в этом смысле двери туда открыты куда шире, чем кажется со стороны.
Где лучше и стоит ли оно того
Я поработал много где как AQA - Ozon, WB, VK, несколько российских и западных стартапов, бигтех US. И могу с уверенностью сказать, что тут не угадаешь, везде всё по разному. Например, в одном из криптостартапов я встретил лучшие процессы, что видел в жизни, а в двух из бигтехов - миллион токсиков, невероятную бюрократию и в целом не очень классные процессы.
Поэтому мое личное мнение - умирать ради работы в конкретной компании вообще того не стоит.
Проекты могут быть плохие и хорошие как в бигтехах, так и в мелких компаниях. Да, в бигтехах часто процессы получше, но это далеко не всегда так. Ну а хороший оффер могут дать и там, и там.
В общем, тут стоит выбирать по сумме условий и не руководствоваться именем компании, т.к. оно часто ничего не значит.
Те же самые "интересные задачи" есть везде, а в стартапах они часто даже круче и челленджовее.
Что в сухом остатке
При прочих равных условиях кроме записи в резюме работа в бигтехе не дает ровным счетом ничего. Везде всё по разному и может оказаться так, что в стартапе проект будет в миллион раз лучше по всем параметрам. Ну а строчку в резюме всегда можно придумать, если так уж хочется.
Всем спасибо за внимание! В комментариях готов подискутировать на эту и смежные темы! В своем блоге Telegram также пишу про тестирование и автоматизацию, ну и в целом про карьеру в сфере IT. Всегда рад новым читателям!)
Вышел наш новый подкаст #Криптонит_говорит про тестирование! Мы обсудили тренды профессии, поговорили об образовании в этой сфере и узнали, почему разрыв между разработкой и тестированием сокращается (и так будет и дальше).
Смотрите и слушайте выпуск на любой удобной платформе:
Приглашаем тестировщиков на митап. Вместе с Moscow QA подготовили три ярких доклада:
Помогите, flaky!
Екатерина Лахтина, тимлид QA UGC в 2ГИС, поделится подходом, который помогает находить и устранять flaky‑тесты, снижать ручную работу и добавлять автоматизацию.
Как прокачать автотесты с 0 до keyword-driven
Анастасия Нестерова, QA Engineer, расскажет, какие методы пробовали, где спотыкались и как в итоге выстроили процесс на стеке Playwright + TypeScript.
Вайб‑кодинг в тестировании с позиции менеджера
Виктория Дежкина, менеджер направления, поделится плюсами и минусами нового подхода в тестировании: как влияет на команду, какие есть риски и стоит ли вообще пробовать.
Как я написал 87 000 сопроводительных писем - про разработку помощника для поиска работы.
Сразу уточню - писал сопроводительные само собой не сам. Мы с командой работаем над ИИ-ассистентом для поиска работы и эти 87 000 писем были отправлены пользователями сервиса в рамках бета-тестирования.
За этой цифрой - месяцы экспериментов, правок и неудачных гипотез. В этом посте поделюсь, с какими сложностями мы столкнулись и как их решили.
Задача
Изначально мы хотели решить довольно простую на первый взгляд проблему: автоматизировать написание сопроводительных писем.
Но быстро стало понятно, что «просто генерировать текст» - бессмысленно.
Цель изменилась. Нужно было не просто прикладывать письмо к отклику, а сделать его:
релевантным конкретной вакансии
не шаблонным
не выглядящим как типовой текст нейросети
понятным для HR за несколько секунд
И вот тут начались сложности.
С чем столкнулись
Шаблонность моделей. Даже при хорошем промптинге тексты начинали повторяться по структуре и формулировкам.
Разные ожидания HR. Кто-то предпочитает краткость, кто-то - структуру, кто-то - конкретные достижения в цифрах.
Изменяющиеся требования вакансий. Один и тот же стек может быть описан по-разному, и формальное совпадение по ключевым словам не гарантирует релевантности.
Ограничения платформ. Изменения на стороне hh влияли на логику работы системы, и часть архитектуры приходилось пересобирать.
В какой-то момент стало ясно, что проблема глубже.
Главный вывод
После десятков тысяч писем стало очевидно:
Проблема не в том, что сопроводительные «плохие». Проблема в том, что в них не видно релевантности.
HR тратит на письмо буквально несколько секунд. Если за это время не становится понятно, почему кандидат подходит - письмо закрывается.
Поэтому мы изменили подход.
Система теперь не «пишет красиво». Она сначала сопоставляет требования вакансии с опытом пользователя и только потом формирует текст, где это соответствие явно показано.
Что изменилось в результате
После 87 000 отправленных писем тексты стали короче, конкретнее, привязанными к требованиям вакансии, менее шаблонными.
Ну а параллельно дорабатывались и другие части системы:
фильтрация релевантных вакансий
автоматизация откликов
работа с онлайн-тестами
механизмы приоритизации
Что по итогу имеем сейчас
Проект находится в стадии бета-тестирования. Мы продолжаем собирать фидбек и корректировать логику, особенно в части сопоставления опыта и требований.
История с сопроводами по большей части пройдена, но осталось ещё множество аспектов для улучшений.
Кому интересно - могут попробовать бота бесплатно. В блоге можно найти более подробную информацию. Также там пишу про развитие проекта и проблемы, с которыми сталкиваемся.
Когда в Android-проекте ≈800 модулей и 37 000 unit-тестов, полный прогон на CI легко превращается в полдня ожидания. У нас было ровно так: больше 3 часов на полный запуск — и ощущение, что локально это вообще не вариант. А потом команда нашла настоящие причины тормозов и довела прогон до 12 минут.
Бесплатный мини-курс для специалистов по ручному тестированию. От нейросети до тест-кейса: практическое применение ИИ в тестировании.
Привет, Хабр! Я — Николай Корнетов, ведущий инженер-тестировщик в IBS. Мы с коллегами записали бесплатный мини-курс об использовании искусственного интеллекта для задач ручного тестирования.
Курс состоит из 8 видео. В них я расскажу, как нейросети могут упростить и автоматизировать вашу работу: разберу принципы работы больших языковых моделей и их ограничения, покажу на реальных примерах, как ИИ помогает ревьюить документацию, создавать чек-листы и тест-кейсы, придумывать тестовые данные и решать другие задачи.
Все уроки курса — на нашем сайте. Смотри видео, применяй новые знания на практике и делись своими впечатлениями в комментариях.
Когда я вижу очередной лендинг какого-нибудь IT-курса, у меня каждый раз возникают два одних и тех же вопроса. Они касаются самого интересного - видеоотзывов выпускников.
Вопрос №1. Большинство IT-школ ежегодно набирают сотни и тысячи студентов. По статистике трудоустройств с лендингов этих же школ сотни и тысячи выпускников должны ежегодно получать офферы.
Почему тогда на сайтах курсов обычно лишь 5-10 видеоотзывов от выпускников, а не сотни?
Вопрос №2. Главная гордость любого новичка - это его первая IT-компания. Он долго и упорно учился, искал работу и, наконец, начал свою карьеру в IT. И ему, скорее всего, хочется поделиться своей радостью со всем миром.
Почему тогда даже этот десяток выпускников в видеоотзывах обычно ничего не говорит про самое важное - в каких именно IT-компаниях они теперь работают?
Пришлось отдуваться за коллег - хотя по сравнению с ними мы очень маленькие и никогда не набирали больше 75 студентов в год.
На рынке сейчас царит жуткая путаница между совершенно разными AI-QA-ролями. Получилось так, что я прошла через все три роли. Если вы планируете карьерный переход, то вот в чем разница между ними:
1️⃣ QA Engineer с инструментами ИИ Цель: Эффективность. Реальность: Вы тестируете традиционный детерминированный продукт. Вы просто используете ChatGPT для генерации тест-кейсов или Cursor/Claude Code для автоматизации. Это «вайб-кодинг» для старых добрых задач.
2️⃣ AI QA Engineer Цель: Базовая проверка интеграции. Реальность: Тестирование того, как чат с LLM работает внутри условной CRM-системы. Вы проверяете, вежлив ли бот и не «поехал» ли интерфейс. Вы всё ещё используете ассерты (asserts), просто с небольшим «привкусом» нейросетей.
3️⃣ ML Evaluation Engineer (Инженер по оценке ML-моделей) Цель: Управление хаосом в недетерминированных моделях. Реальность: Вы не используете ассерты; вы используете статистические метрики. Инструменты: Фреймворки для оценки (например, LM Evaluation Harness), модули метрик на Python.
Почему третий вариант — это совсем другое:
Вероятность > Детерминизм: Вы не проверяете, что . Вы проверяете, является ли показатель метрики 0.87 приемлемым для вашего конкретного сценария.
Стоимость как метрика: В ML Eval затраты токенов так же важны, как задержка (latency). Если ваш агент «умный», но стоит $2 за запрос — вы провалили тест.
Скорость решает всё: Здесь быстрая 7B-модель может выиграть у медленной 70B. Тестирование производительности здесь не «доп. опция», а база.
Не смогли смириться с поражением - и к чему нас это привело. Как мы воскресили ИИ-помощника для поиска работы
Привет, Хабр.
В декабре наш ИИ-ассистент для поиска работы фактически перестал работать. Изменения на стороне платформ, ограничения, поломанные сценарии - всё то, из-за чего большинство подобных проектов обычно закрываются или уходят в «заморозку».
Самый логичный вариант был простой:
«Ну ок, рынок поменялся, едем дальше».
Но мы решили иначе.
Мы не смогли смириться с тем, что квалифицированные специалисты по-прежнему тратят часы жизни на клики, шаблонные отклики и бесполезную рутину. Поэтому вместо точечных фиксов мы решили не чинить старое, а пересобрать всё с нуля.
Так начался путь к OfferMate 2.0.
Главная мысль оказалась неожиданно простой:
Автоматизация должна быть не только быстрой, но и естественной.
Настоящий цифровой ассистент должен вести себя как человек:
выбирать вакансии осмысленно;
работать с паузами и приоритетами;
не выглядеть как бот;
и не ломаться при реальной нагрузке.
Именно вокруг этого принципа мы и пересобрали архитектуру продукта.
Что теперь умеет OfferMate 2.0
🤖 Отклики только на релевантные вакансии Ассистент анализирует ваш опыт и требования работодателя и выбирает вакансии, которые действительно подходят, а не просто совпадают по ключевым словам.
👤 Имитация человеческого паттерна поведения Система воспроизводит действия пользователя: паузы, разную скорость, приоритеты. Это делает работу максимально естественной и безопасной.
✍️ Персонализированные сопроводительные письма Каждое письмо формируется под конкретную вакансию и компанию - на основе вашего опыта и требований позиции.
📈 Контроль и аналитика Пользователь видит, что происходит в системе, и может управлять стратегией поиска.
🧩 Новые функции
автоматическое прохождение онлайн-тестов;
поддержка одновременных откликов с нескольких аккаунтов.
Про релиз
12 февраля в 12:00 мы открываем доступ к OfferMate 2.0.
Первая волна будет ограничена 50 пользователями, а доступ открыт на 3 дня. Это осознанное ограничение - чтобы сохранить стабильность системы и быстро собрать качественную обратную связь.
Поучаствовать в тестировании в числе первых можно будет в нашем телеграм канале, в нём делимся всеми новостями проекта:
В процессе тестирования верстки быстро становится понятно: один и тот же интерфейс может выглядеть аккуратно на макете, но разваливаться на практике. Чаще всего это проявляется в длине текста, переносах строк, состояниях элементов и отступах.
Рассказываем, на что обращаем внимание при проверке верстки и какие моменты проверяем в первую очередь.
1️⃣ С чего начинаем тестирование верстки?
При тестировании верстки мы сначала наполняем блоки разными текстовыми данными. Это сразу показывает, где интерфейс начинает ломаться. Дальше проверяем:
максимально короткие значения — точка, пробел;
максимально длинный текст, который можно ввести;
соответствие ограничениям из постановки — например, максимально доступно 64 символа.
Если ограничений в ТЗ нет, смотрим, какой тип поля используется в базе данных. Часто это varchar(255), от этого и отталкиваемся при проверке.
2️⃣ Почему проверяем текст с пробелами и без?
Очень частый кейс: текст с пробелами красиво переносится, а без пробелов — вылезает за границы или ломает блок.
Иногда нам кажется, что пользователь так точно не напишет, но ничто не мешает ему назвать кнопку: «дезоксирибонуклеиноваякнопка». Поэтому проверяем с пробелами и без пробелов, а еще смотрим, как ведет себя перенос строк.
Для таких проверок удобно использовать максимально широкие буквы:
для кириллицы — «Щ»;
для латиницы — «W».
Это простой способ увидеть помещается ли текст, переносится ли он корректно на следующую строку и не вылезает ли за контейнер.
3️⃣ Что проверяем в макете?
Например, в макете Figma мы смотрим:
И, конечно, отступы между всеми элементами по вертикали и горизонтали.
4️⃣ Как проверяем реализацию?
В браузере используем стандартные DevTools: смотрим вкладку Elements + разделы Styles и Computed.
Computed удобнее — отображаются итоговые значения после применения всех CSS-правил: размер шрифта, высота строки, цвета, отступы.
Так проще напрямую сравнивать реализацию с макетом и не теряться в длинных CSS-цепочках.
5️⃣ Что важно знать о состояниях элементов?
Чаще всего это кнопки. В DevTools можно вручную включить состояния:
:hover
:active
:focus
Позволяет увидеть нужный цвет, проверить границы и сравнить с макетом, даже если мышь сейчас не наведена на элемент.
6️⃣ На что еще обращаем внимание?
Отступы могут быть реализованы через padding (внутренний) и margin (внешний).
Важно помнить, что высота текстового блока определяется line-height. Если высота строки отличается от макета — поплывут и расстояния между элементами, даже если padding и margin заданы верно.
7️⃣ Когда удобно считать руками, а когда — линейкой?
Иногда проще посмотреть padding и margin и сложить их значения. Но если блоки визуально хорошо видны, помогает линейка: измеряем расстояния не только в браузере, но и вообще на экране.
Для текста и иконок лучше ориентироваться на границы блоков и отступы, а не пытаться измерять «на глаз».
При этом в тестировании верстки почти всегда появляется вопрос баланса: где достаточно базовых проверок, а где уже начинается избыточный pixel perfect.
Интересно сравнить подходы: какие проверки верстки вы считаете обязательными в своей практике, а какие — избыточными?
Почему хороший тестировщик — это не тот, кто нашел больше всего багов
В тестировании легко попасть в простую ловушку — начать измерять свою ценность количеством найденных багов. Чем больше тикетов, тем полезнее работа. На первый взгляд логика кажется железной.
На практике все сложнее. И чем опытнее становится тестировщик, тем реже он гордится просто цифрами.
Количество багов ничего не говорит само по себе
Сто найденных дефектов могут означать две совершенно разные вещи:
продукт реально нестабилен;
тестирование началось слишком поздно.
Если баги находятся пачками в самом конце разработки, это не успех, а симптом. Хороший тестировщик старается сделать так, чтобы часть проблем не доходила до баг-трекера вообще.
Сильный тестировщик думает раньше, чем тестирует
Тестирование начинается не с чек-листов и не с автотестов. Оно начинается с вопросов.
что здесь может пойти не так;
где система уже ломалась;
какие изменения самые рискованные.
Человек, который подключается к обсуждению требований и дизайна, часто предотвращает больше дефектов, чем тот, кто просто проверяет готовую фичу.
Баг-репорт — это не обвинение
Новички иногда воспринимают баг как доказательство чьей-то ошибки. Отсюда агрессивные формулировки и желание «поймать» разработчика.
Опытный тестировщик понимает — баг-репорт это способ помочь команде. Хорошее описание проблемы экономит время всем:
понятно, что сломалось;
понятно, как воспроизвести;
понятно, почему это важно.
Чем меньше эмоций и больше контекста — тем лучше работает процесс.
Автотесты — это не самоцель
Автоматизация часто превращается в гонку — у кого больше тестов, у кого выше покрытие. Но цифры сами по себе ничего не гарантируют.
Хороший тестировщик задает другие вопросы:
ловят ли эти тесты реальные проблемы;
можно ли им доверять;
не мешают ли они менять код.
Иногда удаление десятка бесполезных автотестов приносит больше пользы, чем написание сотни новых.
Хороший тестировщик думает о пользователе, а не о сценарии
Чек-листы и тест-кейсы важны, но реальный пользователь почти никогда не действует по ним.
Он кликает не туда, вводит странные данные, прерывает процессы и возвращается позже. Умение выйти за рамки сценариев отличает опытного тестировщика от формального.
Качество — это ответственность всей команды
Одна из самых токсичных идей в тестировании — что за качество отвечает только QA. Это удобно, но не работает.
Сильный тестировщик не берет качество на себя полностью. Он помогает команде видеть риски, объясняет последствия и участвует в решениях. Но ответственность остается общей.
Карьерный рост в тестировании — это не про инструменты
Инструменты меняются быстро. Сегодня один фреймворк, завтра другой. Знание конкретного тулкита редко определяет уровень специалиста.
Гораздо важнее:
умение анализировать систему;
понимание, где искать проблемы;
способность говорить с разработчиками и бизнесом на одном языке.
Именно это делает тестировщика ценным, а не список технологий в резюме.
В итоге
Хороший тестировщик — это не тот, кто нашел больше всего багов. Это тот, кто:
помогает находить проблемы раньше;
думает о рисках, а не о галочках;
пишет понятные баг-репорты;
работает с командой, а не против нее.
Такие люди редко кричат о своих результатах. Но именно благодаря им продукт перестает ломаться в самых неожиданных местах.
Как оставаться релевантным на рынке QA/AQA/SDET в 2026: опыт, харды, софты, ответы
Последнее время всё чаще слышу вопросы про состояние рынка. Многие говорят, что рынок «умер», вакансий стало меньше, а требования выросли настолько, что найти работу почти нереально.
Часто это выглядит так: человек активно откликается, ходит на собеседования, делает тестовые задания, общается с рекрутерами. А на выходе получает либо отказы без конкретных причин, либо формулировки вроде «вы хороший специалист, но нам нужен немного другой профиль».
Ощущение, что стало сложнее, не обманчиво. Рынок действительно изменился за последние один-два года. Но парадокс в том, что именно в таких условиях многим стало проще выделяться. Не потому, что кандидатов стало меньше, а потому, что вырос разрыв между теми, кто выглядит релевантно, и теми, кто нет.
Я регулярно общаюсь с QA, AQA и SDET, которые находятся в активном поиске, и сам продолжаю проходить собеседования, чтобы понимать, как именно сейчас устроен процесс найма. И вот что я понял из всех историй: сегодня выигрывает не самый наглый кандидат (как было раньше), а тот, кто хорошо понимает свой опыт и умеет его объяснять.
Что изменилось
Еще один-два года назад часто работала простая схема: уверенное резюме плюс нормальная подача давали высокую вероятность оффера. Во многих компаниях в детали погружались поверхностно, опыт оценивали в общих чертах, а неточности прощались, если кандидат выглядел уверенно.
Сейчас ситуация другая. Вакансий в ряде направлений стало меньше, требования выросли, а собеседования стали заметно глубже. Интервьюеры чаще проверяют логику решений и реальный вклад кандидата в проекты.
Это не «заговор рынка», а естественная фильтрация. Когда выбор кандидатов большой, требования становятся строже.
Почему в этом есть плюсы
Жесткий рынок хорошо отсеивает слабые места. Причем чаще всего самые базовые.
На собеседованиях у ребят регулярно всплывают одни и те же проблемы:
человек говорит, что строил фреймворк, но не может связно объяснить архитектуру;
упоминает автотесты, но не понимает, почему был выбран конкретный стек;
рассказывает про CI, но путается в вопросах стабильности;
заявляет ответственность за качество, но не может описать процессы и зоны ответственности.
Большинство кандидатов «падает» не на сложных вопросах, а на уточняющих. На этом фоне специалист, который осознанно разбирается в своем опыте и может его структурировано рассказать, сразу выглядит сильнее, даже без громких компаний в резюме.
Как сейчас смотрят на опыт
На интервью все меньше внимания уделяется формальным строчкам в резюме и все больше мышлению.
Интервьюеру важно понять:
Почему было принято именно такое решение;
Какие были трудности;
Как проблемы диагностировали;
Какие выводы сделали.
Если опыт не структурирован, ответы быстро разваливаются. Если же кандидат сам хорошо понимает, что он делал и зачем, он спокойно проходит даже при неидеальном бэкграунде.
Поэтому сейчас важна не красивая история, а осознанное понимание своего опыта.
Что с этим делать
Минимальный практический набор:
Разложить свой опыт по зонам - архитектура, API, UI, CI/CD, процессы, инциденты.
Подготовить ответы в формате «проблема - решение - результат - выводы». (Для шарящих - по STAR)
Прогнать опыт через уточняющие вопросы и проверить, где ответы выглядят слабо или непоследовательно.
Упаковать резюме как набор конкретных ответов - что улучшал, что оптимизировал, за что отвечал + быть готовым это подтвердить.
Вывод
Рынок действительно стал сложнее. Но именно поэтому он стал более комфортным для тех, кто держит фокус на релевантности, понимает свой опыт и готовится к проверке.
Если относиться к поиску работы как к инженерной задаче, жесткий рынок перестает быть проблемой и становится рабочей средой.
Ну а всем нуждающимся желаю скорее обрести себя на сегодняшнем рынке! Готов подискутировать на смежные темы в комментариях)
Автор рассказывает об опыте работы с новым открытым табличным форматом (OTF) Paimon от разработчиков Apache Flink, представляет практические выводы, которые были сделаны на промышленных средах; а также проводит репрезентативное тестирование, где иллюстрирует ключевые практические сценарии.
Появление open table formats исполнило вековую мечту data-инженеров: совместило эффективность хранения и чтения Apache Parquet с возможностью обновления данных без полной их перезаписи. Достигается это за счет парадигмы Merge-On-Read и «отложенного удаления», когда информация об удалении старых версий записи пишется в deletion-файлы. Для фреймворков потоковой обработки, например Flink, это открывает возможности по обновлению данных прямо в Data Lake в режиме, близком к реальному времени, а для движков пакетной обработки — Spark, Impala, Trino, StarRocks — сокращает расход ресурсов на MERGE новых порций данных в витрины.
Процедурное SQL-расширение в Lakehouse-платформе — новые возможности для работы с данными
В блоге технологического партнера GlowByte вышла новая статья. Команда Data Sapience рассказала о реализации процедурного расширения для работы с MPP-движками Lakehouse-платформы данных Data Ocean Nova, которое стало доступным для пользователей.
Ребята рассказывают о возможностях, применимости и сценариях использования процедурного языка в аналитической платформе данных и делятся планами по развитию Data Ocean Nova.
Рынку плохо? Работу найти нереально? — Это твой шанс 🚀
Последнее время всё чаще вижу одну и ту же ситуацию.
Человек активно ищет работу: отклики, собеседования, тестовые, разговоры с HR. А на выходе — либо отказы без внятного объяснения, либо формулировки вроде «вы хороший специалист, но нам нужен чуть другой профиль» 🤷♂️
И почти всегда звучит один и тот же вывод: «рынок умер, конкуренция бешеная, сейчас вообще нереально найти работу».
Отчасти это правда — рынок действительно стал жёстче. Но вот что интересно: именно в таких условиях многим стало проще выделяться 💡 Не потому что кандидатов стало меньше, а потому что вырос разрыв между теми, кто выглядит релевантно, и теми, кто — нет.
Я регулярно общаюсь с QA / AQA / SDET, которые сейчас находятся в активном поиске, и сам продолжаю проходить собеседования, чтобы держать руку на пульсе. И главный вывод из этого опыта простой: сегодня выигрывает не самый громкий кандидат, а тот, кто чётко понимает свой опыт и умеет его объяснять.
Ниже — что именно изменилось и как этим пользоваться 👇
Что изменилось
Ещё 1–2 года назад часто работала простая схема: уверенное резюме + нормальная подача = высокая вероятность оффера 😌
Многие компании:
не сильно углублялись в детали;
смотрели на опыт в общих чертах;
закрывали глаза на неточности, если кандидат выглядел уверенно.
Сейчас ситуация другая:
вакансий в ряде направлений стало меньше 📉;
требования заметно выросли;
собеседования стали глубже и детальнее 🔍;
интервьюеры чаще проверяют логику решений и реальный вклад кандидата.
Это не “заговор рынка”, а обычная фильтрация: когда выбор большой — требования растут.
Почему в этом есть плюс
Жёсткий рынок хорош тем, что он быстро отсеивает слабые места ⚠️ Причём чаще всего — самые базовые.
Типичные проблемы, на которых кандидаты “сыпятся”:
говорят, что строили фреймворк, но не могут связно объяснить архитектуру;
упоминают автотесты, но не понимают, зачем выбран конкретный стек;
рассказывают про CI, но путаются в вопросах стабильности и flaky-тестов 🤯;
заявляют про ответственность за качество, но не могут описать процессы.
Большинство падает не на сложных вопросах, а на уточняющих. На этом фоне человек, который осознанно разбирается в своём опыте, сразу смотрится сильнее 💪 Даже без “топовых” компаний в резюме.
Как сейчас смотрят на опыт 🎭
На интервью всё меньше внимания формальным строчкам и всё больше — мышлению 🧠
Интервьюеру важно понять:
почему было принято именно такое решение;
какие были ограничения;
что пошло не так;
как проблему диагностировали;
какие выводы сделали.
Если опыт не структурирован — ответы быстро разваливаются. Если опыт разобран и понятен самому кандидату — он спокойно проходит даже при неидеальном бэкграунде.
Поэтому сейчас важна не “красивая история”, а осознанное понимание того, что ты делал.
🎯 Ключевой навык сегодня — релевантность
Недостаточно просто быть QA или AQA.
Важно быть релевантным:
конкретной роли;
стеку компании;
типу продукта;
уровню ответственности.
Это проявляется в деталях:
какие кейсы вы выбираете;
как формулируете достижения;
как отвечаете на вопросы «почему?» и «а что если иначе?».
Иногда достаточно слегка пересмотреть подходы или формулировки — и это сильно влияет на конверсию.
Что с этим делать 🛠
Практический минимум: 1️⃣ Разложить опыт по зонам: архитектура, API, UI, CI/CD, процессы, инциденты. 2️⃣ Готовить ответы в формате: проблема → решение → результат → выводы. 3️⃣ Прогнать опыт через уточняющие вопросы — здесь хорошо помогают LLM. 4️⃣ Упаковать резюме как набор сигналов 🚦 и быть готовым их подтвердить.
Вывод 🧠
Рынок стал сложнее — это факт. Но именно поэтому он стал выгоднее для тех, кто:
держит фокус на релевантности;
понимает свой опыт;
готовится к проверке;
не теряется на уточнениях.
Если относиться к поиску работы как к инженерной задаче, “жёсткий рынок” превращается в возможность 🚀
👉 Если интересно — глубже разбираю эту и другие интересные темы в своем Telegram-канале, ну а также делюсь там инсайдами по рынку, собеседованиям и росту в AQA / SDET.
. Вы проверяете, является ли показатель метрики 0.87 приемлемым для вашего конкретного сценария.
