Становимся продвинутым QA

⚡️Mentorpiece Vacy Index август 2026: Число вакансий по тестированию AI-приложений растет третий месяц подряд 🟡 Ежедневный анализ открываемых и закрываемых вакансий в более чем 2000 IT-компаний начал показывать тренд роста вакансий, где требуется тестирование AI-приложений. Процент компаний с открытыми вакансиями AI QA и ML Evaluation:

июнь: +1.0% июль: +0.3% август: +0.2%

Пусть этот рост идет от нулевой базы и пока он не очень значителен, но на фоне продолжающих падение Manual QA и Automation QA/Senior QA внушает хоть какую-то надежду. Как выглядят такие вакансии по тестированию AI, можно увидеть в превью того, что собирают AI-агенты по российскому или 🇺🇸 американскому рынку. Лилия Урмазова • Что в августе с наймом по другим IT-ролям/странам • Вакансии AutomationQA/SeniorQA и AI QA/ML Evaluation - превью ежедневно обнаруживаемых AI-агентами вакансий. Что с IT-наймом будет дальше? Индикатор активности IT-найма за сентябрь появится в Становимся продвинутым QA.

Как обычно тестируются приложения, сгенерированные с помощью ИИ? QA-агенты проверяют UI и проводят end-to-end тесты. Но что, если заглянуть глубже? Если нам нужно протестировать непосредственно сгенерированный код? Последний год я работаю над NDA-проектом в глобальной компании, ориентированной на профессиональную IT-разработку. Мы создаем приложение новой категории, которая только обретает очертания. Недавно мне разрешили поделиться некоторыми подходами, над которыми мы работаем. И я представила их на международной конференции PyData. Судя по 30-минутной сессии вопросов и ответов после выступления, тема многих заинтересовала. Как только видео с конференции будет готово, я опубликую его вместе с подробными пояснениями. Лилия Урмазова

Каждый запуск пайплайна стоит денег API Anthropic не блокирует доступ мгновенно, как только баланс достигает нуля. В итоге одна незамеченная за ночь ошибка может привести к тому, что баланс AI-токенов не просто обнулится, а уйдет в глубокий минус. Когда тестовый скрипт начинает вести себя как оставленный без присмотра банкомат, реактивного мониторинга уже недостаточно. Нам нужна архитектурная дисциплина. Вот стратегии, на которые я опираюсь, чтобы держать расходы на ML-оценку под контролем: СНАЧАЛА МОКИ Симулирую ответы модели для детерминированных, структурных частей пайплайна. Реальные вызовы LLM остаются исключительно для недетерминированного слоя "рассуждений", который действительно требует валидации. ИЗОЛИРОВАННЫЕ ТОЧКИ ВХОДА В МОДУЛИ Небольшие блоки if __name__ == "__main__": позволяют тестировать логику подмодулей и граничные случаи без запуска полного агентского цикла. ОТЛАДКА НА МИКРО-БАТЧАХ Я отлаживаю код на 1-3 тщательно отобранных наборах данных. Масштабирование до полного тестового набора происходит только после того, как тестовая обвязка полностью проверена. СТОИМОСТЬ КАК АРХИТЕКТУРНОЕ ОГРАНИЧЕНИЕ В нашем проекте задержка выполнения и стоимость токенов отслеживаются непрерывно - как через Langfuse, так и с помощью внутренних метрик. Им придается такое же значение, как и корректности работы. В этом подходе есть еще один уровень, который меняет то, как вся команда реагирует на аномалии: читать далее

Почему ваш LLM-as-a-Judge "слишком вежливый" (и как с этим бороться) Я часто вижу, как команды внедряют LLM-as-a-Judge и радуются стабильным метрикам 1.0. На деле это не показатель качества системы, а показатель того, что «судья» слишком добрый и апрувит всё подряд, включая грубые нарушения бизнес-логики. Простой пример: клиент требует возврат за кроссовки не того цвета (ошибка комплектации), а бот вежливо отказывает и предлагает купон на 10%. Политика компании требует полного возврата средств. Бот нарушил ключевое правило - но сделал это учтиво. Обычный LLM-судья с высокой вероятностью поставит такому ответу 5 из 5. В посте я разобрала три типовых искажения, которые превращают судью в «поддакивателя», и как их нейтрализовать через архитектуру промпта: • ПЕРСОНА - без жесткой авторитетной роли (например, «старший корпоративный аудитор по комплаенсу») модель скатывается к Central Tendency и ставит безопасные средние баллы. • ЗАДАЧА - без явной привязки к политике компании срабатывает Sycophancy Bias: эмпатичный ответ автоматически считается «отличным». • ШАГИ - если просить финальную оценку сразу, включается Precedence Bias, и модель галлюцинирует обоснования под уже выставленную цифру. Спасает строгий Chain-of-Thought с цитатами из политики до вердикта. Отдельно я рассказала, почему стабильная метрика 1.0 - это красный флаг, и что мы делаем на проекте, когда судью становится слишком легко порадовать: читать далее

Почему мне нравится работать ML Evaluation инженером после 20 лет опыта в QA Многие спрашивают, как мне живется в моей новой роли. Этот пост - ответ на вопрос. ПОЧЕМУ МНЕ НРАВИТСЯ В ML EVALUATION: • Сложная архитектура вместо стандартной автоматизации. Когда "вспомогательные таски" включают кастомные методы клонирования удаленных репозиториев с датасетами в зависимости от условий и содержимого или работу с системными процессами - инфраструктура превращается в настоящую инженерную задачу. Чистый поддерживаемый код и постоянный рефакторинг - то, что меня по-настоящему зажигает. • Целый отдельный мир новых понятий. Качество - это уже не просто малое количество багов. Это экономика токенов, перформанс, A/B тестирование разных моделей и понимание того, как все устроено на уровне embeddings. По ссылке - еще три значащих пункта (включая, конечно, и финансовую стабильность): читать далее

⚡️Mentorpiece Vacy Index июль 2026: IT-найм продолжает падать, но сокращение Automation замедлилось 🟠 Появились признаки улучшения ситуации по Automation QA и Senior QA – число нанимающих компаний по этим ролям за месяц уменьшилось всего на 0.2%. Это минимальное падение за последние три месяца, и оно в рамках погрешности измерений. По сравнению с Manual QA, где меньше чем за полгода процент нанимающих компаний упал с 40.7% до 21.6% (❗️), ситуация почти нормальная. • Что в июле с наймом по другим IT-ролям/странам • Вакансии AutomationQA/SeniorQA и AI QA/ML Evaluation - превью ежедневно обнаруживаемых AI-агентами вакансий. Что с IT-наймом будет дальше? Индикатор активности IT-найма за август появится в Становимся продвинутым QA. Лилия Урмазова

Пройдет ли AI код-ревью? ИИ может за час сделать то, на что раньше уходили недели. Но готовы ли вы выкатить этот результат в прод без код-ревью от сеньора? 🚩 Скорее всего, нет. «Работающий код» больше не критерий качества. Критерий - поддерживаемый код. По мере того как мы перекладываем задачи на ИИ-агентов, главный инженерный вопрос смещается с «Как мне это написать?» на «Насколько чисто это написано?» Почему код, который «просто работает», может оказаться бомбой замедленного действия: • СПАГЕТТИ-КОД. Агент вполне может решить сложную задачу одной функцией на 500 строк. Юнит-тесты пройдут, но поддержка превратится в кошмар. ИИ по умолчанию выбирает стратегию «лишь бы работало», игнорируя SOLID. • БЕЗОПАСНОСТЬ И «ГАЛЛЮЦИНАЦИИ». LLM опирается на частые паттерны из обучающих данных - а они не всегда безопасны. Захардкоженные креды, устаревшие уязвимые библиотеки - всё это регулярно подтягивается в кодовую базу просто потому, что «выглядело уместно». • ЛОВУШКА ЭФФЕКТИВНОСТИ. Фронтенд выглядит отлично, но что под капотом? Оптимальный алгоритм или вложенный цикл O(n²), который намертво ляжет на реальных объемах данных? Написание кода стремительно обесценивается. Умение ревьюить, аудировать и оркестровать становится главным навыком. О практике двойного ревью AI-кода, которую мы внедрили на проекте, и о том, почему одного функционального тестирования уже недостаточно, читайте в полной версии: читать далее

Как короткое слово может превратить ваш AI-продукт в юридический кошмар В сфере ML Evaluation, особенно при использовании подхода LLM-судьи, мы часто попадаемся в ловушку «гало-эффекта» (Halo Effect). Если ответ тестируемой AI-модели звучит авторитетно и профессионально, LLM-судья автоматически ставит высокий балл, напрочь упуская из виду смысл. ЛОВУШКА «ЛЕНИВОГО СУДЬИ» Представьте инструмент для краткого изложения юридических контрактов. Стандартный промпт: «Оцени резюме документа по шкале от 1 до 5 по точности и беглости». Фраза в документе: «Поставщик НЕ несет ответственности за убытки, превышающие 1 млн долларов». Резюме модели: «Поставщик несет ответственность за все убытки, превышающие 1 млн долларов». Оценка LLM-судьи: 4.5 / 5. Для судьи тексты выглядят почти идентично: ключевые слова на месте, синтаксис идеален. Но пропущенное «не» - это разворот смысла на 180 градусов, и в продакшене такая ошибка стоит миллионы. Корень проблемы в том, что LLM-судья по умолчанию оценивает форму, а не логические операторы. Стиль маскирует семантическую инверсию. В полной версии разобрала, как структурировать промпт для «критически мыслящего» судьи через принудительную деконструкцию текста (извлечение отрицаний и кванторов, верификация привязок, штраф за инверсию), и почему подозрительно высокие метрики - почти всегда симптом проблемы именно в промпте судьи: читать далее

⚡️Mentorpiece Vacy Index июнь 2026: IT-найм продолжает падать 🟠 Процент нанимающих IT-компаний по ролям Automation QA и Senior QA за месяц снизился, продолжая небольшое, но постоянное падение последние месяцы. • Что в июне с наймом по другим IT-ролям/странам (спойлер: автоматизация плохо себя чувствует и в 🇺🇸, а AI-роли растут, но пока слабо) • Вакансии AutomationQA/SeniorQA и AI QA/ML Evaluation - превью ежедневно обнаруживаемых AI-агентами вакансий. Что с IT-наймом будет дальше? Индикатор активности IT-найма за июль появится в Становимся продвинутым QA.

Теперь ежемесячно публикуем такую инфографику по индексу IT-найма:

🔻 Российское IT падает уже семь месяцев С декабря получаю многочисленные сообщения о сокращениях во всё большем и большем числе российских IT-компаний. Любой кризис не вечен. Вопрос состоит только в том, как определить наступление этого самого момента. Обычно ориентируются на число открытых сейчас IT-вакансий. Но это относительный параметр (1000 открытых вакансий для конкретной IT-роли – это много или мало?), который не учитывает, что рост как числа IT-компаний, так и соискателей продолжается и во время кризиса (поэтому год назад 1000 открытых вакансий – это хорошо, а сейчас – плохо). Год назад мы случайно создали более точный индикатор активности IT-найма. Ежедневно AI-агенты сканируют напрямую тысячи источников: сайты компаний, ATS-системы и job-сайты. Миллионы накопленных записей о датах открытия и закрытия вакансий по каждой IT-роли в каждой из тысяч компаний позволяют видеть тренд роста или падения найма по конкретным IT-ролям. Благодаря ему мы вместе с вами можем следить за изменениями в IT-найме и вовремя узнать об улучшении. Лилия Урмазова Почему классический показатель "число открытых вакансий" может расти даже во время сокращений. Найм по каким IT-ролям продолжает падать в июне 2026:

Почему поздно учить автоматизацию Идея этого поста пришла мне в голову, когда неделю назад мы с менторами, SDET крупных международных компаний, на регулярной встрече обсуждали перспективы рынка автоматизаторов и пришли к довольно интересным выводам. Ещё несколько лет назад путь из manual QA в автоматизацию был очевидным апгрейдом: более сложные задачи, соотношение вакансий 70/30 в пользу автоматизаторов, выше зарплата. Порог входа был понятным - базовый Python/Java/JS, CSS/XPath, DOM, Git, Selenium. Сегодня позиция автоматизатора всё чаще подразумевает специалиста, который ставит задачи AI и контролирует чистоту, поддерживаемость и производительность сгенерированного кода. Часть SDET, с которыми я общаюсь, код уже не пишут вообще. Я ещё пишу - но уже как ML Evaluation Engineer. Вопрос, который мы разобрали на встрече: что будет, когда Claude Code и его аналоги дорастут до уровня крепкого fullstack-разработчика? Очевидный ответ - "чистые" программисты и тем более автоматизаторы рынку станут не нужны. Но есть нюанс, связанный с обучающими выборками AI-моделей: примеров работающего кода в них много, а вот примеров качественной архитектуры - на порядок меньше. Именно здесь, по нашему мнению, и сместится фокус ценности QA-инженера в ближайшие пару лет. В полной версии поста - конкретный план из трёх шагов, который мы с коллегами составили для тех, кто хочет остаться востребованным: читать далее

Как тестировать AI-приложения: Рубрики Когда вы используете одну LLM для оценки других, прилагательные в промптах работают против вас. Слова вроде «хорошо», «плохо», «вежливо» - это размытые ярлыки, которые судья интерпретирует через призму своих обучающих данных, а не вашей бизнес-логики. РАЗБИРАЮ НА КОНКРЕТНОМ КЕЙСЕ: Клиент требует возврат за кроссовки не того цвета. Бот вежливо отказывает и предлагает скидку 10%, хотя политика компании предписывает 100% возврат. Если судья обучен «ценить вежливость», такой ответ получит высокий балл - несмотря на то, что бизнес теряет лояльность клиента и нарушает собственные правила. ЧТО РАБОТАЕТ ВМЕСТО ЭТОГО: • Четкая рубрика по шкале 1-5, где каждый балл привязан к конкретному поведению (например, «3 = признает ошибку, но предлагает скидку вместо возврата») • Chain-of-Thought до вердикта: сначала идентифицировать жалобу, найти раздел политики, сравнить ответ бота с требованиями - и только потом ставить оценку • Нормализация численных метрик в диапазон 0.0-1.0 для последующего комбинирования Почему CoT критичен и как именно борьба с предвзятостью поспешных выводов меняет точность судьи: читать далее

Как тестировать AI-приложения: Модель-судья и золотой стандарт Если вы используете одну LLM для оценки других, всегда лучше иметь под рукой «золотой стандарт» для сравнения. В противном случае ваш «судья» полагается только на собственную память и может галлюцинировать гораздо чаще, особенно в узкопрофессиональной нише. ПРИМЕР ПРОБЛЕМЫ Клиент просит возврат денег, потому что кроссовки пришли не того цвета. Бот отвечает: «Мне очень жаль! Обычно мы не возвращаем деньги, но вот вам скидка 10%». Реальность же такова: политика компании требует полного возврата средств в случае ошибки при комплектации. Без привязки к фактам компании LLM-судья пропустит эту ошибку, опираясь на «общие знания» из обучающих данных, которые противоречат вашим внутренним правилам. ВТОРАЯ ЛОВУШКА: ПОЗИЦИОННОЕ СМЕЩЕНИЕ LLM-судьи склонны отдавать предпочтение первому варианту в списке просто потому, что он идет первым. Это искажает любые A/B-сравнения моделей и делает результаты оценки нерепрезентативными. В полном посте я разобрала технику «Swap and Shuffle» для борьбы с position bias, а также рассказала, кому стоит доверить создание «золотого стандарта» и почему промпты судьи нужно версионировать как код: читать далее

Как тестировать AI-приложения: Модель-судья и золотой стандарт Если вы используете одну LLM для оценки других, всегда лучше иметь под рукой «золотой стандарт» для сравнения. В противном случае ваш «судья» полагается только на собственную память и может галлюцинировать гораздо чаще, особенно в узкопрофессиональной нише. ПРИМЕР ПРОБЛЕМЫ Клиент просит возврат денег, потому что кроссовки пришли не того цвета. Бот отвечает: «Мне очень жаль! Обычно мы не возвращаем деньги, но вот вам скидка 10%». Реальность же такова: политика компании требует полного возврата средств в случае ошибки при комплектации. Без привязки к фактам компании LLM-судья пропустит эту ошибку, опираясь на «общие знания» из обучающих данных, которые противоречат вашим внутренним правилам. ВТОРАЯ ЛОВУШКА: ПОЗИЦИОННОЕ СМЕЩЕНИЕ LLM-судьи склонны отдавать предпочтение первому варианту в списке просто потому, что он идет первым. Это искажает любые A/B-сравнения моделей и делает результаты оценки нерепрезентативными. В полном посте я разобрала технику «Swap and Shuffle» для борьбы с position bias, а также рассказала, кому стоит доверить создание «золотого стандарта» и почему промпты судьи нужно версионировать как код: читать далее

Как тестировать AI-приложения: Determinism vs. Probability Традиционный QA, даже вооруженный до зубов AI-инструментами, принципиально не отличается от тестирования без них. Вы планируете покрытие, опираясь на классический тест-дизайн: эквивалентное разделение, попарное тестирование и т.п. Вы работаете с установкой, что если ожидаемый результат A + B = C, а на деле A + B != C - это дефект. В этом детерминированном мире почти никогда нет смысла прогонять один и тот же тест дважды. Однако, если вы AI QA или ML Evaluation инженер, ваше A + B в первом прогоне может быть C, во втором - C + k, а в третьем C - k или даже C + n. Вы живете в мире подброшенных кубиков. По сути, вы измеряете вероятность результата. А чтобы рассчитать эту вероятность, у вас должно быть статистически репрезентативное количество наблюдений. Почему так происходит? Потому что, если честно, даже разработчики LLM не знают до мельчайших деталей, как они работают. Да, они понимают архитектуру (например, Transformer) и базовые принципы, но не могут гарантировать, что для одного и того же ввода сигнал всегда пройдет один и тот же путь. В полной версии поста я разобрала, как именно адаптировать процесс под эту недетерминированность - от работы с доверительными интервалами и N-прогонами до конкретного примера стресс-теста промптов на задаче «нарисуй дом» и подхода, который мы применяем у себя на проекте для минимизации галлюцинаций: читать далее

Тестовое задание для тестировщика AI-приложений Ранее меня просили рассказать про subj. Итак, домашнее задание по оценке навыков ML Evaluation Engineer: как оно выглядит и чего ожидают работодатели? Гипотетический сценарий: приложение медицинских консультаций тонет в пользовательских жалобах, при этом sentiment-модель внутри рапортует о высокой Global Accuracy. Дано: 1000 отзывов в JSON с ground truth, предсказаниями и confidence scores. Задача - найти «слепые зоны», которые скрывают агрегированные метрики. Ключевая ошибка большинства кандидатов - воспринимать это как задачу по кодингу. На самом деле, проверяется способность отвечать на вопрос «Ну и что?». Просто посчитать precision/recall недостаточно, нужен структурированный аудит с визуальными доказательствами (calibration curves, confusion matrices) и текстовым объяснением, где именно модель проваливается и почему старые метрики этого не видят. Разбор по фазам: • ФАЗА 1 «Детектив»: проверка дисбаланса классов (если позитива в 10 раз больше - Accuracy врет), поиск bias на срезах (медицинский жаргон vs разговорный). • ФАЗА 2 «Архитектор»: модульный Python-код, решение где применять статистику, а где LLM-as-a-Judge для разбора сарказма и медконтекста, отдельная проверка на «Confidently Incorrect» предсказания - самые высокорисковые ошибки. • ФАЗА 3 «Стратег»: визуализация + бриф по слепым зонам. В оригинальной заметке также разобрано, какой именно «гибридный» профиль навыков ждут работодатели и почему ваш GitHub-README важнее самих .py файлов: читать далее

LLM-as-a-Judge (модель-судья) и QA-терминология Если вы задумываетесь о переходе из QA в ML-инженеры, стоит начать с изучения основных концепций больших языковых моделей (LLM) и способов оценки их результатов. Одна из ключевых идей здесь - оценка работы «младшей» модели с помощью «старшей» (вместо или вместе с проверкой человеком). Эту «старшую» модель называют LLM-as-a-Judge. Проще говоря, вы используете более мощную LLM в качестве автоматизированного асессора. Традиционные ассерты из автотестов здесь не работают по двум причинам: • Выходные данные недетерминированы, поэтому каждый тест априори будет «мигающим» (flaky). • Крайне сложно прописать четкие критерии pass/fail, если мы имеем дело, например, с текстовой схожестью (text similarity). КАК ЭТО ВЫГЛЯДИТ НА ПРАКТИКЕ Сначала определяется рубрика - строгие критерии оценки («Является ли ответ фактологически верным? Есть ли галлюцинации?»). Это ваша спецификация теста. Далее пишется промпт для «модели-судьи», включающий рубрику, ответ целевой модели и исходный промпт. Судья прогоняет датасет несколько раз (из-за недетерминированности) и возвращает структурированный JSON с оценкой и обоснованием. В полной версии поста я разобрала, как концепции LLM-as-a-Judge напрямую проецируются на привычную QA-терминологию - от Test Oracle до Acceptance Criteria: читать далее

Один день тестировщика AI-приложений Один мой день (разумеется, без нарушения NDA!). 09:30 – 10:30 Смена архитектуры Начала день с синка по нашему агентскому воркфлоу (agentic workflow). Команда разработки представила нового агента. Задача: мне нужно убедиться, что появление нового агента не повлияло на качество системы. Предстоит сравнить старую версию системы с новой. 11:00 – 12:00 Споры о метриках Встретились с ML-командой, чтобы решить, как мы будем оценивать этого красавца. Мы уже выходим за рамки простой точности (accuracy). Итог: остановились на Faithfulness (отсутствие галлюцинаций) и Efficiency (не делает ли агент 10 шагов там, где достаточно двух?). 12:00 – 14:00 Python Пора приступать. Добавляю метрики в пайплайн с помощью Python-библиотек или подхода LLM-as-a-judge — посмотрим, что сработает лучше. Здесь я работаю напрямую с кодом проекта, а не с AQA-кодом. И должна признать: это на порядок сложнее того, к чему я привыкла. AQA-код обычно базируется на отдельных фреймворках типа Selenium, его проще понять и написать. Так что изначально для меня это был серьезный вызов. 14:00 – Обед! 🙂 Продолжение моего рабочего дня: читать далее