Тестирование IT-систем *

На рынке сейчас царит жуткая путаница между совершенно разными 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. Тестирование производительности здесь не «доп. опция», а база.

КОРОТКО
Традиционный QA = Поиск дефектов.
ML Evaluation = Измерение неопределенности.

Представляете, группа международных исследователей разработала e-Taste — систему, которая передает реальный вкус еды в виртуальной среде.

Как это работает на примере мороженого

Чтобы человек мог насладиться мороженым в VR, ученые сначала оцифровали его вкус. Нанесли растопленное лакомство на специальную пластинку с датчиками, и она выделила в растворе 5 основных вкусов (сладкий, кислый, солёный, горький, умами — вкус мяса или сыра), измерила силу каждого и перевела в цифровые данные, которые можно хранить, копировать и передавать.

Обратное превращение цифровых данных во вкус происходит через устройство-получатель, которое крепится на язык. Оно состоит из электромагнитного насоса и трубочек с 5 гелями разных вкусов.

Для получения нужного вкуса все 5 гелей смешиваются в нужных пропорциях, полученная жидкость попадает на язык и передает вкус мороженого. Интенсивность можно регулировать, меняя соотношение разных гелей в получаемой жидкости.

Почему разработка интересна тестировщикам

На первый взгляд, тестировать e-Taste просто: пробуешь реальное блюдо и сравниваешь с тем, что передает устройство.

Но это ошибочный подход.

Еды бесконечно много, ощущения субъективны, а если вкус не совпадает — непонятно, где именно возник сбой: на этапе анализа продукта, при передаче данных или в восприятии человека.

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

Ключевой тест здесь — стабильность получаемого результата. Когда один и тот же продукт анализируется 5, 10, 100 или 1 000 раз, результаты должны быть одинаковыми. Если они «плавают», это дефект, даже если человеку кажется, что вкус «примерно такой же».

Важно исследовать безопасность системы, ведь цена ошибки не просто плохой пользовательский опыт, а риск навредить здоровью людей. Необходимо проверить: возможна ли передозировка съедобными компонентами, что произойдет при сбое передачи данных или потере сигнала; неопасно ли длительное использование и еще множество сценариев.

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

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

Представлен открытый проект Hacking-Tools с набором инструментов, которыми пользуются кибербезопасники и системные администраторы, включая:

• Поиск информации: показывает, какие данные о вас и компаниях уже лежат в интернете; 

• Проверки на уязвимости: находит дыры в сайтах, приложениях и серверах;

• Инструменты взлома (для тестов): имитируют атаки, чтобы понять, где всё сломается;

• Анализ Wi‑Fi и сетей: проверяют, можно ли перехватить трафик или подключиться без спроса; 

• Цифровая криминалистика: вытаскивают удалённые файлы, метаданные и следы активности; 

• Стресс‑тесты: нагружают сайты и сервисы, чтобы проверить нагрузку; 

• Перехват и анализ трафика: показывают, какие данные гуляют по сети; 

• Подбор паролей: тестируют, насколько легко взломать слабые комбинации;

• Анализ сайтов: ищут скрытые страницы, баги и уязвимый код; 

• Реверс‑инжиниринг: разбирают программы «по косточкам», чтобы понять, как они работают; 

• Социальная инженерия: симуляторы фишинга и проверка сотрудников на внимательность.

Приглашаем на бесплатный вебинар “Обзор AI-ассистентов для кодинга в 2026”

Когда: 12 февраля 2026 года, 14:30 (Мск)
Формат: онлайн · 45 минут
Спикер: Михаил Костицын, ведущий разработчик Veai, преподаватель СПбГУ и руководитель Летней школы Veai для студентов ИТМО и СПбГУ
Бесплатная регистрация: по ссылке

AI-ассистенты для программирования за последние годы прошли путь от простого автодополнения до полноценных агентов, способных анализировать проект, принимать решения и выполнять сложные задачи. На этом вебинаре мы разберём, какими на самом деле являются AI-ассистенты в 2026 году и как получать от них пользу в корпоративной разработке.

Рассмотрим эволюцию AI-инструментов для написания кода: от inline-генерации и чатов до агентных систем. Обсудим основные классы решений (LLM, AutoML, agent-based подходы), их сильные стороны и ограничения при работе с большими кодовыми базами. Отдельное внимание уделим сравнению консольных агентов, IDE-плагинов и IDE со встроенными AI-возможностями, а также как правильно собирать контекст и писать промпты, работать с MCP-серверами и решать проблему засорения контекста.

Обсудим ключевые для компаний вопросы: безопасность кода и данных, on-premise развёртывание, риск уязвимостей в сгенерированном коде и контроль действий AI-ассистентов.

В завершение разберём, как выбирать модели и инструменты под конкретные задачи с учётом производительности, стоимости и доступности решений.

Посетители вебинара:

• научатся оценивать реальные возможности и ограничения AI-ассистентов в промышленной разработке

• будут осознанно выбирать AI-ассистенты под конкретные задачи и команды

• смогут оценивать риски безопасности и требования корпоративной среды

• узнают, как говорить об AI с менеджментом, маркетингом и другими командами на одном языке.

Вебинар носит прикладной характер и опирается на реальный опыт внедрения AI в промышленную разработку. Михаил Костицын, ведущий разработчик Veai, преподаватель СПбГУ и руководитель Летней школы Veai для студентов ИТМО и СПбГУ, поделится своим опытом пилотирования проектов и ответит на вопросы участников.

Участие в вебинаре бесплатное, необходима регистрация.

Veai — команда профессиональных исследователей и разработчиков с практическим опытом в анализе кода, генерации тестов и поиске уязвимостей. Плагин Veai c собственным AI агентом понимает структуру проекта и подстраивается под его стиль. Ускоряет разработку без потери качества.

В процессе тестирования верстки быстро становится понятно: один и тот же интерфейс может выглядеть аккуратно на макете, но разваливаться на практике. Чаще всего это проявляется в длине текста, переносах строк, состояниях элементов и отступах.

Рассказываем, на что обращаем внимание при проверке верстки и какие моменты проверяем в первую очередь.

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, но путается в вопросах стабильности;

• заявляет ответственность за качество, но не может описать процессы и зоны ответственности.

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

Как сейчас смотрят на опыт

На интервью все меньше внимания уделяется формальным строчкам в резюме и все больше мышлению.

Интервьюеру важно понять:

1. Почему было принято именно такое решение;

2. Какие были трудности;

3. Как проблемы диагностировали;

4. Какие выводы сделали.

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

Поэтому сейчас важна не красивая история, а осознанное понимание своего опыта.

Что с этим делать

Минимальный практический набор:

1. Разложить свой опыт по зонам - архитектура, API, UI, CI/CD, процессы, инциденты.

2. Подготовить ответы в формате «проблема - решение - результат - выводы». (Для шарящих - по STAR)

3. Прогнать опыт через уточняющие вопросы и проверить, где ответы выглядят слабо или непоследовательно.

4. Упаковать резюме как набор конкретных ответов - что улучшал, что оптимизировал, за что отвечал + быть готовым это подтвердить.

Вывод

Рынок действительно стал сложнее.
Но именно поэтому он стал более комфортным для тех, кто держит фокус на релевантности, понимает свой опыт и готовится к проверке.

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

Ну а всем нуждающимся желаю скорее обрести себя на сегодняшнем рынке! Готов подискутировать на смежные темы в комментариях)

При написании интеграционных тестов для Spring Boot приложения часто возникает проблема, что разработчики бездумно добавляют аннотации @MockBean, @SpyBean, @DirtiesContext или переопределяют прямо в тестовом классе различные property. Всё это приводит к изменению Spring Context, невозможности использовать закэшированный контекст и следовательно созданию нового. Часто создание нового контекста это длительная операция.

Существуют инструменты по отслеживанию этих процессов. Самым простым способом увидеть количество контекстов и количество попаданий в кэш является добавление логирования либо через свойство logging.level.org.springframework.test.context.cache=DEBUG либо настройкой вашего логгера.

Один известный автор статей про тестирование на Java / Spring Boot, Philip Riecks (со товарищи), создал инструмент с открытым исходным кодом Spring Test Profiler при помощи которого можно получить html отчёт о поднимаемых контекстах во время тестов, о количестве и типе бинов в этих контекстах. На Хабре есть перевод его статьи в сообществе Spring АйО.

У нас на проекте стал вопрос, как нам показать разработчикам, что их тест порождает новый Спринг Контекст. Мы решили считать контексты в тестах и при превышении ожидаемого количества падать. Это "руинит" сборку и CI/CD пайплайн.
Для этого мы добавили реализацию интерфейса ContextCustomizer

class LimitingSpringContextCustomizer implements ContextCustomizer {

    private static final AtomicInteger CONTEXT_COUNTER = new AtomicInteger();
    private static final int EXPECTED_SPRING_TEST_CONTEXT_COUNT = 16;

    @Override
    public void customizeContext(ConfigurableApplicationContext context, MergedContextConfiguration mergedConfig) {
        int numberOfContexts = CONTEXT_COUNTER.incrementAndGet();
        log.info("Number of Spring Test Contexts: {}/{}", numberOfContexts, EXPECTED_SPRING_TEST_CONTEXT_COUNT);
        Assert.state(numberOfContexts <= EXPECTED_SPRING_TEST_CONTEXT_COUNT,
                () -> "Number of test contexts exceeds configured maximum: " + EXPECTED_SPRING_TEST_CONTEXT_COUNT);
    }

    @Override
    public boolean equals(Object obj) {
        return (obj != null) && (getClass() == obj.getClass());
    }

    @Override
    public int hashCode() {
        return getClass().hashCode();
    }
}

Здесь, согласно документации интерфейса ContextCustomizer необходимо корректно переопределить методы equals и hashCode.

WARNING: implementations must implement correct equals and hashCode methods since customizers form part of the MergedContextConfiguration which is used as a cache key.

Далее добавляем фабрику.

class LimitingSpringContextCustomizerFactory implements ContextCustomizerFactory {

    @Override
    public ContextCustomizer createContextCustomizer(Class<?> testClass,
                                                     List<ContextConfigurationAttributes> configAttributes) {
        return new LimitingSpringContextCustomizer();
    }
}

Затем регистрируем эту фабрику при помощи spring.factories чтобы она применялась ко всем тестам.
Для этого создаём в тестовых ресурсах файл по пути src/test/resources/META-INF/spring.factories со следующим содержимым

org.springframework.test.context.ContextCustomizerFactory=\  
com.mycompany.app.support.spring.LimitingSpringContextCustomizerFactory

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

Возможно, это пример поможет кому-нибудь повысить скорость прохождения своих тестов путём отслеживания количества запускаемых тестовых Спринг контекстов.

Не надо делать по красоте. Надо делать MVP.

Никто так говорить, кроме менеджеров, не любит. А я вдруг внезапно полюбил такой подход в работе. Стал бить себя по рукам и делать дешево.

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

MVP-подход тут мне стал очень помогать на моем, локальном уровне. Суть очень простая: делаю минимум и быстро. А потом добавляю на кости мяса. Надо сделать сохранение строк файла в БД? Пока сделаю построчно и поставлю # TODO. Потом сделаю батчем. Нужна отправка сотен объектов из БД в API? Пока тоже построчно. Нужна еще одна очередь Redis для этапа в обработке файла — потом. Пока и с одной очередью и воркером справимся.

MVP-подход требует некоей выдержки, особенно на пет-проектах. Код пишешь ты сам с собой. Выступаешь внутренним критиком и, зачастую, самым строгим. Но делать все дешево и сердито стало помогать мне лично держать фокус на цели: дать максимум ценности за минимум усилий. И при этом не сгореть от объема, быть в тонусе.

Риски, конечно тоже есть. У TODO нет хозяев, кроме нас. Дешевое Г становится иногда продом. Техдолг это вообще бесконечная тема и, пожалуй, не для этого поста. Пост про эффективность.

MVP-промтинг работает и с нейронками таким же образом. Берем чистый контекст, делаем простой прототип. А дальше по кускам его обтесываем, заменяем, улучшаем. Может, у нас есть с ними что-то общее?

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

Рынку плохо? Работу найти нереально? — Это твой шанс 🚀

Последнее время всё чаще вижу одну и ту же ситуацию.

Человек активно ищет работу: отклики, собеседования, тестовые, разговоры с HR.
А на выходе — либо отказы без внятного объяснения, либо формулировки вроде
«вы хороший специалист, но нам нужен чуть другой профиль» 🤷‍♂️

И почти всегда звучит один и тот же вывод:
«рынок умер, конкуренция бешеная, сейчас вообще нереально найти работу».

Отчасти это правда — рынок действительно стал жёстче.
Но вот что интересно: именно в таких условиях многим стало проще выделяться 💡
Не потому что кандидатов стало меньше, а потому что вырос разрыв между теми, кто выглядит релевантно, и теми, кто — нет.

Я регулярно общаюсь с QA / AQA / SDET, которые сейчас находятся в активном поиске, и сам продолжаю проходить собеседования, чтобы держать руку на пульсе.
И главный вывод из этого опыта простой: сегодня выигрывает не самый громкий кандидат, а тот, кто чётко понимает свой опыт и умеет его объяснять.

Ниже — что именно изменилось и как этим пользоваться 👇

Что изменилось

Ещё 1–2 года назад часто работала простая схема:
уверенное резюме + нормальная подача = высокая вероятность оффера 😌

Многие компании:

• не сильно углублялись в детали;

• смотрели на опыт в общих чертах;

• закрывали глаза на неточности, если кандидат выглядел уверенно.

Сейчас ситуация другая:

• вакансий в ряде направлений стало меньше 📉;

• требования заметно выросли;

• собеседования стали глубже и детальнее 🔍;

• интервьюеры чаще проверяют логику решений и реальный вклад кандидата.

Это не “заговор рынка”, а обычная фильтрация: когда выбор большой — требования растут.

Почему в этом есть плюс

Жёсткий рынок хорош тем, что он быстро отсеивает слабые места ⚠️
Причём чаще всего — самые базовые.

Типичные проблемы, на которых кандидаты “сыпятся”:

• говорят, что строили фреймворк, но не могут связно объяснить архитектуру;

• упоминают автотесты, но не понимают, зачем выбран конкретный стек;

• рассказывают про CI, но путаются в вопросах стабильности и flaky-тестов 🤯;

• заявляют про ответственность за качество, но не могут описать процессы.

Большинство падает не на сложных вопросах, а на уточняющих.
На этом фоне человек, который осознанно разбирается в своём опыте, сразу смотрится сильнее 💪
Даже без “топовых” компаний в резюме.

Как сейчас смотрят на опыт 🎭

На интервью всё меньше внимания формальным строчкам и всё больше — мышлению 🧠

Интервьюеру важно понять:

• почему было принято именно такое решение;

• какие были ограничения;

• что пошло не так;

• как проблему диагностировали;

• какие выводы сделали.

Если опыт не структурирован — ответы быстро разваливаются.
Если опыт разобран и понятен самому кандидату — он спокойно проходит даже при неидеальном бэкграунде.

Поэтому сейчас важна не “красивая история”, а осознанное понимание того, что ты делал.

🎯 Ключевой навык сегодня — релевантность

Недостаточно просто быть QA или AQA.

Важно быть релевантным:

• конкретной роли;

• стеку компании;

• типу продукта;

• уровню ответственности.

Это проявляется в деталях:

• какие кейсы вы выбираете;

• как формулируете достижения;

• как отвечаете на вопросы «почему?» и «а что если иначе?».

Иногда достаточно слегка пересмотреть подходы или формулировки — и это сильно влияет на конверсию.

Что с этим делать 🛠

Практический минимум:
1️⃣ Разложить опыт по зонам: архитектура, API, UI, CI/CD, процессы, инциденты.
2️⃣ Готовить ответы в формате: проблема → решение → результат → выводы.
3️⃣ Прогнать опыт через уточняющие вопросы — здесь хорошо помогают LLM.
4️⃣ Упаковать резюме как набор сигналов 🚦 и быть готовым их подтвердить.

Вывод 🧠

Рынок стал сложнее — это факт.
Но именно поэтому он стал выгоднее для тех, кто:

• держит фокус на релевантности;

• понимает свой опыт;

• готовится к проверке;

• не теряется на уточнениях.

Если относиться к поиску работы как к инженерной задаче, “жёсткий рынок” превращается в возможность 🚀

👉 Если интересно — глубже разбираю эту и другие интересные темы в своем Telegram-канале, ну а также делюсь там инсайдами по рынку, собеседованиям и росту в AQA / SDET.

Не пользуюсь LLM-агентами, если могу. Давно замечаю: просто избегаю запускать LLM прямо в проекте, потому что боюсь разучиться кодить и думать. Поход в ChatGPT себе разрешаю — это как встать с дивана, чтобы пойти в магазин, а не заказывать доставку на дом. Там нужно правильно сформулировать запрос, потому что он не может добрать контекст проекта сам. Можно перекинуться парой мыслей, как с товарищем на работе. Надо подумать, как применить ответ, что выкинуть. В итоге я всё равно как-то худо-бедно программирую сам.

Пока я отрицаю прогресс, из мира агентов доносится много шума про управление контекстом и токенами. Агенты в ответ на запросы жрут лимиты по токенам, выделенные на отрезок времени. Ну либо запросы по API просто тарифицируются. Причем чем дольше общаешься с нейросетью, тем больше контекста ей нужно держать, учитывать, корректировать, сжимать. Помимо этого, нейронка ещё подглядывает правила проекта в .md-файлах, что-то помнит между переписками.

Чем больше у нейронки пузырь вашего контекста, тем хуже она работает. Путается в постоянно пополняющихся правилах, корректировках и ограничениях. Наконец, контекстный оверхед — это еще очень дорого. Каждый запрос к API содержит тысячи «мусорных» токенов и выжирать лимиты получается еще быстрее.

В ответ на это индустрия на венчурные деньги придумывает и продвигает свои «велосипеды», чтобы с помощью агентов эффективнее и дешевле решать задачи:

• В Cursor IDE есть Rules, которые накладывают ограничения поверх ваших промптов. Их можно применять вручную или автоматически; говорят, автомат работает хуже.

• Anthropic пиарит Skills (еще пример Playwright Skill). Это интерфейс для решения типовых задач с адаптивными ступенями контекста в зависимости от сложности.

• Есть MCP (Model Context Protocol) — условное API, которое расширяет возможности агентов, чтобы они не писали собственные инструменты и не тратили контекст и токены на типовые задачи: открыть браузер, прочитать Jira, отправить письмо и т. д.

• Также есть субагенты; их оркестрирует агент-оркестратор. У субагентов чистый контекст: они получают задачу, выполняют её и идут на «свалку».

И вот среди этого новояза я – старпер со своим ChatGPT: после 2–3 запросов удаляю чат и начинаю новый. Вот моя экономика токенов и галлюцинаций. Меня и Альтмана маркетингом не проведешь!

Отраслевое исследование QA: автоматизация, AI и метрики — сбор данных

Команда Test IT (бренд «Девелоника» FabricaONE.AI (акционер – ГК Softline)) запустила опрос для сбора данных перед публикацией отраслевого исследование по состоянию QA в российских компаниях.

Наша задача опросить реальных тестировщиков и понять, что меняет их работу прямо сейчас, какие особенности в проектах нужно учитывать в 2025-2026 году и как меняется тестирование с учетом новых инструментов и развития отечественных решений TMS.

Ссылка на анкету исследования

Если вы представитель QA-сообщества и готовы поделиться реальной практикой (включая проблемы и ограничения), то будем ждать ваших ответов! Участие в опросе займет немного времени, итоговые данные будут направлены всем участникам-респондентам.

Присоединяйтесь, давайте вместе составим объективную картину по рынку в нашем сегменте! Всем недели без багов и без пятничных релизов)!

Разработчик Эван Хан спустя 13 лет практики установил все 376 параметров Vim. Его конфигурационный файл состоит из почти из 2900 строк.

Про воркеры простыми словами

На работе мне понадобилось реализовать воркер. Описываю, как сам эту тему разобрал.

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

Пример
Сборщик мусора в БД: пройтись раз в час, например, и удалить старые записи. Или, как у меня задача на работе: обработать xlsx-файл, который передали в ручку.

Зачем
Чтобы сделать работу приложения асинхронной. Представим задачу, которую можно обработать дольше, чем за 10 секунд. Клиент на вашем сайте не будет сидеть и смотреть в экран эти 10 секунд. Он перезагрузит страницу, сессия прервётся, и задача не выполнится. Или веб-сервер вернёт клиенту таймаут. В описанном сценарии обработка запроса — синхронная процедура. Она плохо подходит для быстрых веб-сервисов. А вот асинхронная обработка: кинули запрос, получили ответ 200 OK и пошли чилить, пока задача исполняется — это то, что нужно. Воркер как раз для этого.

Коллбэк
Коллбэком воркера может быть любая нужная функция: отправить имейл, прочитать содержимое, залить файл во временное хранилище и т. д.

Триггеры
Триггерами для воркера могут быть:

• крон

• таймер

• событие

Очереди
Воркеры по событию обычно подписаны на очередь. В моём случае это как раз Redis Queue (библиотека rq, например https://python-rq.org/ ). Запрос в ручку получает 200 OK. Мой сервис создаёт запись в БД типа «задача id такой-то, статус processing» и публикует событие в очереди. Воркер забирает событие, чтобы другие воркеры не могли задачу задублировать, и пробует выполнить свой коллбэк. Если всё ок, воркер пишет в БД данные по выполненной задаче и подтверждает в очереди прочтение события. Иначе воркер может ретраить, может завалить задачу и вернуть её в очередь, а может и сам упасть.

Воркер-пул
Воркеров может быть несколько. Они могут выполнять как несколько разных задач, так и одну вместе. Увеличение числа воркеров требует оркестрации и иногда для этого также выделяет контейнер с оркестратором. Воркеры могут передавать задачи друг другу. Могут конкурировать за задачи, если очередь организовать неправильно. А могут вообще читать разные потоки и быть никак не связаны друг с другом.

Накладные расходы
Чем сложнее слой с воркером, тем больше необходимость следить за их хелсчеками. В отличие от вашего сервиса, воркер может тихо упасть. Ваш сервис отдаёт 200, а по факту задачи не отрабатывают. Так что воркеры накладывают дополнительные накладные расходы: связанность, обработка ошибок, логирование, алерты, ретраи, рестарты подов и т. д.

Образ
Воркер собирается из того же образа, что и ваше приложение, но у него отдельный энтри-поинт. Вместо запуска через main.py у, например, worker.py, есть строчка вида:

def main():

    ... # Какая-то логика по инициализации воркера и очереди

if name == '__main__': 

    main() # Если запускают этот модуль напрямую, выполни команду main()

Из-за этого кода модуль можно вызвать напрямую python -m app.worker. В main(), как правило, скрыта логика какого-то while-true цикла и шатдауна на случай завершения работы воркера.

"У меня друг/брат/сват/муж/жена/собака хочет в тестирование! где почитать?!"

Несколько лет назад мы с коллегами заметили закономерность: раз в неделю кто-то спрашивает "с чего начать изучение тестирования?". Вопрос один и тот же. Ответы одни и те же. Ссылки одни и те же.

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

Никакой монетизации. Никаких платных курсов в конце воронки. Просто практикующие специалисты, которым захотелось поделиться опытом. Записывали ролики по вечерам, монтировали по выходным, выкладывали когда получалось.

Честно скажу: последний год всё как-то притихло. Базовые темы разобрали, а снимать очередной ролик про создание коллекций в Postman уже не видим смысла. Инструменты меняются быстрее, чем мы успеваем про них рассказывать.

Но материал никуда не делся. Если кому-то нужен некоммерческий контент от практиков, а не от инфобизнеса, приходите, смотрите. Надеюсь, будет полезно.

Если есть тема, которую мы не осветили, и она вам реально нужна - пишите. Только учитывайте: запись и монтаж видео съедают много времени и сил. Мы стали бережнее относиться к своему ресурсу и откликаемся не на всё. Но если тема важная и интересная - почему бы и нет.

В общем, если вас спросят "где посмотреть что-то про тестирование для начинающих" - можете кинуть ссылку: TostersSchool

Канал легко гуглится и ищется в Telegram.

Если ты — Automation QA и хочешь перейти в мир обеспечения качества AI-приложений*, как это сделала я, то мой путь может послужить небольшой дорожной картой.

*не путать с использованием AI-инструментов для тестирования классических приложений

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

Вот как я восполняла пробелы в знаниях:

Временные затраты
Около 7 месяцев изучения теории и параллельно более года практического опыта. Этот год я провела, участвуя в стартап-проектах (в основном в роли QA Lead), что дало мне «безопасную песочницу» для применения знаний в области ML на реальных практических задачах.

Переход на Python
Java — отличный язык, но в экосистеме ML/AI «лингва франка» — это Python. Библиотеки для работы с моделями, статистикой, метриками и трансформерами здесь есть на любой вкус и цвет. Так что, если ты Java QA, стоит сменить Java на Python.

Создание теоретической базы
Нельзя оценивать то, чего не понимаешь. Мне пришлось изучать, как модели строятся с нуля, чтобы понять, как их измерять.

Этот бесплатный англоязычный курс был действительно отличным, интересным и захватывающим — спасибо, Dr. Raj Abhijit Dandekar!

Мое прошлое обучение в аспирантуре по прикладной лингвистике здесь немного помогло, но кое-где математика и архитектура стали новым вызовом.

Кроме того, я изучила множество других материалов (например) и, конечно, много общалась с «железным другом» Gemini. :)

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

оригинальные посты выходят в Linkedin (англ.)

Услышал про Apidog. Кажется, Postman больше не единственный вариант

Давно понял, что в работе в ИТ очень важно быть открытым к новым знаниям. Технологии меняются быстро, и то, что было стандартом вчера, завтра может оказаться устаревшим подходом.

До недавних пор был уверен, что Postman это непоколебимый промышленный стандарт для работы с API. Все его знают, все используют, коллекции передаются из проекта в проект. Зачем искать что-то ещё?

Вчера разговорился с коллегой из команды, и он упомянул Apidog. Говорит, перешёл полгода назад и не жалеет. Сегодня решил посмотреть сам. Вот первые впечатления.

Что это такое

Apidog позиционируется как all-in-one платформа: дизайн API, документация, mock-сервер, тестирование и дебаг в одном месте. По сути, Postman + Swagger + Mock + автотесты без переключения между инструментами.

Что зацепило

Визуальный редактор для создания спецификаций. Рисуешь схему, она автоматически превращается в OpenAPI. Не нужно писать YAML руками.

Mock из коробки. Создал спецификацию, mock-сервер уже работает. Фронтенд может начинать разработку не дожидаясь бэкенда. Причём mock умный: генерирует данные по типам полей.

Автотесты с визуальными assertions. Можно добавлять проверки без кода, просто кликая. Есть data-driven тестирование, интеграция с CI/CD.

Командная работа в реальном времени. Версионирование API, ветки как в Git, ролевой доступ.

Импорт коллекций из Postman. Миграция не с нуля.

Что смущает

Китайские корни. Для кого-то это плюс (активная разработка, быстрые релизы), для кого-то минус (вопросы безопасности данных).

Ещё один инструмент в зоопарк. Bruno, Insomnia, Hoppscotch, теперь Apidog. Выбор это хорошо, но и головная боль при стандартизации в команде.

Бесплатный тариф щедрый, но всё равно есть ограничения для больших команд.

Пока не тестировал глубоко

Это именно первые впечатления после пары часов изучения. Не готов сказать «бросайте Postman», но точно буду пробовать на реальных задачах.

Интересно послушать тех, кто уже работает с Apidog на постоянной основе. Какие подводные камни? Стоит ли переходить с Postman или это из серии «работает — не трогай»?

Ссылки по теме на Хабре

Коллеги уже делали разборы инструментов для работы с API:

📄 Отказаться от Postman, перейти на Bruno и жить счастливо — в комментариях есть отзыв про Apidog от человека, который перешёл

📄 Лучшие open-source инструменты для тестирования API в 2025 году — обзор альтернатив

📄 Как выбрать инструмент для тестирования API — сравнение Postman, Insomnia и других

📄 API Тестирование без Postman — разбор Hoppscotch

Представлен открытый проект Mimesis: The Fake Data Generator для генерации фейковых данный для проектов, пентеста, хакинга или анонимности в сети, включая ФИО, email, адреса проживания, телефоны, локации, смена стран и адаптирование данных в соответствие с задачами. Полезно также для создания файлов JSON и XML произвольной структуры, а также анонимизации данных. Устанавливается за один клик, имеет простой и понятный интерфейс.

Эти три открытый проекта по ИБ позволяют анализировать и изучать беспроводные сети Wi‑Fi:

• Wi‑Fi‑autopwner — моделирование взлома сетей Wi‑Fi с простой защитой. Работает в консоли.

• Wi‑Fi Exploitation Framework — сервис, который поможет проверить и пробить безопасность беспроводной сети, а также протестировать на ней различные виды тестовых атак: от простых до комплексных.

• Freeway — Python‑сервис, который показывает механизм работы беспроводных сетей и их уязвимостей, помогает выявить способы перегрузки сети и смоделировать атаки с нарушением аутентификации.

Почему мы до сих пор спрашиваем про пирамиду тестирования образца 2010 года

Провожу собеседования на позиции тестировщиков уже много лет. И заметил странную вещь: вопросы по теории не меняются вообще. Те же классы эквивалентности, те же граничные значения, та же пирамида тестирования. Как будто за окном не 2026 год, а 2010.

При этом реальная работа изменилась радикально. Половина команды использует нейросетевых агентов для генерации тестов. Автоматизация пишется в паре с ассистентом. Тест-дизайн делается через промпты. А на собеседовании мы всё ещё спрашиваем "чем отличается верификация от валидации".

Я не говорю, что классика не нужна. Нужна. Но если человек не понимает, как работать с агентами в 2026 году, он будет отставать от коллег с первого дня.

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

1. Промпт-инжиниринг для тестировщика

Как правильно формулировать запросы к нейросети, чтобы получить качественные тест-кейсы, а не общие фразы. Какая структура промпта даёт лучший результат. Почему "напиши тесты для этой формы" работает хуже, чем детальное описание контекста и ожиданий.

2. Валидация результатов работы агента

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

3. Границы применимости нейросетей в тестировании

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

4. Работа с контекстом

Как правильно передавать агенту информацию о проекте. Что такое контекстные файлы и зачем они нужны. Почему один и тот же запрос в разных условиях даёт разные результаты. Как не потерять контекст в длинном диалоге.

5. Этика использования нейросетей

Можно ли отправлять агенту конфиденциальные данные проекта. Как работать с чувствительной информацией. Что происходит с данными, которые вы отправляете. Политики компаний относительно использования внешних сервисов.

6. Интеграция агентов в процесс тестирования

Как встроить работу с нейросетью в существующий рабочий процесс. На каких этапах агент полезен: планирование, написание тестов, анализ результатов, документирование. Как не превратить это в дополнительную работу вместо экономии времени.

7. Оценка качества сгенерированных тестов

По каким критериям оценивать тесты, которые написал агент. Покрытие, читаемость, поддерживаемость, соответствие стандартам команды. Как отличить хороший сгенерированный тест от плохого.

8. Работа с разными типами агентов

Чем отличаются агенты для разных задач: генерация кода, анализ требований, работа с документацией. Какой инструмент выбрать для какой задачи. Как комбинировать несколько агентов в работе.

9. Ограничения и риски

Что может пойти не так при использовании агентов. Зависимость от внешних сервисов. Проблемы воспроизводимости результатов. Риск снижения собственной квалификации при чрезмерном делегировании. Как минимизировать эти риски.

10. Критическое мышление в эпоху нейросетей

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

Это не замена классической теории тестирования. Это дополнение, которое отражает реальность 2026 года. Если кандидат знает только классику, он справится. Если знает и классику, и современные инструменты, он будет эффективнее с первого дня.

А какие темы про работу с нейросетями вы бы добавили в собеседование?