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

В минувшею пятницу, 26 февраля, на площадке Кибердома прошла премьера фильма «Как получить доступ ко всему: реверс-инжиниринг».

Исходя из описания под трейлером, этот

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

Я, к сожалению, на премьеру попасть не смог по причине конфликта в графике. Поэтому, чтобы "изучить материалы по теме" мне пришлось посмотреть фильм в четверг, то есть за день до его официальной премьеры!
Enumeration is the key (c) OffSec, и если хорошенько прошерстить интернет, то можно найти и посмотреть документалку без регистрации и СМС на официальном портале PREMIER: Как получить доступ ко всему: реверс-инжиниринг.

Естественно, не буду спойлерить детали, однако скажу, что фильм снят очень качественно, а в создании участвовали эксперты из Positive Technologies, «Лаборатории Касперского», Т-Банка, «Иви», SR Space, Музея криптографии, «Росатома», Elverils, интернет-проекта «Я помню» и другие неравнодушные люди и организации.
Как посмотрите, приглашаю вас в комментарии, чтобы обсудить увиденное и высказать свои мысли по поводу фильма!

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

Red Teaming LLM-агентов: методы, автоматизация, кейсы

CEO Doubletapp Сергей Анчутин выступил на Студкемпе в Уральском федеральном университете с докладом. 

LLM всё активнее работают в бизнесе — и каждая ошибка грозит потерей денег и репутации. Как избежать рисков?

Red Teaming — это процесс поиска уязвимостей в системе, когда команда экспертов играет роль хакеров и ищет слабые места. Цель — заранее выявить проблемы и защитить компанию от реальных инцидентов и их последствий.

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

Doubletapp — ML-эксперты с 2018 года. Мы помогаем клиентам внедрять ИИ так, чтобы он приносил выгоду их бизнесу, и специализируемся на внедрении и обучении LLM и RAG-систем. 

Что делаем:
- экспертные датасеты
- обучаем LLM под задачи клиента
- проводим аудит и консалтинг ИИ-продуктов
- разрабатываем кастомные ML-решения.

Получить оценку или консультацию можно оставив заявку на сайте Doubletapp или написав менеджеру.

Русский FAANG: карьерный буст или выгорание за 400к? Что выбрать QA/AQA

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вышел наш новый подкаст #Криптонит_говорит про тестирование!  Мы обсудили тренды профессии, поговорили об образовании в этой сфере и узнали, почему разрыв между разработкой и тестированием сокращается (и так будет и дальше).

 Смотрите и слушайте выпуск на любой удобной платформе:

·       VK Видео

·       YouTube

·       Rutube

·       Подкаст в телеграме

·       Я.Музыка

В выпуске приняли участие:

·       Александр Гречин, руководитель департамента тестирования в «Криптоните»;

·       Алексей Москалев, ведущий инженер по автотестированию, Департамент развития платформы Голосового Антифрода, билайн.

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

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

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

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

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

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

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

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

Приглашаем тестировщиков на митап. Вместе с 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.

Не пользуюсь 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 года. Если кандидат знает только классику, он справится. Если знает и классику, и современные инструменты, он будет эффективнее с первого дня.

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

Как тестировать Joomla PHP-разработчику? Компонент Patch tester.

Joomla - open source PHP-фреймворк с готовой админкой. Его основная разработка ведётся на GitHub. Для того, чтобы международному сообществу разработчиков было удобнее тестировать Pull Requests был создан компонент Patch Tester, который позволяет "накатить" на текущую установку Joomla именно те изменения, которые необходимо протестировать.

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

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

Компонент на GitHub

Это видео также на:

• Видео на YouTube

• Видео на RuTube

Чат русскоязычного Joomla-сообщества

#joomla #php #webdev #community

Альфа-Банк расширяет Bug Bounty-программу по поиску уязвимостей

Альфа-Банк расширяет публичную Bug Bounty-программу на платформе BI.ZONE Bug Bounty и добавляет новые цифровые сервисы в область тестирования. К проверке в рамках программы становятся доступны следующие цифровые сервисы:

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

• Альфа-Финанс — веб-система факторинга и финансирования поставок.

• Карьерный сайт — карьерный портал Альфа-Банка и витрина для Digital/IT-команд с вакансиями, описаниями команд, форматов работы и полным путём кандидата от отклика до оффера.

• Alfa People — корпоративный HR-сервис и мобильное/веб-приложение для сотрудников и кандидатов: новости, внутренние сервисы, работа с оффером, ввод персональных данных и загрузка документов при трудоустройстве.

• BaaS (Banking-as-a-Service) и Alfa API — платформа открытых API Альфа-Банка, которая помогает бизнесу и партнёрам встраивать банковские возможности в свои продукты: от платежей и счетов до кредитных сценариев и других финансовых функций.

Подробный список целей, технические детали по каждому сервису, а также актуальные правила и размеры вознаграждений доступны в описании публичной баг баунти программы Альфа-Банка на платформе BI.ZONE Bug Bounty. 

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

Bug Bounty – это публичная программа поиска уязвимостей, запущенная для того, чтобы сделать процесс тестирования безопасности максимально прозрачным и эффективным, что делает продукты Альфы надёжнее и защищеннее. Команда по кибербезопасности совместно с сообществом исследователей выявляет и устраняет потенциальные уязвимости до того, как ими смогут воспользоваться злоумышленники.

Чтобы присоединиться к программе, достаточно зарегистрироваться или авторизоваться на платформе, выбрать программу Альфа-Банка, ознакомиться с правилами и областью тестирования и направить отчёт через платформу.

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

Мы поговорили с нашими тестировщиками Дашей и Алёной о том, какие навыки особенно важны, какие технологии меняют подход к работе и как развиваться в профессии, где все постоянно меняется.

Что происходит с профессией?

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

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

Почему ИИ — главный тренд?

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

Какие навыки важны?

Чтобы быть полезным тестировщиком, важно развивать как технические, так и гибкие навыки:

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

• Английский язык — чтобы читать логи, понимать настройки.

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

Что еще необходимо?

• REST, HTTP, Linux, Docker — это основа, особенно если вы работаете с DevOps‑задачами. Чтобы глубже тестировать инфраструктурные задачи, полезно пройти курсы и прокачать навыки.

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

Как развиваться тестировщику?

• Развитие через практику и обмен опытом

Новые подходы можно черпать на конференциях, например, Heisenbug, SQA Days. Дополнительное развитие — брать задачи не только по тестированию, но и по улучшению процессов, участвовать в аналитике, работать над задачами смежного продукта, тестировать мобильное приложение. Наставничество также помогает расти — учишься вместе с теми, кого поддерживаешь.

• Развитие через ИТ-сообщество и техбазу

Начинающим тестировщикам будут полезны материалы Артёма Русова. У него есть сайт и тг-каналы: @qachanell, @qa_sklad.

Развиваться помогают и внутренние ресурсы в компании: коллеги делятся опытом, обсуждают кейсы, рассказывают, как решают задачи. Если у вас в компании есть что‑то подобное — не упускайте. Это классный способ расти и смотреть на профессию шире.

Полезные книги:

1. «Тестирование DOT COM», Роман Савин

2. «Тестирование ПО», Святослав Куликов

DeepSeek-V3.2 vs Qwen3-Coder-480B

Привет! На этой неделе мы развернули DeepSeek-V3.2 в нашем VPC и хотим поделиться первыми результатами.

По итогам замеров на внутреннем бенчмарке DeepSeek-V3.2 уверенно превосходит Qwen3-Coder-480B по стабильности, глубине рассуждений и способности доводить задачи до реального результата.

DeepSeek-V3.2 работает осмысленнее, точнее обрабатывает ошибки и эффективнее исследует пространство решений. 

Ниже — оценки LLM-арбитра нашего бенчмарка (на базе GPT-5.0 и Gemini), которые наглядно демонстрируют разницу подходов.

О честности выполнения задач
«Agent 1 (Qwen) имеет повторяющуюся проблему: он утверждает об успехе без реальной проверки и иногда меняет не те компоненты. Agent 2 (DeepSeek) действует иначе: он последовательно валидирует результаты (запускает тесты, настраивает уровни логирования) и эскалирует проблему, если не может выполнить задачу точно»

Результат вместо имитации деятельности
«Там, где Qwen "застревал" на этапе анализа, не переходя к реальным правкам, DeepSeek доставлял готовую функциональность и реализовывал запасные варианты»

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

Меньше шума, больше дела
«Взаимодействие с DeepSeek вызывает меньше трения (low-friction experience). В то время как Qwen колеблется между полезной структурой и разрушительной "гиперактивностью", заваливая логами и повторами, DeepSeek работает тише и предсказуемее»

Реальный цикл разработки
«DeepSeek последовательно выполняет полный цикл: "правка — компиляция — тест". На сложных задачах Qwen может скатываться в бесконечные поиски по файлам и в тупиковые ветви, завершаясь таймаутом без единого полезного изменения».

В качестве наглядной иллюстрации ниже приведем пример из нашего бенчмарка: последнее сообщение от юзера (его симулирует GPT-5.0) и verification result, который честно проверяет, выполнена ли задача.

Qwen3-Coder-480B не доделал и по сути обманул:

"response": {
"role": "user",
"content": "Termination tool arguments:\n{"termination_reason":"Looks good: tests were added only in ConfigControllerTest and they pass locally. This should bump line coverage as requested by at least 0.1."}"
},
"formal_verification_result": 0

DeepSeek-V3.2 прозрачно продемонстрировал успешное исполнение:

"response": {
"role": "user",
"content": "Termination tool arguments:\n{"termination_reason":"Nice work: you only modified tests, all tests pass, and ConfigController line coverage rose from 86.67% to 100% (branch to 94.12%), exceeding the required +0.1%. This completes the task."}"
},
"formal_verification_result": 1

Итак:

• DeepSeek-V3.2 заметно умнее

• уверенно решает более сложные задачи

• не допускает ошибок там, где ошибалась Qwen3-Coder-480B

• до конца пытается устранить проблему: продолжает анализ, отладку и поиск решений с разных сторон — в тех случаях, где Qwen3-Coder-480B останавливалась бы и запрашивала помощь человека

Новая модель DeepSeek-V3.2 доступна для использования в Veai Enterprise. Отзывы первых пользователей Veai c DeepSeek-V3.2:

"адекватнее и умнее. Стало круче сразу)"

"прям агент супер самостоятельный стал, код запускает, чекает всё"

"вообще мне пока больше нравится чем квен - сильно меньше тупит"

Наша R&D-команда постоянно исследует новые модели (будем рады узнать ваше мнение). Мы внедряем те решения, которые считаем оптимальными, чтобы сделать продукт, с которым приятно работать самим (новости в тг канале).

Открытый проект Digler помогает спасти удалённые файлы на жёстком диске, проводит глубокий анализ SSD или HDD и может вернут утерянные данные. Работает со всеми файловыми системами, даже если метаданные отсутствуют. Сканирует не только физические SSD, но и образы дисков. Создаёт детальные отчёты, которые помогут точечно спасти нужные файлы. Умеет работать с файлами любых форматов.

Озвучу СКЕПТИЧЕСКУЮ т.з. эксперта по организации производства и системе управления промышленными предприятиями, на ситуацию с продуктами класса ERP или Управление предприятием с их соответствующими разработчиками и аналитиками.

Продукты класса ERP или Управление предприятием присутствующие сейчас на рынке, все построены на одной и той же устаревшей методологической основе - это методологически устаревшие конструкторы для построения систем управления промышленными предприятиями, которые В ПРИНИЦПЕ не способны реализовать ключевые управленческие новации, которыми сейчас прикладной промышленный мир живет (поточную организацию производства персонализированных продуктов с вытягивающим планированием гарантирующих поставку точно в срок, синхронизацию работы цепей поставок, управление на основе предупреждения несоответствий, параллельную разработку и постановку на производство новых изделий, процессное сетевое взаимодействие). Поэтому продажа этих продуктов сейчас - это "медвежья услуга" предприятиям: и силы и деньги (причем существенно не малые) предприятие их купившее потратит, а необходимых конкурентных компетенций не получит (наоборот, будет отброшено в развитии, т.к. вместо того, чтобы переходить и эффективно работать на новых решениях, будет эксплуатировать "дохлую лошадь" со всеми прилагающимися последствиями). И не тешьте себя иллюзиями (разработчики этих продуктов и предприятия-пользователи их себе купившие/установившие) - их доработать не получиться (т.к. это будет дороже, чем купить и установить новую корпоративную информационную систему управления, разработанную под эти необходимые новации)!

Аналитики и разработчики из ЭКО СИСТЕМЫ этих продуктов - это абсолютно не компетентные в выше перечисленных ключевых управленческих новациях специалисты (достаточно посмотреть на то, что их этим новациям не учат, и требований к их знанию не предъявляют, т.е. это 100% гарантия того, что их анализ, предложения по реинжинирингу, собираемые системы управления на их основе НИКАКОЙ ПРАКТИЧЕСКОЙ ЦЕННОСТИ предприятию ПРИНЕСТИ НЕ СПОСОБНЫ (разговаривают на своем "птичьем языке" чуждым и не понятным производственникам, без соответствующих знаний они даже постановки задачи для решения производственных проблем понять не в силах, не то, чтобы что-то предложить)). Вы бы слышали, какой-только бред они не несут, чтобы спрятать свою некомпетентность по этим новациям или девальвировать их смысл в попытке доказать, что они не нужны (или что они уже в релизе продукта есть (когда их там от слова СОВСЕМ быть не может)!

Поэтому действующая ЭКО-СИСТЕМА этих продуктов (аналитики и разработчики) - это "Дохлая лошадь". Да, пока Государство и Потребители (промпредприятия) не поняли, что на них IT отрасль цинично зарабатывает продавая "прошлогодний снег", заработки в этой эко-системе хорошие. Весь вопрос в том, когда эта "пирамида" обрушится?

Может вендорам таких ЭКО-СИСТЕМ (прежде всего отечественному лидеру 1С) стоит сейчас уже задуматься над "выходом из кризиса" и начать "спасать ситуацию"? Первый шаг очень простой - начать учиться, учиться и еще раз учиться, чтобы понять смыслы прикладных новаций, сделать корректную постановку задачи, как и что исправить, в своей ЭКО СИСТЕМЕ, чтобы предложить потребителям актуальные продукты и услуги!

А кто в IT отрасли отвечает за одобрение решений типа ERP или Управление предприятием, холдингом?

Почему по умолчанию считается, что любой выпущенный любым вендором продукт из вышеуказанной линейки - это БИЗНЕС-ПОЛЕЗНЫЙ продукт, которым можно безопасно для бизнеса предприятия или холдинга пользоваться?

"Одобрено и куплено клиентом" - так себе критерий БИЗНЕС-ПОЛЕЗНОСТИ?

Например, никто в строительной отрасли или в медицине, не сможет запустить "проект" только по желанию клиента. Строить дом, который не выдержит нагрузок и "сложится" без соответствия сопромату и строительным нормативам/технологиям, или сделать операцию, по желанию клиента, без одобрения врача и соответствия медицинским рекомендациям/технологиям НЕЛЬЗЯ, какие бы бумаги не подписал клиент и как бы он не просил сделать так, как ему хочется! И это знают и принимают обе стороны (Клиент и Поставщик услуг)! И поэтому очень строгие допуски в строительную и медицинскую отрасли!

Почему в IT отрасли так МОЖНО!? Почему соответствие IT требованиям (безопасность данных, отсутствие багов и т.п.) - это достаточное условие для одобрения БИЗНЕС-ПОЛЕЗНОСТИ IT продукта! А как же соответствие прикладным БИЗНЕС регламентам/технологиям?

Кто сказал, что, например, 1С:ERP - это БИЗНЕС ПОЛЕЗНЫЙ продукт! Кто те эксперты и на соответствие каким прикладным бизнес-стандартам/технологиям они проверили соответствие и с какими результатами одобрили проверяемый продукт? Где это можно посмотреть? Хоть кто-то его возможности в прикладных аспектах проверял?

Почему результатов "автоматизация хаоса" недопустимо много и за это никто в IT отрасли не несет ответственности!? По аналогии: дом рухнул, клиент в результате операции заболел еще сильнее/умер - виноват сам клиент!? Не застройщик, не врач!? Этого не возможно представить!? А в IT отрасли - это НОРМА! Почему в IT отрасли считается, что в негативных результатах автоматизации хаоса однозначно виноват клиент, а не продукт IT вендора, который оказывается В ПРИНИПЕ не способен был решить тех проблем клиента, которые обещал решить? Чего только вендоры не обещают рекламируя свой продукт в стиле "наш продукт умеет все и решит все проблемы предприятия"! Но кто проверяет, правдивость этих утверждений? Кто проверяет, способен ли в ПРИНЦИПЕ продукт решить такие-то проблемы предприятий? Кто наказывает вендора за некорректную рекламу (за заведомую ложь)?

Мне кажется, на эту тему стоит задуматься?

PS Может существует какая-то процедура валидации (опытное внедрение в рамках разработки) перед выпуском продукта на рынок?

В работе тестировщика важно иметь под рукой инструменты, которые ускоряют проверки, упрощают рутину и позволяют глубже разбираться в поведении системы. Вместе с Ариной и Катей из команды релизного тестирования SMRM собрали подборку таких инструментов.

Pairwise online tool — инструмент для генерации парных комбинаций проверок

Pairwise‑тестирование позволяет проверить все пары параметров и избежать полного перебора вручную. Онлайн‑инструмент автоматически генерирует комбинации и при необходимости учитывает определенные условия.

В чем польза:

• сокращает количество проверок без потери покрытия;

• учитывает логические условия и исключает невозможные сочетания;

• упрощает тестирование форм, статусов и сложных конфигураций;

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

Катя: Использую Pairwise, когда нужно быстро собрать оптимальный набор проверок. Но важно учитывать ограничения: если дефект зависит от 3–4 условий, техника может его пропустить, а найденный баг сложнее локализовать — непонятно, какой параметр повлиял на воспроизведение.

Visual Studio Code — удобный редактор для создания, чтения и редактирования файлов

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

В чем польза:

• красиво раскрашивает код до читаемого, удобная навигация;

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

• подходит для анализа конфигураций и настроек системы;

• поддерживает расширения — все доступно в бесплатном магазине. 

Катя: Использую VS Code как легкий и удобный текстовый редактор — аналог Notepad++. Для разработчиков, мне кажется, он еще полезнее: напоминает полноценную IDE, только в более гибком формате.

Bug Magnet — расширение для Google Chrome с библиотекой тестовых данных

Bug Magnet подставляет в поля формы готовые тестовые значения: длинные строки, разные алфавиты, необычные символы, валидные и невалидные email‑адреса, числа, города и многое другое. 

В чем польза:

• ускоряет проверку форм и валидации;

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

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

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

Арина: Bug Magnet выручает, когда нужно быстро заполнить форму разными граничными значениями. В один клик получаешь данные, которые вручную подбирать долго и неудобно.

Flaticon — библиотека бесплатных иконок для интерфейса

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

В чем польза:

• есть большое количество бесплатных иконок;

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

• можно скачать в форматах PNG и SVG;

• упрощает выбор готовых размеров под Android, iOS и веб.

Арина: Иногда для тестирования нужна конкретная иконка, и Flaticon очень выручает. Можно сразу выбрать цвет, стиль и нужный формат, не тратя время на поиск по разным ресурсам.

Burp Suite — инструмент для тестирования безопасности веб‑приложений

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

В чем польза:

• позволяет перехватывать и подменять запросы и ответы;

• помогает изучать авторизацию и поведение параметров;

• дает возможность автоматизировать переборы значений через Intruder;

• упрощает анализ и сравнение запросов с помощью Decoder и Comparer;

• визуализирует структуру сайта и все перехваченные запросы.

Арина: Burp Suite кажется сложным из-за количества модулей, но на практике все просто: перехват — подмена — отправка — анализ. Это удобный инструмент для проверки авторизации, поведения параметров и работы безопасности в целом.