Представлен ресурс для тестировщиков с различными сервисами для автоматизации в одном месте: конверторы, json валидаторы, генераторы uuid и ещё десятки приятных мелочей.
7 открытых уроков для тестировщиков: автоматизируем тесты с умом
30 марта 20:00
Spring Boot Actuator: основы мониторинга и управления приложением
Разберётесь в базовых функциях Spring Boot Actuator и поймёте, как начать использовать его для небольших приложений.1 апреля 19:00
Собеседование с умом: секреты успешного подбора QA-талантов
Погрузимся в секреты успешного подбора талантов, изучим эффективные техники интервьюирования и разберем, как выявить не только технические навыки кандидата, но и его личные качества, которые могут стать залогом успешной работы в QA команде.2 апреля 20:00
Поиск работы JS-автотестером в 2026 году: как выделиться на рынке работодателя
Разберём, как изменилась ситуация на рынке труда для JS-автотестеров в 2026 году и какие стратегии действительно работают при поиске работы. Поговорим о том, как адаптировать резюме под разные рынки, на что обращают внимание HR и технические интервьюеры, и как повысить свои шансы получить оффер.7 апреля 20:00
Модульное (unit) тестирование в 1С
Познакомимся с современными инструментами модульного тестирования. Разберем несколько «неудобных» для тестирования примеров. А также научимся автоматизировать запуск тестов.14 апреля 20:00
Внедрение автотестирования с участием искусственного интеллекта
Этот урок — практическое руководство для тех, кто хочет выстроить устойчивую стратегию авто-тестирования, а не просто «добавить тесты». Мы отдельно разберем, как использовать ии-инструменты в автотестах: где они реально помогают, а где создают иллюзию эффективности.16 апреля 20:00
ИИ для тестировщика: инструменты, которые уже меняют профессию
Разберём, какое место ИИ занимает в работе тестировщика сегодня, какие инструменты действительно помогают ускорять работу и повышать качество, а какие остаются маркетинговым шумом. Узнаем, как ИИ может стать ассистентом QA-инженера в ручном и автоматизированном тестировании.20 апреля 20:00
Модульные (unit) тесты для iOS приложений, работаем над качеством изнутри
Обсудим, какие решения есть в iOS SDK, как их подключить и использовать. Чем различаются Xcode Unit тесты и Swift Testing. Как документировать и сопровождать код приложения с помощью тестов.
Онлайн инструменты для тестировщиков без регистрации и смс
Каждый тестировщик (как мне кажется) каждый день в своей работе использует генераторы uuid, конвертеры, регулярные выражения и json валидаторы. И если у нас нет самописных скриптов, то где то в закладках есть любимый инструмент (обычно разный для каждого из этих действий)
Я решил собрать все в одном месте. Ничего революционного, просто удобно, когда не нужно прыгать по вкладкам. Есть и валидация JSON по схеме, и разбор JWT, и ещё куча мелочей, которые в работе всплывают постоянно.
Ссылка на ресурс: tools.save-link.ru
P. S. может работать как pwa расширение и даже в оффлайне
Мы привыкли воспринимать 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️⃣ Как работать с локальными данными
Во вкладке Приложение можно посмотреть данные, которые браузер сохраняет на стороне пользователя:
Локальное хранилище — данные, которые сохраняются надолго и не исчезают после перезагрузки страницы.
Сессионное хранилище — данные, которые живут только пока открыта вкладка.
Файлы cookie — похожи на локальное хранилище, но у них есть срок жизни и дополнительные ограничения по источнику.
Все это можно просматривать, изменять и очищать.
9️⃣ Как менять геолокацию и часовой пояс
DevTools позволяют изменить геолокацию и часовой пояс, не меняя настройки операционной системы.
Можно выбрать готовую точку или указать координаты вручную. Полезно, когда нужно проверить поведение элементов в другом городе, регионе или стране.
🔟 Как записывать пользовательские сценарии
Инструмент Регистратор умеет записывать действия пользователя на странице — фиксируются шаги, например, клики и переходы по интерфейсу.
После записи сценарий можно воспроизвести, отредактировать, сохранить и отправить коллегам.
Пару лет назад мы с коллегами из 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 года как альтернатива ушедшим с рынка платежным сервисам... Для оплаты нужно посмотреть в камеру, которая распознает изображение лица и сопоставляет его с уникальным номером, привязанным к биометрическим данным. Этот номер также привязан к счету карты. Если данные совпадают, оплата проходит. (с) РБК
Вообще, распознавание лиц в биометрических системах обычно работает как конвейер из нескольких шагов. Верхнеуровнево порядок следующий:
Набор камер получает кадр лица
Алгоритм находит лицо на изображении (рамку вокруг лица)
Система ищет ключевые точки (глаза, нос, уголки рта) и “выравнивает” лицо
Нейросеть преобразует лицо в вектор признаков (эмбеддинг) — набор чисел, который компактно описывает уникальные черты
Дальше считается “близость” двух векторов, например, косинусное сходство или евклидова дистанция: если сходство выше порога, то доступ/оплата разрешена.
Системы безопасности в таких устройствах настроены на защиту от подстановки фотографий, масок, а также добавляют проверки на "человечность". Так, системы анализируют блики и глубину, микродвижения, отражения от ИК-камера (кожа и материалы отражают по-разному); определяют объемность и т.д.
Поэтому, в профессиональных системах биометрии обычно используется нескольких камер:
• обычная 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.
Вайб‑кодинг в тестировании с позиции менеджера
Виктория Дежкина, менеджер направления, поделится плюсами и минусами нового подхода в тестировании: как влияет на команду, какие есть риски и стоит ли вообще пробовать.
