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

Когда задача считается выполненной

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

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

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

Настя, тестировщик:

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

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

Ваня, системный аналитик:

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

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

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

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

Олег, android-разработчик:

Задача выполнена, когда:

1. Функциональность реализована и проверена вручную — примерно так, как это сделал бы тестировщик, но без учета конкретных тест-кейсов.

2. Новое поведение решает цель задачи, а не просто повторяет постановку. Иногда по ходу работы находится вариант проще для разработки/поддержки или удобнее для пользователя — выбираю его. Фича должна закрывать потребность.

3. Пограничные случаи поведения (corner cases) проработаны и учтены. В постановке не всегда учитываются моменты, которые становятся заметны в коде. Например, что показать на мобильном клиенте при 500 ответе сервера или при долгой загрузке из-за задержки ответа сервера.

4. Новое поведение покрыто тестами, есть уверенность, что его не сломают случайно. Также важно, чтобы оно не сломало существующие автотесты.

5. Новое поведение поддерживаемо и расширяемо: его сможет понять и продолжить другой разработчик.

От джуна к сеньору в верификации: как расти

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

Алексей Ковалов, руководитель отдела модульной верификации YADRO, в статье рассказал, как на практике происходит рост от джуна до сеньора. И начинается все с базовых вещей. Команда Алексея использует принцип  «15–45»: 15 минут попробуй разобраться сам, но если за 45 не сдвинулся — иди к ментору. Самостоятельность важна, но умение вовремя эскалировать проблему — это уже признак зрелости.

Внутри статьи:

• почему «вечный мидл» — это не миф, а распространенный сценарий,

• как меняется тип задач при переходе между грейдами,

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

• как не утонуть в покрытии и научиться оценивать объем работы заранее.

Если откликается описанный подход к росту, сейчас хороший момент присоединиться к команде YADRO. Мы открыли Sprint Offer для RTL- и UVM-инженеров. Подать заявку можно до 22 февраля. 

Инженеры занимаются fabless-разработкой микропроцессоров на базе RISC-V — полным циклом от собственного процессорного IP до системного ПО. Работают с IP, SoC, беспроводными системами и высоконагруженными архитектурами.

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