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

Немного о автотестах (unit, e2e)

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

• Дебаг кода — запуск конкретного участка кода в изолированной среде вместо прокликивания всего приложения

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

• Работа с mock-данными — быстрая генерация нужных состояний и данных без зависимости от внешних сервисов и БД

• Безопасный рефакторинг — уверенность, что изменения внутренней структуры не ломают внешнее поведение

• Исследование legacy-кода — способ понять, что делает незнакомый код, через эксперименты с вводом и выводом

• Проверка граничных случаев — систематическая проверка null, пустых коллекций, переполнений и прочих крайних сценариев

• Изоляция компонентов — возможность запустить один модуль отдельно от всего приложения и проверить именно его логику

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

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

• Уверенность при деплое — зелёный CI даёт объективное основание катить релиз, а не полагаться на интуицию

• Фиксация требований — бизнес-правила, выраженные в тестах, становятся исполняемой спецификацией, а не абзацем в Confluence

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

• Проектирование API — написание теста до реализации заставляет продумать интерфейс с точки зрения потребителя

• Валидация архитектурных решений — если код тяжело тестировать, это сигнал о проблемах в архитектуре

Цитата из статьи Нет времени на тесты — через неделю релиз

Недавно общался с крупной зарубежной продуктовой компанией. Штат 500–1000 человек, вроде зрелые процессы, ЗП у разрабов 5000€ баг-репорты по ISO/IEC/IEEE 29119. И при этом:

«Не успеваем уделять время автотестам. Сфокусированы на скорости разработки и релизах.»

Что меня зацепило — каждый их аргумент против тестов я интерпретировал как аргумент за:

— «Слишком частые релизы» → А не потому ли они такие частые, что баги проскакивают на прод?

— «Требования постоянно меняются» → Тем более — как вы контролируете, что старое не ломается?

— «И так работают наизнос если еще и тесты заставить писать — выгорят» → А не от бесконечного ли футбола с багами они выгорают?

А как у вас? Есть автотесты на проекте? Или тоже «не до них»?

Я написал целую статью на эту тему, если все выше вам откликается рекомендую к прочтению: Нет времени на тесты — через неделю релиз

«Русский FAANG». Стоит ли туда стремиться QA/AQA и другим?

В русском IT регулярно всплывает формулировка «русский FAANG» и многие хотят туда попасть. В этом посте на основе своего опыта разберу, стоит ли оно того.

Начнем с того, что каждый под словосочетанием русский FAANG подразумевает разное. Есть как минимум:
1. ВАСЯ: ВК, Альфа, Сбер, Яндекс
2. МЯСОВАТА: Mail (VK), Яндекс, Сбер, Озон, Валдберрис, Авито, Теле2, Альфа
3. Мой любимый - ОБОСРАЛСЯ: Озон, Билайн, ОККО, Сбер, Рамблер, Атол, ЛамодаТех, Совкомбанк, Яндекс

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

Так стоит ли QA/AQA и другим стремится в ВАСЯ или можно ограничится ОБОСРАЛСЯ или даже обычными мелкими компаниями / стартапами?

Чего стоит попасть туда (насколько это сложно)

У многих есть ощущение, что российский бигтех - это нечто недосягаемое. Почти как западный FAANG.

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

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

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

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

Где лучше и стоит ли оно того

Я поработал много где как AQA - Ozon, WB, VK, несколько российских и западных стартапов, бигтех US.
И могу с уверенностью сказать, что тут не угадаешь, везде всё по разному. Например, в одном из криптостартапов я встретил лучшие процессы, что видел в жизни, а в двух из бигтехов - миллион токсиков, невероятную бюрократию и в целом не очень классные процессы.

Поэтому мое личное мнение - умирать ради работы в конкретной компании вообще того не стоит.

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

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

Те же самые "интересные задачи" есть везде, а в стартапах они часто даже круче и челленджовее.

Что в сухом остатке

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

Всем спасибо за внимание! В комментариях готов подискутировать на эту и смежные темы!
В своем блоге Telegram также пишу про тестирование и автоматизацию, ну и в целом про карьеру в сфере IT. Всегда рад новым читателям!)

Приглашаем тестировщиков на митап. Вместе с Moscow QA подготовили три ярких доклада:

Помогите, flaky!

Екатерина Лахтина, тимлид QA UGC в 2ГИС, поделится подходом, который помогает находить и устранять flaky‑тесты, снижать ручную работу и добавлять автоматизацию.

Как прокачать автотесты с 0 до keyword-driven

Анастасия Нестерова, QA Engineer, расскажет, какие методы пробовали, где спотыкались и как в итоге выстроили процесс на стеке Playwright + TypeScript. 

Вайб‑кодинг в тестировании с позиции менеджера

Виктория Дежкина, менеджер направления, поделится плюсами и минусами нового подхода в тестировании: как влияет на команду, какие есть риски и стоит ли вообще пробовать.

👉 Регистрация

Встречаем март с новыми вакансиями в SSP SOFT

SSP SOFT — компания работает в сфере заказной разработкой ПО и предоставления выделенных команд на ИТ-аутсорсинг для крупных клиентов. У нас всегда есть открытые вакансии — за прошлый год мы наняли 179 сотрудников.

Рабочие места предоставляются в московском офисе, который открылся в 2025 году у самой Красной площади. А еще есть вакансии в офис разработчиков в Томске и на удаленку из любой точки России.

Работа в SSP SOFT — это реальные проекты, дружная атмосфера, где работать — продуктивно, без выноса мозга и микро-менеджмента. В марте 2026 ищем опытных спецов, кто готов в новое профессиональное будущее вместе с нами.

Самые горячие вакансии прямо сейчас:
1️⃣ Разработчика DWH
2️⃣ Data Аналитика
3️⃣ Технического писателя
4️⃣ Fullstack QA Engineer (Java/Kotlin)
(см. ссылку на остальные вакансии ниже на ХХ-ру)

Что предоставляет экосистема SSP SOFT:
✅ Мы пишем код, который формирует завтрашний день. Никакой скучной рутины.
✅ Центр компетенций и личное менторство ускорят развитие до максимума.
✅ Офис, гибрид или фулл-удаленка? Есть все варианты.
✅ Время — ваш ресурс. Мы его уважаем.

Подробности о вакансиях читайте на нашей странице ХХ.ру, но там откликаться необязательно. Ждем резюме напрямую в ЛС нашей HR Lead Алине (https://t.me/AONikitina).
Не забудьте добавить «секретную фразу» в сопроводительное письмо, «Увидел(а) вашу вакансию на Хабре».

Желаем всем хабровцам успешной карьеры в 2026 году 🚀

Среди пентестеров в настоящее время сложилась такая тенденция, что "внутреннее тестирование" подразумевает под собой исключительно взятие домена: ребята идут на проект с одной целью - взять AD и стать доменными администраторами. Однако, в сети живут не только рабочие станции и ноутбуки пользователей под управлением 💻 Windows. Мало того, что сеть полна зоопарком IoT устройств: принтеры, камеры наблюдения, роутеры, IP-телефония; так еще и внутренние веб-порталы, различные ERP-системы и среды разработки часто преобладают в общей "сетевой" массе.

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

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

Среди основных выводов, данные программы показывают такие важные вещи, как SUID и GUID/SGID. SUID (Set User ID) заставляет программу при запуске временно работать с правами владельца файла (часто root), а GUID/SGID (Set Group ID) — с правами группы файла. То есть, если у исполняемого файла стоит бит SUID и его владелец — root, а программу запускает обычный пользователь, то программа запускается от имени рута.

Для помощи в эскалации привилегий группа исследователей разработали GTFOBins — онлайн-каталог встроенных в Unix/Linux утилит (bin’ов), которые при неправильной настройке, в том числе SUID/SGID, можно использовать, чтобы обойти локальные ограничения. Однако ручная проверка 40-50+ сервисов - не самая лучшая идея.

Поэтому, для помощи в "моментальном" получении суперпользователя при неправильной настройке SUID/GUID я разработал оффлайн утилиту AutoSUID. Она построена на базе проекта GTFOBins, имеет предзагруженную библиотеку мисконфигов (работает на системах без интернета) и, самое главное, работает с использованием штатных средств Linux (так как у простого пользователя нет прав на установку дополнительного ПО).
То есть просто закидываете .sh файл на тестируемый сервер и запускаете. Если есть уязвимые приложения, сразу получаете терминал рута (см. картинку). Вобщем, рекомендую!

Однако, если вы начинающий Linux пентестер, я не советую слепо исполнять мой скрипт равно как и LinEnum с LinPeas. Компания Splunk еще в 2021 году указала, что наши утилиты являются прекрасными инструментами для системных администраторов и ИБ при обнаружения потенциальных ошибок в системе. Вместе с тем они также могут быть использованы злоумышленниками для повышения привилегий и иных подозрительных действий.

Поэтому, перво-наперво, я бы рекомендовал изучить "матчасть" и понять, как работают скрипты под "капотом", а уже потом использовать средства автоматизации!

🧠 Обязательно поделись с теми, кому это может быть полезно 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте | ⚡️Бустануть канал

Бесплатный мини-курс для специалистов по ручному тестированию. От нейросети до тест-кейса: практическое применение ИИ в тестировании.

Привет, Хабр! Я — Николай Корнетов, ведущий инженер-тестировщик в IBS. Мы с коллегами записали бесплатный мини-курс об использовании искусственного интеллекта для задач ручного тестирования.

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

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

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

В зависимости от сложности схемы, печатная плата может быть выполнена в 1-2 слоя: тогда дорожки можно визуально "проследить", просветив их фонариком. К слову сказать, лет 20-30 назад инженеры вообще не испытывали таких проблем, так как печатные платы были формата сквозного монтажа и все дорожки были снаружи и, как правило, контрастные.

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

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

В данном случае, у меня на исследовании ключ автомобильной сигнализации. Как можно видеть по схеме, вся электроника крутится вокруг чипа A3XA5 QFN, работающего на частоте 27.6 МГц. С учетом того, что данное устройство является элементом безопасности, в интернете ноль информации по плате, чипу, алгоритму и т.д. Но это ненадолго: я провел собственное исследование и в скором времени опубликую свои находки! Поэтому, не переключайтесь ;)

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

🧠 Обязательно поделись с теми, кому это может быть полезно 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте | ⚡️Бустануть канал

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

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

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

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

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

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

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

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

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

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

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

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

Олег, 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.