Обновить
256K+

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

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

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

Привет! На связи QA-сообщество 2ГИС. Пробуем ввести новую рубрику — регулярные новости из мира разработки и тестирования. И вот первый дайджест свежих релизов.

PEP 831 — “Build CPython with Frame Pointers by Default”

Новый PEP предлагает включить frame pointers по умолчанию во всех сборках CPython. Это обеспечит корректные стеки вызовов для профайлеров, дебаггеров и eBPF‑трейсинга без необходимости пересобирать Python вручную.

→ https://peps.python.org/pep-0831/

Playwright 1.60

HAR‑запись теперь доступна напрямую через tracing.startHar() / stopHar(), появился locator.drop() для эмуляции drag‑and‑drop, а также новый метод test.abort() для мгновенного прерывания теста.

https://playwright.dev/docs/release-notes#version-160

TestRail 10.3.1

Вернулся тёмный режим, добавлен AI Evaluation Template с дашбордом Quality Insights — теперь можно оценивать качество LLM‑функций не только «проходит/падает», но и по показателям эффективности, безопасности и любым другим метрикам, которые нельзя привести к бинарному результату.

→ https://support.testrail.com/hc/en-us/articles/48316772215956-TestRail-10-3-1-Default-1009

Chrome DevTools 148

Теперь по умолчанию отобржается полное дерево доступности (Full accessibility tree), добавился новый раздел Crash report в Application, в Network появилась новая колока Request order (показывает порядок запросов).

→  https://developer.chrome.com/blog/new-in-devtools-148?hl=en

tox 4.54.0

В релизе добавлен экстра tox[testing] для легкой установки зависимостей плагина tox.pytest, плюс исправлены погрешности в TOML‑схеме для таблиц replace.

→ https://tox.wiki/en/latest/changelog.html#v4-54-0-2026-05-12

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

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

Почему зелёный CI не гарантирует, что система работает

Кейс из QA automation: как миграция на TypeScript привела к скрытому удвоению тестов без единого падения в CI

CI зелёный.

Тесты проходят.

Pull request’ы мерджатся.

Но система уже сломана.

И самое опасное — это не видно ни в логах, ни в отчётах CI.

В большинстве команд CI воспринимается как индикатор здоровья системы:

  • зелёный CI → всё работает

  • красный CI → есть проблема

Это удобная модель. Но она не всегда верна.

Контекст кейса

После миграции проекта с JavaScript на TypeScript мы заметили странное поведение:

  • CI стал выполняться почти в 2 раза дольше

  • тесты не падали

  • ошибок не было

  • метрики оставались “нормальными”

На первый взгляд — ничего критичного.

Что происходило на самом деле

Playwright начал подхватывать одновременно два набора тестов:

  • .spec.js

  • .spec.ts

В результате один и тот же тестовый набор запускался дважды.

Самое неприятное — CI не просто не показывал проблему. Он создавал иллюзию, что всё становится лучше: время выполнения росло постепенно, и это воспринималось как “нормальная деградация после миграции”.

Почему это было незаметно

Проблема усугублялась полным отсутствием сигналов:

  • CI оставался зелёным

  • тесты не фейлились

  • никаких warning’ов

  • никаких алертов

Единственный симптом — увеличение времени выполнения. Которое списали на “ну TypeScript, наверное тяжелее”.

Как проблема была обнаружена

Случайно. Ближе к завершению миграции, при удалении .js файлов, количество тестов внезапно сократилось примерно в два раза:

  • было ~240

  • стало ~120

До этого момента CI фактически выполнял двойную работу — без каких-либо признаков аномалии.

Root cause

Root cause оказался банальным — и именно поэтому его так долго не замечали.

В playwright.config.ts отсутствовал явный testMatch. Playwright по умолчанию подхватывает все файлы, соответствующие glob-паттерну — и .js, и .ts одновременно.

Фикс — одна строка:

testMatch: [‘**/*.spec.ts’]

Но чтобы до неё дойти, нужно было сначала понять, что вообще происходит.

Архитектурный вывод

Большинство проблем в тестовых системах не проявляются как падения.

Они проявляются как:

  • дублирование выполнения

  • скрытая деградация производительности

  • изменения в поведении runner’а без изменений в тестах

И у них нет алертов — потому что мы их не проектируем.

Например, в нашем случае проблему можно было бы поймать простым счётчиком discovered tests в CI.

Финальный вывод

CI — это не инструмент контроля качества системы. Это инструмент контроля того, что тесты не упали.

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

CI отражает только одно: тесты выполнились без явных ошибок.

CI не отражает: тесты запустились правильно, в правильном количестве, с правильными предположениями об окружении.

Если система может быть “зелёной” и при этом работать некорректно — значит у вас есть статус выполнения, но нет наблюдаемости.

Как это выглядит в реальной системе

Именно этот кейс лёг в основу проекта, который я собирала как QA portfolio. В pipeline добавлен счётчик discovered tests: если количество отклоняется от ожидаемого, CI падает явно, а не молчит. Рядом — buggy branch с намеренно сломанной конфигурацией, чтобы можно было воспроизвести и починить самостоятельно.

Код и структура проекта: GitHub (https://github.com/Ariless/clinic-booking-api-tests)

Если собираешь QA портфолио или готовишься к техническому собеседованию — в Telegram-канале Тесты как система (https://t.me/qa_as_a_system) разбираю такие кейсы с кодом и объяснением: что показывать, как объяснять решения, какие находки работают на собеседовании.

Теги:
+2
Комментарии6

Коллеги, у нас на Хабре идет голосование по Veai.

Если вы уже пробовали агент в JetBrains IDE или просто следите за тем, как меняется разработка с AI, загляните и проголосуйте ссылка на голосование Ваше мнение поможет нам понять, что важно разработчикам, и развивать продукт в правильном направлении.

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

Будем рады голосам, комментариям и особенно критике. Она помогает точнее объяснять, чем Veai отличается от чат-ассистента, который не видит проект так, как его видит IDE.

Если у вас есть опыт с Cursor, Continue, JetBrains AI Assistant или другими инструментами, тоже приходите в обсуждение. Нам важны честные сравнения, а не стерильный маркетинговый текст.

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

Тестировщик докапывается — и это не баг, а фича

Тестировщиков иногда упрекают в том, что они всё время сомневаются и докапываются. Но что, если это не особенность характера, а главный профессиональный инструмент?

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

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

🎧 Яндекс Музыка
🔵 VK Видео 
📺 YouTube
Ⓜ️ Mave

Теги:
+13
Комментарии0

Согласно проекту Zero Day ClockLive, с 2018 года значительно сократилось время от выявления уязвимостей в ПО до начала их активной эксплуатации в продуктивных системах (дельта между публичным раскрытием CVE и первым подтверждённым случаем эксплуатации в реальных условиях).

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

Открытый проект SecretScanner помогает парсить пароли, API‑ключи, токены и другие ценные данные из приложений. Сервис проверяет Docker образы и файловую систему, чтобы отыскать секреты. Внутри у каждой программы есть целая база важной инфы — можно почерпнуть множество полезностей.

Теги:
+3
Комментарии0

Что дальше в Пайплайне? Первый выпуск — в эфире!

Мы запустили новый формат: никаких слайдов и скучных докладов.

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

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

Смотреть «Часть 1: QA-версия»

Ещё больше о мероприятиях — в нашем TG-канале.

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

Самое быстрое — «хренак-хренак и в продакшн»: о статическом анализе и скорости выхода продукта

Иногда задают вопрос: "Как статический анализ ускорит Time to market?"

Никак. Статический анализатор не ускорит выход продукта/обновления на рынок. С ним будет дороже и медленнее. Причина — неправильный вопрос.

Аналогично можно спрашивать, как этап тестирования ускоряет Time to market? Точно так же — никак. Тестировщикам мало того, что надо деньги платить, так они ещё будут разработчиков багами отвлекать. Намного быстрее просто написать запускающийся код и выложить дистрибутив. Как говорится, "хренак-хренак и в продакшен". Это самый быстрый вариант.

Но про тестирование, в отличии от статического анализа, такой вопрос не задают. Все понимают, что тестирование — важный элемент создания ПО. Видимо, статический анализ — более молодая методология по сравнению с тестированием, и он просто ещё не стал неотъемлемой частью разработки. Хотя видится очевидным, что и то, и другое неразрывно связано с обеспечением необходимого качества создаваемых программных продуктов.

Какой вопрос правильный?

Как статический анализ ускоряет Time to market при выпуске продуктов заданного уровня качества и надёжности?

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

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

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

P.S. Если понадобится, то есть более формальный и развёрнутый вариант этой сентенции – Статический анализ кода и вывод программных продуктов на рынок.

Теги:
+3
Комментарии0

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

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

Егор, аналитик в Naumen Contact Center, рассказал, как внутри продукта устроено нагрузочное тестирование и почему «запустить тест» — самая простая часть.

1️⃣ Что такое нагрузочное тестирование? 

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

  • количество одновременно работающих операторов

  • нагрузка на входящие и исходящие вызовы

2️⃣ Почему аналитик вообще занимается нагрузочным тестированием?

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

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

3️⃣ Когда нужно проводить нагрузочное тестирование?

Есть несколько типичных ситуаций, когда без него не обойтись:

  • Регулярные проверки перед релизом или после обновления серверов.

  • Тестирование новых фич — если изменения потенциально могут повлиять на производительность.

  • Запросы от клиентов или команды внедрения — когда нужно проверить нагрузку или конфигурацию.

  • Внутренние задачи разработки — когда команде нужно проверить свои решения под нагрузкой.

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

4️⃣ Как принимается решение о проведении тестирования?

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

5️⃣ Как устроен процесс нагрузочного тестирования?

Процесс можно разделить на три этапа:

  1. Первичная аналитика — собираем требования и определяем цель.

  2. Детальная аналитика — описываем сценарии, метрики, инфраструктуру.

  3. Проведение тестов — запускаем тестирование и анализируем результаты.

6️⃣ Почему нагрузочное тестирование требует отдельной инфраструктуры?

Для более-менее реалистичного тестирования недостаточно одного сервера. В нашем случае используются несколько гипервизоров, десятки виртуальных машин, серверы генерации и приема нагрузки, а также инструменты вроде Gatling, JMeter, Grafana и Ansible.

Отдельные компоненты эмулируют работу операторов и клиентов. Например, для проверки нескольких тысяч операторов фактически собирается отдельный контур.

7️⃣ Почему даже короткий тест может занимать полтора часа?

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

8️⃣ Что происходит после тестирования?

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

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

После анализа команда либо фиксирует результаты, либо заводит задачи на доработку сервисов, окружения или инструментов.

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

Бесплатный сервис для базового мониторинга сайта и срока жизни ssl сертификата

SaveTrace
SaveTrace

Что умеет SaveTrace?

- Мониторинг доступности по HTTP/HTTPS для сайтов и API.

- Отслеживание времени отклика, чтобы замечать деградацию до реального падения.

- Контроль SSL-сертификатов и сроков их действия.

- Уведомления о проблемах и история инцидентов в понятном интерфейсе.

Теги:
+7
Комментарии2

Thales опубликовала ежегодный отчёт Bad Bot Report, посвящённый автоматизированной активности в глобальной сети. Главный вывод документа — 53% всего мирового интернет‑трафика по итогам 2025 года пришлось на ботов, тогда как люди сгенерировали лишь 47% запросов. Аналитики компании подчёркивают, что почти 40% общемирового веб‑трафика относится к категории вредоносного и речь идёт не только о примитивных скриптах для подбора паролей или мониторинга цен. Авторы исследования прогнозируют, что в 2026 году интернет окончательно станет средой, где машинное боты и ИИ‑агенты будут доминировать. Это потребует от владельцев цифровых сервисов перехода к модели управления на основе политик: с детальным мониторингом, поведенческим анализом и сегментацией автоматизированной активности по уровню доверия.

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

Ты один QA на проекте? Это твой шанс или риск?

Соло-тестировщик — звучит гордо, но как не утонуть в задачах без онбординга и поддержки? Эксперт Юзтеха на совместном митапе Moscow QA #23 x ИнфоТеКС & Юзтех разобрала типичные сложности и показала, как соло-формат может стать точкой роста, а не дорогой к выгоранию.

Будет полезно, если вы хотите понять, как не выгореть и вырасти.

P.S. Заходите в наш TG-канал, там мы рассказываем о технических мероприятиях и конференциях, делимся выступлениями экспертов, обсуждаем подборки на технические и ИБ темы.

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

Ответственность за качество: почему это не только твоя проблема

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

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

В новом выпуске «Не воспроизводится» Оля Шнайдер и Сережа Атрощенков поговорили о том, как в этой гонке сохранить голову. В гостях — Вася Юдин, тимлид команды, которая делает инструменты для тестировщиков Авито. Обсудили три вещи, о которых в профессиональном контексте говорят редко: почему ответственность за качество — это не груз одного QA, а дело всей команды; как давать и принимать критику, не превращая это в стресс; и стоит ли вообще пытаться вывозить всё в одиночку.

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

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

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

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

Теги:
+28
Комментарии0

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

Если тесты есть, а уверенности в них нет — 10 открытых уроков по тестированию (апрель‑май)

Тестирование в 2026 — это уже давно не только про «проверить, что работает». Это про архитектуру тестов, нагрузку, интеграции и всё чаще — про работу с AI.

Чувствуете, что текущего инструментария уже не хватает (или просто хочется систематизировать практику)? Собрали серию открытых уроков по тестированию — от базовых вещей до более инженерных подходов.

🔥 Что будет:

28 апреля 20:00. «Первый нагрузочный тест в Apache JMeter»
открытый урок курса «Нагрузочное тестирование»

28 апреля 20:00. «Архитектура тестового фреймворка: от хаоса к стабильности»
открытый урок курса «Автоматизатор тестирования на Python»

28 апреля 20:00. «Контрактные тесты в Kotlin: как подружить фронт и бэкэнд»
открытый урок курса «Автоматизатор тестирования на Kotlin»

29 апреля 20:00. «Качество C#‑кода: от модульных тестов к системному подходу»
открытый урок курса «C#-разработчик. Продвинутый уровень»

7 мая 20:00. «Тестирование микросервисов на Go: почему ваш сервис ломается под 1000 RPS»
открытый урок курса «Микросервисы на Go»

19 мая 20:00. «Навыки нагрузочного тестирования и их роль в развитии инженера»
открытый урок курса «Нагрузочное тестирование»

19 мая 20:00. «Введение в OpenTelemetry и основы наблюдаемости»
открытый урок курса «C#-разработчик. Продвинутый уровень»

21 мая 20:00. «Суперсилы Kotlin для удобных UI‑автотестов»
открытый урок курса «Автоматизатор тестирования на Kotlin»

21 мая 20:00. «ИИ как ассистент QA: пишем API‑тесты с нуля»
открытый урок курса «Автоматизатор тестирования на Python»

21 мая 20:00. «API Gateway и не только: шаги к идеальной архитектуре внешних API»
открытый урок курса «Архитектор программного обеспечения»

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

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

📌 Посмотрите каталог курсов по тестированию: там уже не отдельные инструменты, а полноценные треки с практикой, архитектурой и реальными кейсами.

[Перейти в каталог]

Теги:
+3
Комментарии1

📝 Анонс бесплатных открытых уроков на неделю: 27–30 апреля

Привет, коллеги! Традиционная подборка открытых онлайн‑мероприятий для тех, кто хочет прокачать скиллы в IT, управлении, аналитике и автоматизации. На этой неделе — фокус на архитектуру, тестирование, Computer Vision и внутреннюю кухню разработки. Всё бесплатно, но нужна регистрация.

📅 Расписание по дням

Понедельник, 27 апреля

Вторник, 28 апреля

Среда, 29 апреля

Четверг, 30 апреля

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

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

23 апреля: Открытый бесплатный вебинар про ИИ-агенты

Сегодня 23 апреля в 11:00 рассмотрим прикладные сценарии, ограничения и старт внедрения. Разберем примеры разработки и внедрения под задачи тестировщиков, разработчиков, сотрудников непроизводственных направлений (маркетологи, рекрутеры, операционисты). Нужна предварительная регистрация, мероприятие бесплатное. в онлайн формате.

О чем расскажем на вебинаре

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

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

Авторы и спикеры вебинара: 

  • Роман Садрисламов, директор производственного направления, FabricaONE.AI (акционер — Softline)

  • Роман Смирнов, коммерческий директор, FabricaONE.AI (акционер — Softline)

Основной фокус обсуждения

Эксперты покажут опыт компании и заказчиков в трех базовых вопросах:

  • в каких сценариях ИИ-агенты дают измеримый эффект;

  • чем ИИ-агенты отличаются от чат-ботов в прикладных задачах;

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

Среди кейсов:

  1. Снижение ручных операций: сокращение доли рутинных действий в бизнес-процессах.

  2. Ускорение процессов: Использование ИИ-агентов для сокращения времени выполнения задач.
    Работа с информацией и знаниями. По направлениям: поиск информации, работа с корпоративными знаниями в разных отраслях, подготовка ответов и решений на основе доступных данных.

  3. Работа с неструктурированными данными: включая упрощение обработки больших объемов неструктурированной информации.

Бонус: практический блок по кейсу участника

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

Регистрация открыта по ссылке:
https://clck.ru/3T3cYR 


Кому будет особенно полезна встреча

  • руководители бизнеса (CEO, коммерческие директора) — влияние на экономику процессов

  • ИТ-руководители (CIO, CTO) — интеграции, архитектурные и безопасностные ограничения

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

  • руководители цифровизации — выбор пилотных сценариев внедрения

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

Ручное vs автоматизированное тестирование: где заканчивается автоматизация и начинается здравый смысл

Спор между сторонниками ручного тестирования и автоматизации идёт давно — и обычно заходит в тупик. Потому что вопрос «что лучше» изначально поставлен неправильно.

В третьем выпуске «Не воспроизводится» ведущие подкаста Оля Шнайдер и Серёжа Атрощенков отошли от вкусовщины и попробовали разобраться по существу. Когда автотест — это инвестиция, а когда попытка автоматизировать бессмысленность? В каких сценариях ручное тестирование быстрее и точнее? И правда ли, что, уйдя с головой в автотесты, можно потерять связь с реальным пользователем?

Обсудить это пришли Игорь Стародубцев, тестлид в Авито Товарах, и Глеб Дмитриев, старший QA в Распродажах — люди, которые каждый день принимают именно эти решения.


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

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

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

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

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

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

Выяснилось, что всё довольно прозаично: красный — это KL.30, чёрный — земля, а белый — тот самый загадочный третий провод, который раньше вызывал больше всего вопросов. Им оказался KL.15 — не просто «ещё один плюс», а линия, на которую питание подаётся только при включённом зажигании. То есть, в отличие от постоянного питания на KL.30, этот провод живёт своей жизнью: есть зажигание — есть питание, нет зажигания — тишина: всё, что не должно сажать аккумулятор на стоянке, вешается именно туда.

В ходе изучения устройства я долго пытался понять, как же оно осуществляет связь с оператором: где GSM сим-карта или тут все по новомодной технологии Mesh? :) Ну или мне стоит искать дополнительный модуль связи где-то у себя под задним сидением? Но нет — всё оказалось куда компактнее. Если верить документации на УВЭОС, внутри вполне взрослый набор: GSM, UMTS и LTE в нескольких диапазонах, а тип SIM-карты – резидентная (несъемная) многопрофильная SIM-карта, установленная на печатную плату по SMD-технологии.

И действительно, если присмотреться, то “симка” у нас в форм-факторе WSON 8, и даже обведена соответственно. Поэтому, одним из следующих шагов может быть ее выпаивание и установка в полнофункциональный мобильный аппарат: узнать оператора связи, номер телефона, есть ли безлимитный интернет и звонки на отличные от экстренных служб номера.
А то кто знает… ну вы поняли ;)

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

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

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

Я знаю, что ничего не знаю (с) Сократ

Казалось бы, уже более 7 лет я провожу аудиты безопасности и тестирование на проникновение. NMap, если и не затерт до дыр, то бодрый десяток команд уже настолько забетонирован на подкорке мозга, что если меня разбудить ночью и попросить составить запрос на сканирование 20-й подсети с отображением версий сервисов, с последующим применением к ним скриптов, с максимальным отображением вывода и последующей записи лога в формат grep’а, то я продиктую команду даже не разомкнув глаз.

Однако воистину: век живи - век учись! На одном из последних проектов, в котором я принимал участие со стороны “синих”, случилась интересная аномалия: все принтеры организации поверили в SkyNet и начали неистово печатать какую-то абракадабру. И я не говорю про 1-2 листка - это было тотальное истощение ресурсов: 1 строка на 1 листе, а таких листков около сотни. И даже очищение кэша через физическое отключение 220 не помогло. В общем, на полдня компания реально “встала”. Что же произошло?

В ходе изучения текста напечатанных “документов” мы с командой выявили, что все запросы на принтеры шли на порт 9100. Порт 9100/TCP является стандартным портом прямой печати Raw и часто называется JetDirect или RAW-печать. Он позволяет сетевому устройству отправлять задание на печать напрямую в буфер принтера без использования дополнительных протоколов, шифрования и авторизации.

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

После локализации проблемы и восстановления работоспособности парка техники я начал разбираться, почему за всю мою ИБэшную карьеру у меня такого никогда не случалось, ведь я сканирую сети практически каждый день? Так вот, если мы внимательно прочитаем документацию к приложению, мы узнаем, что у NMap есть исключения (так называемые Exclude Directive), в которые по умолчанию включены порты 9100-9107. Как вы можете понять, исключены они как раз по той причине, чтобы принтеры не тратили тонны бумаги на каждую проверку сканера. В общем, хорошее откровение.

П.С. Когда я собеседую кандидатов на вакантные должности, я внимательно изучаю резюме и стараюсь задать вопросы исключительно по нему (и на половину вопросов мне не могут ответить)). И когда я вижу в секции скилы “NMap”, я люблю задавать вопрос, как программа определяет, что порт на хосте открыт, закрыт или зафильтрован. Теперь у меня будет второй добивающе-контрольный вопрос: сканирование каких портов по умолчанию не производится и требует явного указания?

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

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

Инструкция по отключению в Windows 11 процесса NDU (Network Diagnostic Usage), который не несёт ничего полезного и нужен только для того, чтобы в Microsoft мониторили подключение ПК.

Как отключить эту опцию:

  • Win+R → regedit.

  • Заходим в директорию: Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Ndu

  • Меняем значение «Start» на «4».

  • Перезагружаем ПК.

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

Уронить прод специально: безумие или отвага?

Есть инженеры, которые боятся инцидентов. А есть те, кто устраивает их самостоятельно — по расписанию, с тикетом в Jira и полным пониманием того, что сейчас случится. Chaos Engineering — это не баг в процессах, а фича. Только вот объяснить это менеджеру, когда прод лежит намеренно — всё равно непросто.

Вместе с Дмитрием Баскаковым, Head of Platform в MindBox, разбираемся, что на самом деле стоит за этим методом — и почему компании, которые регулярно что-нибудь ломают, в итоге падают реже остальных.

Что на повестке

Chaos Engineering звучит красиво, но практика гораздо прозаичнее: нужна культура, нужны SLO, нужно понимать, что именно вы тестируете — систему или людей. В выпуске обсуждаем, чем хаос-тесты отличаются от нагрузочного тестирования, кто принимает решение «ломать» и кто за это отвечает, почему без blameless-культуры всё это превращается в поиск виноватых — и есть ли у хаос-инженерии реальный ROI или это дорогостоящее развлечение для зрелых команд.

Отдельно поговорили про выгорание: добавляет ли плановый хаос тревожности инженерам — или, наоборот, снимает её.

Если вы хоть раз думали «у нас и так всё нестабильно, зачем ещё специально ломать» — этот выпуск именно про вас.

Слушайте и смотрите на площадках

И подписывайтесь на телеграм-канал Avito SREда

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

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

ИИ пришёл в 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
1
23 ...