Обновить
256K+

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

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

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

Привет! На связи 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
1
23 ...