Обновить
256K+

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

Тестируем все и вся

189,42
Рейтинг
Сначала показывать
Порог рейтинга

ИИ пришёл в QA. Что с этим делать?

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

В этот раз в гости к Оле Шнайдер и Сергею Атрошенкову пришел Андрей Бровко, тестлид Авито Авто, AI-евангелист в тестировании и лидер AI Agent Dev Community. Андрей работает с этой темой изнутри, поэтому разговор получился конкретным: где ИИ уже реально помогает, где пока добавляет больше головной боли, чем пользы, какие риски стоит держать в голове — и что в работе QA-инженера искусственному интеллекту пока не под силу.

🎧 Слушайте выпуск подкаста на всех подкаст-платформах:

💬 Обсуждение тем, тренды в QA и, конечно, мемы — в Telegram-канале «Не воспроизводится».

Добро пожаловать в мир тестирования. Баги прилагаются.

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

Теги:
Всего голосов 25: ↑23 и ↓2+23
Комментарии1

Как думает хакер: логика атак на бизнес

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

27 марта состоялся очный бизнес-интенсив, реализуемый в рамках курса повышения квалификации «Анализ типовых сценариев компьютерных атак на организации и их последствия» МГТУ им. Н.Э. Баумана совместно с компанией Бастион!

Программа построена на исследовании сценариев реальных компьютерных атак и включает три ключевых блока:

1️⃣ Разведка: как хакер выбирает жертву
2️⃣ Внутренний взгляд: как атака развивается внутри компании
3️⃣ Вас взломали: что делать в первые 24 часа

Спикеры:

  • Дмитрий Калинин, директор департамента по работе с уязвимостями и инцидентами ИБ, Бастион

  • Иван Глинкин, руководитель группы аппаратного тестирования департамента по работе с уязвимостями и инцидентами ИБ, Бастион

Для тех, кто по тем или иным причинам не мог присутствовать очно, представляю полную запись интесива во 📺 ВКонтакте (3 часа 5 минут).

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

Теги:
Всего голосов 1: ↑1 и ↓0+3
Комментарии0

Представлен открытый ИИ-проект METATRON для проведения исследований, пентестов и поиска информации:

  • модель metatron‑qwen или дообученная Qwen 3.5;

  • ИИ автоматически пробивает и собирает все данные: сканирует порты, ищет уязвимости веб‑серверов и сведения о доменах и заголовках, профилях социальных сетей;

  • ищет уязвимости через DuckDuckGo;

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

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

  • работает полностью локально.

Теги:
Всего голосов 2: ↑2 и ↓0+2
Комментарии0

Представлен открытый OSINT-инструмент, который за несколько секунд собирает цифровой след по всему интернету. Проект Sherlock по одному нику пробивает аккаунты сразу на сотнях сайтов. Решение параллельно проверяет 400+ платформ: от соцсетей до форумов и цифровых площадок. На выходе получается список всех найденных профилей, можно выгрузить в файл или открыть прямо в браузере. Работает на любой системе, есть поддержка прокси и Tor.

Теги:
Всего голосов 4: ↑4 и ↓0+4
Комментарии1

Тестировщики из Авито запустили подкаст — и у них есть что сказать

«Не воспроизводится» ведут Оля Шнайдер и Сережа Атрощенков — практикующие QA-инженеры, которые каждый день работают с тем, о чём собираются говорить. В выпусках они разбирают реальные темы мира тестирования: ручное и автоматизированное тестирование, работа с ИИ, карьерный рост, отношения с командой, work-life balance — и всё, что обычно остаётся за закрытыми дверями ретро.

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

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

💬 Обсуждение тем, тренды в QA и, конечно, мемы — в Telegram-канале «Не воспроизводится».

Добро пожаловать в мир тестирования. Баги прилагаются.

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

Теги:
Всего голосов 26: ↑26 и ↓0+26
Комментарии1

Открытый сетевой инструмент Deep Eye может автономно искать уязвимости и проводить тесты на проникновение в исследовательских целях. Проект использует нейросети, которые коллективно ищут уязвимости на выбранном ресурсе и пытаются проводить различные тесты. Решение поддерживает 45 методов и атак. Алгоритмы системы собирают всю информацию о сайте, включая поддомены и DNS.

Теги:
Всего голосов 2: ↑2 и ↓0+5
Комментарии0

Представлен ресурс для тестировщиков с различными сервисами для автоматизации в одном месте: конверторы, json валидаторы, генераторы uuid и ещё десятки приятных мелочей.

Теги:
Всего голосов 3: ↑2 и ↓1+1
Комментарии0

7 открытых уроков для тестировщиков: автоматизируем тесты с умом

Теги:
Всего голосов 3: ↑2 и ↓1+3
Комментарии0

Онлайн инструменты для тестировщиков без регистрации и смс

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

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

Ссылка на ресурс: tools.save-link.ru

P. S. может работать как pwa расширение и даже в оффлайне

Теги:
Всего голосов 3: ↑3 и ↓0+5
Комментарии2

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

Попросили Костю, frontend-разработчика Naumen, рассказать, какие возможности DevTools он использует в работе и на что стоит обращать внимание.

1️⃣ Как открыть DevTools, если F12 не сработал

Самый простой способ — клавиша F12 для Windows/Linux. На macOS сочетание отличается, но открыть DevTools можно не только с клавиатуры.

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

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

2️⃣ Как работать с версткой во вкладке Элементы

Вкладка Элементы показывает DOM-дерево страницы — структуру документа, из которого собран интерфейс. 

Здесь можно:

  • навести курсор на элемент и посмотреть, где он находится на странице

  • быстро найти нужный блок через селектор

  • посмотреть размеры, фон и отступы

А еще можно посмотреть доступность — как элементы переключаются через Tab.

3️⃣ Как находить итоговые стили 

Если у элемента много CSS-правил, я перехожу во вкладку Вычисленные.

Там собраны все итоговые стили элемента — включая те, что пришли через наследование или заданы браузером. Можно быстро найти нужное свойство, например, border-radius, и понять, какое значение реально применяется.

4️⃣ Как проверять изменения без правок в коде

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

После обновления страницы все возвращается как было.

5️⃣ Как разбирать запросы во вкладке Сеть

Во вкладке Сеть видно, какие запросы отправляет страница и что приходит в ответ. А еще в этой вкладке есть не только список запросов, но и инструменты для фильтрации, поиска и просмотра этапов выполнения. Если нужно исключить что‑то из поиска, можно использовать инверсию или минус в строке фильтра.

Также можно сохранить HAR-файл и передать его разработчику — в нем будет вся история сетевых запросов. Но в HAR попадут только те запросы, которые видны с учетом текущих фильтров.

6️⃣ Как подменять ответ бэка

В DevTools можно изменить ответ запроса и посмотреть, как на него отреагирует интерфейс.

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

7️⃣ Как проверять работу при медленном интернете

DevTools позволяют проверить, как работает интерфейс при плохом соединении. Во вкладке Сеть можно:

  • выбрать готовые профили — 3G, 4G

  • настроить собственную скорость сети

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

8️⃣ Как работать с локальными данными

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

  1. Локальное хранилище — данные, которые сохраняются надолго и не исчезают после перезагрузки страницы.

  2. Сессионное хранилище — данные, которые живут только пока открыта вкладка.

  3. Файлы cookie — похожи на локальное хранилище, но у них есть срок жизни и дополнительные ограничения по источнику.

Все это можно просматривать, изменять и очищать. 

9️⃣ Как менять геолокацию и часовой пояс

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

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

🔟 Как записывать пользовательские сценарии

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

После записи сценарий можно воспроизвести, отредактировать, сохранить и отправить коллегам.

Теги:
Всего голосов 4: ↑3 и ↓1+7
Комментарии0

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

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

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

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

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

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

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

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

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

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

Теги:
Всего голосов 1: ↑1 и ↓0+1
Комментарии0

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

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

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

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

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

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

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

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

Теги:
Всего голосов 5: ↑2 и ↓3+2
Комментарии5

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

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

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

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

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

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

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

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

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

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

Теги:
Рейтинг0
Комментарии0

Ближайшие события

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, время выполнения, стоимость поддержки), а не трендов.

Теги:
Рейтинг0
Комментарии2

Компания 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.

Теги:
Рейтинг0
Комментарии1

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

Впервые в истории писать тесты стало легко и совсем не страшно. Вокруг теперь у всех покрытие 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 — ровно так, как ошибается человек. Или другая нейронка.

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

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

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

Теги:
Всего голосов 5: ↑5 и ↓0+7
Комментарии3

Попадая в подсеть контроллера домена, первое, что делает любой пентестер, это перебор учётных записей пользователей (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 | 📝 Хабр | 💙 ВКонтакте | ⚡️Бустануть канал

Теги:
Всего голосов 3: ↑3 и ↓0+3
Комментарии4

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

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

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

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

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

Теги:
Всего голосов 4: ↑0 и ↓4-4
Комментарии0

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

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

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

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

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

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

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

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

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

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

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

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

Теги:
Всего голосов 7: ↑6 и ↓1+5
Комментарии19

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

Календарь AQA собесов за декабрь
Календарь 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. Всегда рад новым читателям!)

Теги:
Всего голосов 5: ↑1 и ↓4-3
Комментарии35