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

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

Первое и самое сложное — это съемки. Иногда, для того чтобы записать 5-тиминутное видео, у меня уходило по 4 часа. И я сейчас не говорю про человека‑соседа, решившего повесить полку именно в момент съемки. Это и забывчивость подготовленного текста, Эканья и Аканья, почесывания, сбой в ПО при презентации экрана и банальная усталость от сидения на табуретке (именно табуретке, так как спинка стула мешает в кадре). А так как режиссер требует все записывать «одним дублем», иногда приходилось раз 20 перезаписывать 10-ти минутное видео с самого начала.

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

Технологи начали требовать от нас составления плана на каждое видео: какие цели мы ставим перед уроком, какими задачами мы их достигнем и чему в итоге научится студент, посмотрев видео‑урок (что делали сами технологи, кроме как указывать нам на это, мы так и не поняли). Более того, это нужно проговаривать в начале каждого видео, и в конце повторяться и подводить итог, чему же все‑таки научились студенты.

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

Ну и меньшее из зол, это неудобство исполнения. С учетом того, что я записывался в квартире, это накладывало свои особенности взаимоотношений с родными. Одна из комнат была постоянно занята, так как был развернут хромакей 2×2 метра, дополнительный свет, камера, микрофон, а заниматься постоянной сборкой‑разборкой такой конструкции то еще занятие. Кроме того, семья и человек‑сосед должны находиться в тишине, чтобы не было шума на фоне, а с учетом наличия детей — это просто нереально.

В общем, с горем пополам мы записали пару пилотных уроков, но потом решили завершить начинание. Это очень большой и тяжелый труд, который требует много сил. И это я еще не говорю про само содержание курса, которое должно быть качественным, актуальным и конкурентноспособным. А с учетом планов маркетологов по выпуску 2–3 уроков в неделю, это было более чем призрачно.

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

Прилагаемое видео — один из демо видеоуроков, который мы записали и смонтировали. Понимаю, что не у всех есть возможность посмотреть в YouTube, поэтому я залил видео во 📺 ВКонтакте. Желаю приятного просмотра.

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

Всепомнят захватывающий монолог Вигго Тарасова из фильма «Джон Уик», когда он рассказывал легендарную историю про «Бабу ягу» и уби**тво им трех человек... карандашом? Я думаю, 9 из 10 человек ответят утвердительно. А слышал ли кто‑нибудь из вас не менее захватывающую историю про открытие металлического сейфа... деревянной палочкой для суши? Я думаю тут таких не будет, поэтому исправляем ситуацию.

В рамках аппаратных исследований к нам на реверс‑инжиниринг в этот раз попал сейф EASY SAFE от китайской компании JIANGSU SHUAIMA SECURITY TECHNOLOGY с электронным замком. В соответствии с инструкцией на сейф можно установить 2 кода: пользовательский и дополнительный, каждый длиной от 3 до 8 символов. Для этого необходимо открыть сейф и нажать красную кнопку на внутренней части двери.

Кажется, безопасно, если не несколько НО!

Во‑первых, вышеназванная красная кнопка просто огроменная, что делает ее достаточно легкой целью.

Во‑вторых, наличие технического отверстия aka дырки аккурат напротив кнопки.

Следовательно, если владелец сейфа не прикрутил его к бетонной стене или иному недвижимому объекту, он подвергает себя большому риску.

И это только начало и, по сути, вершина айсберга «безопасности». В общем, не буду больше спойлерить. Остальные файндинги и полный разбор‑исследование данного аппарата можно будет почитать у меня на Хабре в скором будущем ;) Stay tuned!

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

QA, выбирай сторону

Мы возвращаемся с новым форматом QAчественного общения — антимитапом для тестировщиков.

Когда: 27 марта
Где: Санкт-Петербург, offline only

В этот раз сделали два зала и два настроения:

🔥 Test core
Пространство вызовов, острых тем и адреналина. Сарказм приветствуется, личные нападки — запрещены.

Будут холивары: «Hard Skills для QA — это про инструменты или про понимание систем?», «Как меняется профессия QA с приходом AI».

💆‍♀️ Debug
Зал для размышлений и рефлексии. Здесь не доказывают, а задаются вопросами и делятся гипотезами. Тот самый safe space, чтобы подумать о будущем QA.

Будут дискуссии: «Как принять свою роль и стать хорошим тестировщиком», «ИПР: развитие специалиста — это задача компании или специалиста?».

Вы сами выбираете маршрут. Можно передвигаться между залами и собирать инсайты с двух полюсов или остаться в одном пространстве и погрузиться в его формат.

🔗 Зарегистрироваться на митап

Playwright в 2026: новый стандарт UI‑автоматизации

На протяжении последних нескольких лет Playwright из альтернативного инструмента превратился в де‑факто стандарт для UI‑автоматизации в современных веб‑приложениях.

Основная причина тому — архитектурный сдвиг. В отличие от Selenium, который опирается на WebDriver и добавочный слой взаимодействия с браузером, Playwright работает напрямую через DevTools‑протокол. Это устраняет лишние абстракции и снижает накладные расходы на взаимодействие.

На практике это дает три ключевых эффекта:

Стабильность

Встроенный механизм auto‑waiting и синхронизации с состоянием DOM значительно снижает количество flaky‑тестов. Инженеру больше не нужно вручную управлять ожиданиями и обрабатывать race conditions.

Производительность

Благодаря прямому взаимодействию с браузером и встроенной поддержке параллельного выполнения, Playwright демонстрирует более быстрый feedback loop в CI/CD пайплайнах.

Developer Experience

Инструмент предоставляет полноценный набор средств чуть ли не из коробки: trace viewer, codegen, network interception, изоляция через browser contexts. Это снижает порог входа и ускоряет разработку тестов.

При этом важно понимать: Playwright не является «серебряной пулей». Он не делает плохую архитектуру тестов хорошей, не отменяет необходимость в грамотной декомпозиции сценариев, и не заменяет стратегию тестирования.

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

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

Если у вас уже есть зрелая Selenium‑инфраструктура — решение о миграции должно приниматься на основе метрик (flaky rate, время выполнения, стоимость поддержки), а не трендов.

Компания Mistral AI представила большую языковую модель Leanstral. Это проект для разработки приложений с помощью вайб‑кодинга и оптимизированный для формальной верификации кода. Предполагается, что Leanstral может применяться для создания ИИ‑ассистентов, позволяющих не просто генерировать код, но и гарантировать отсутствие в нём ошибок.

Leanstral стала первой открытой моделью, поддерживающей язык программирования Lean 4 и связанный с ним инструментарий для проверки математических доказательств. Lean 4 предоставляет возможности для математического доказательства корректности кода и его соответствия спецификации, что в контексте вайб‑кодинга позволяет подтвердить, что сгенерированный ИИ‑моделью код делает именно то, что задумано.

Модель Leanstral охватывает 119 миллиардов параметров (6.5 млрд активируемых параметров на токен), учитывает контекст в 256 тысяч токенов и опубликована под лицензией Apache 2.0. Загружаемый архив с Leanstral занимает 121 ГБ и пригоден для использования на локальных системах. Для локального запуска могут применяться библиотеки vllm, transformers и SGLang.

Для оценки возможностей ИИ-моделей с учётом качества проведения формальной верификации кода и написания математических доказательств разработан новый набор тестов FLTEval. В проведённых тестах модель Leanstral обогнала существующие открытые модели Qwen3.5 397B‑A17B, Kimi‑K2.5 1T‑A32B и GLM5 744B‑A40B, показала сходные результаты с моделями Claude Haiku 4.5 и Claude Sonnet 4.6 от компании Anthropic, но отстала от модели Claude Opus 4.6. В частности, модель Opus набрала 39.6 баллов, а Leanstral — 21.9 при одном проходе и 31.9 при 16 проходах. При этом затраты при использовании Opus составили $1650, а Leanstral — $18 при одном проходе и $290 при 16 проходах. Модель Haiku набрала 23 балла при затратах $184, а модель Sonnet — 23.7 при затратах $549.

Зелёные тесты ≠ хорошие тесты

Впервые в истории писать тесты стало легко и совсем не страшно. Вокруг теперь у всех покрытие 80%, 90%, а то и вовсе 100%. И вот тут начинается проблема: зелёные тесты ≠ хорошие тесты.

Проблема в метрике, которой мы все привыкли доверять. Code coverage считает строку протестированной, если она выполнилась во время теста. Всё. Не «поймает ли тест баг в этой строке», не «проверяет ли он правильность результата» — просто выполнилась. Можно написать тест без единого assert, и покрытие вырастет. 500 тестов, 90% coverage, а пользы ноль.

Мутационное тестирование — это совершенно другой путь. В простейшей реализации этот инструмент тупо берёт твой код и намеренно ломает его: меняет > на >=, + на ‑, True на False. Каждая такая поломка — мутант. Если после мутации все тесты по‑прежнему зелёные — значит они ничего не проверяют. Покрытие есть, защиты нет.

Почему это важно именно сейчас?

Потому что нейронка любит зелёненькое. Чем больше зелёных тестов — тем субъективно лучше. 100 тестов внушают больше доверия, чем 10, правда? А внутри там assert response.status_code == 200. assert result is not None. assert len(items) > 0. Тест проверяет, что функция вернула хоть что‑то — и радостно зеленеет. Поменяй логику условия, перепутай знак, сломай граничный случай — тест всё равно зелёный. Потому что он проверяет не правильность, а наличие.

Мутационное тестирование — единственный автоматический способ это поймать. Метрика называется mutation score: процент убитых мутантов. 60% — плохо. 90%+ — тесты реально что‑то защищают.

Кое‑какие инструменты для такого тестирования уже есть: mutmut и cosmic‑ray для Python, Stryker для JS/TS, PIT для Java. Медленно? Да, значительно медленнее обычного тест‑рана. Но запускать его не нужно на каждый коммит — достаточно на PR в критические модули.

Но есть нюансы. А где их нет, правда?

Первый: мутации рандомные. Замена > на >= — это не баг, который кто‑то реально допустит. Это синтетическая поломка. Половина мутантов генерирует код, который в реальности никогда не появится. Ты тратишь время на убийство мутантов, которые не имеют отношения к настоящим ошибкам. Это как тестировать замок, ковыряя его вилкой — формально проверка, по факту мимо.

Второй — ещё хуже. Чтобы убить мутанта, тест должен зафиксировать конкретное поведение. Каждую ветку, каждое значение, каждый edge case. Доведи mutation score до 100% — и ты прибил гвоздями каждую строчку кода. Буквально. Теперь попробуй отрефакторить. Переименовал внутренний метод — 40 тестов красные. Поменял порядок полей в ответе — ещё 20. Тесты превращаются из страховки в кандалы: код работает правильно, но тесты падают, потому что они проверяют не поведение, а реализацию.

Это реально ловушка. Слишком гонишься за mutation score — получаешь хрупкие тесты. Не гонишься — получаешь видимость тестирования.

Перемены — впереди!

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

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

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

Ждём, когда мутанты станут умнее.

Попадая в подсеть контроллера домена, первое, что делает любой пентестер, это перебор учётных записей пользователей (Kerbrute атака). Существует много статей об этом типе эксплуатации, но в каждом источнике авторы используют заранее подготовленный словарь (Смиты, Джоны, Уайты...), который не слишком точно соответствует реальной жизни. Сегодня мы попытаемся заполнить этот пробел и создать универсальный рабочий словарь для атаки Kerbrute в российской среде AD.

Первое, что нам нужно сделать — понять, как администраторы создают учётные записи в домене, а точнее — каков шаблон имён пользователей. Лучшей практикой для корпоративных имён пользователей является сочетание фамилии человека и первой буквы его имени, например в моём случае — iglinkin@corporate.local или i.glinkin@corporate.local. Шаблон зависит от политики безопасности компании и может выглядеть так: ivanglinkin@corporate.local, glinkini@corporate.local, glinkin.i@corporate.local, glinkinivan@corporate.local, или даже просто фамилия — glinkin@corporate.local

Для более точного определения формата пентестеры изучают сайты организаций и посещаемых ими публичных мероприятий: там как раз и указан верный формат. Например, в Microsoft используют формат ИФамилия@microsoft.com: John Winn имеет почту jwinn@microsoft.com.

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

Мониторя интернет, я нашёл интересный источник https://woords.su/full-name/russian-surnames: в нём содержится почти полный список русских фамилий, в том числе уже c окончаниями "а" для женской половины. Ну а дальше дело техники: создаем скрипт,
for p in {1..2234}; do curl -shttps://woords.su/surnames/russian/page-$p | grep "<tr><td>" | sed 's/<tr><td>/\n/g' | sed 's/<\/td><td>/\n/g' | cut -d "/" -f 5 | cut -d "\"" -f 1 | sed 's/surname-//g' >> surnames.txt; done
который парсит все фамилии и кладет в файлик surnames.txt.

Далее генерируем простой словарь с буквами. Его можно даже создать вручную, там всего-то будет 28 букв (минус Ë, Й, Ъ, Ы, Ь - так как с них имена не начинаются): a, b, v, g , d, e, zh, z, i, y, k, l, m, n, o, p, r, s, t, u, f, h, ts, ch, sh, shch, yu, ya.

Последний шаг — это добавить каждую букву перед каждой фамилией. Что может быть проще?
for name in $(cat one_letter.txt); do for surname in $(cat lastnames.txt); do echo $name$surname; done;done
Полный список username'ов будет состоять из чуть более 9 миллионов. Достаточно много, но, как показывает моя практика, они перебираются за 1.5 часа через kerberos_enumusers от метасплоита.

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

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

За пару-тройку месяцев пристрастился к публикациям на Хабр.
И, чтобы это не превращать эту новую привычку в пустое графоманство, решил сфокусироваться и прикинуть в этом посте темы для следующих публикаций:

• Как судить песни на онлайн-турнирах в числах?

• Функция Cover в Suno для возведения нашего творчества в степень

• Типовые баги в русской фонетике относительно песнен из Suno

• Публикуем музыкальный альбом через сервис дистрибьютора

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

«Оплата улыбкой» — это сервис Сбербанка, который позволяет оплачивать покупки на кассах в магазинах с помощью биометрии. Проект был запущен летом 2023 года как альтернатива ушедшим с рынка платежным сервисам... Для оплаты нужно посмотреть в камеру, которая распознает изображение лица и сопоставляет его с уникальным номером, привязанным к биометрическим данным. Этот номер также привязан к счету карты. Если данные совпадают, оплата проходит. (с) РБК

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

1. Набор камер получает кадр лица

2. Алгоритм находит лицо на изображении (рамку вокруг лица)

3. Система ищет ключевые точки (глаза, нос, уголки рта) и “выравнивает” лицо

4. Нейросеть преобразует лицо в вектор признаков (эмбеддинг) — набор чисел, который компактно описывает уникальные черты

5. Дальше считается “близость” двух векторов, например, косинусное сходство или евклидова дистанция: если сходство выше порога, то доступ/оплата разрешена.

Системы безопасности в таких устройствах настроены на защиту от подстановки фотографий, масок, а также добавляют проверки на "человечность". Так, системы анализируют блики и глубину, микродвижения, отражения от ИК-камера (кожа и материалы отражают по-разному); определяют объемность и т.д.
Поэтому, в профессиональных системах биометрии обычно используется нескольких камер:
• обычная RGB: получение изображения лица
• ИК: даёт надёжную проверку "человечности"
• глубина (3D/ToF): уверенное отделение “лица” от плоской подделки.

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

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

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

44 собеса за месяца — Жив ли рынок QA/AQA на самом деле?

Последний год в IT регулярно обсуждают одну и ту же тему — рынок стал сложнее.
Вакансий меньше, требования выросли, конкуренция усилилась.

Особенно часто это можно услышать от специалистов из QA/AQA:
Мол, тестирование переполнено, вакансий мало, а найти новую работу стало почти нереально.

Я давно консультирую ребят в сфере QA и автоматизации тестирования (AQA) и регулярно наблюдаю, как специалисты выходят на рынок. Поэтому иногда вижу довольно наглядные примеры того, как ситуация выглядит на практике.

Как раз недавно один из ребят показал в нашем чатике свой календарь собеседований за декабрь — этот календарь приложил выше.

И, честно говоря, даже меня это немного удивило. За месяц у него набралось 44 собеседования.

Причём:
Во-первых, всё это происходило параллельно с основной работой.
Человек не уходил в отпуск и не ставил поиск работы на полный день — все интервью проходили между рабочими задачами.

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

Тем не менее календарь получился очень плотным.

Иногда у него было по несколько интервью в день:
HR, технички, финалки, снова HR.

А если представить его лицо 11го декабря — то лучше не надо)

P.S. Выходил на рынок он как Fullstack QA/AQA, если что. В ручном тестировании естественно ситуация похуже. Но наверное основной моей задачей и являлось помочь ему с этим переходом (QA->AQA), т.к. именно тут наилучшая конверсия для QA.

И что по итогу? Оправдались ли такие усилия?

Думаю, всем это тоже будет интересно. Стоило ли оно вообще того.

Вы реально думаете, что человек, который проходил по 6 собесов в день, мог не добиться своего?)

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

В итоге этот кандидат получил 6 офферов.

Один из них оказался особенно сильным — около 490 000 рублей gross для позиции в автоматизации тестирования.

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

Да, он действительно стал сложнее.
Да, требования выросли.

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

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

А те, кто не пытается, чаще находят объяснение, почему сейчас «не время».

Поэтому, когда в очередной раз услышите, что рынок QA/AQA окончательно умер, просто вспомните календарь из 44 собеседований за один месяц.

Спасибо, что дочитали пост до конца! Надеюсь, смог зарядить вас мотивацией, это была моя основная цель 🙂

В комментариях готов подискутировать на эту и смежные темы! Ну а в своем блоге Telegram также пишу про тестирование и автоматизацию, иногда затрагивая и общие темы развития в сфере 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 | 📝 Хабр | 💙 ВКонтакте | ⚡️Бустануть канал