Как собрать тестовый стенд, если опыта нет, а железо разное?
IP-камеры, роутеры, одноплатники — и всё это нужно подружить в одном стенде. Эксперт ИнфоТеКС на QA-days рассказал, через что ему пришлось пройти, пересобирая стенд с нуля. Трудности, подводные камни и отсутствие опыта на входе.
P.S. В нашем TG-канал рассказываем о технических мероприятиях и конференциях, делимся выступлениями экспертов, обсуждаем подборки на технические и ИБ темы.
Все что нужно знать QA-специалистам: сводка новостей за весну и лето 2026
Наш QA-комитет держит руку на пульсе — читает отчеты, изучает кейсы и копается в обсуждениях, чтобы вы могли заниматься более важными вещами. Забирайте выжимку всего, что стоит внимания.
📊 Рынок
Вышло крупное исследование Tricentis 2026 Quality Transformation Report: опросили 2 501 ИТ- и QA-руководителей из шести стран. 93% руководителей C-level уверены в своей стратегии тестирования, в то время как 30% руководителей QA и DevOps такой уверенности не испытывают. Доверие к ИИ-агентам упало с 48% до 34% за год.
Короче: скорость выхода ПО растет, но уверенность в его качестве падает из-за перегруженности инструментарием и невозможности перепроверить все за ИИ. Сейчас самое узкое место — валидация автотестов и подсчет реального покрытия, около 60% компаний выпускают непротестированный код в прод и теряют миллионы долларов.
Во многих источниках отмечают следующие тренды: shift-left подход к разработке ПО, плотная работа QA c data-специалистами и фокус на стратегии качества, а не на наращивании числа автотестов.
🔧 Интересные материалы на Хабре
В блоге Росгосстраха вышел целый цикл статей про применение LLM в тестировании. Начать лучше с этой статьи — про подготовку контекста для LLM: как структурировать требования, парсить PDF из Confluence, работать с макетами и диаграммами.
ВкусВилл рассказали, как превратили Swagger из документации в двигатель API-автотестов: OpenAPI Generator генерирует Java-клиенты и модели, swagger-coverage считает реальное покрытие по контракту, а LLM-скиллы по JSON-отчету сами предлагают, какие тесты дописать.
В Telegram-сообществах в последнее время гремит Playwright как наиболее перспективный фреймворк для автоматизации. Вот тут один автор решил проверить, не маркетинг ли это: собрал все свежие бенчмарки Playwright vs Selenium vs Cypress vs WebdriverIO, сравнил методологию и выяснил, что большинство цифр просто несопоставимы. Вывод: единственный процент, которому можно доверять — тот, что вы сами намерили на своем проекте.
🤖Про агентов
СВОЙ Тех описали свою архитектуру ИИ-агентов в автоматизации. Там сложный 12-актовый воркфлоу, но и результат интересный: агент анализирует собственные ошибки и обновляет конфигурацию. Можно взять как шаблон для построения агентного фреймворка.
Вот тут автор описывает, как собрал систему из 11 узкоспециализированных ИИ-скиллов, которая по Jira-ссылке сама генерирует тест-кейсы, пишет автотесты, загружает их в Zephyr и создает merge request. Можно адаптировать под свой стек.
Если вы еще не писали свой первый QA-скилл, рекомендуем почитать большой разбор от Битрикса, чем скилл отличается от RAG, Tools и MCP. Дает полное понимание архитектуры и поможет избежать ошибок новичка при написании кастомных скиллов.
💼 Для карьеры
ISTQB выпустила обновленную версию сертификации Certified Tester AI Testing (CT‑AI) v2.0, что де-факто означает появление общепризнанного стандарта использования ИИ в тестировании и тестирования самих ИИ-систем. Кому актуально, можно получить сертификат и использовать его как аргумент в переговорах с HR.
Еще нашли бесплатный 100-страничный учебник по тестированию — удобно учиться самим и использовать для онбординга.
Вот список крупных европейских и отечественных мероприятий по разработке и тестированию.
Ну и открытая вакансия Fullstack QA у нас в Cloud.ru.
👉Подписывайтесь, будем вместе повышать качество своего ПО и разбираться, чем полезны ИИ и агентные системы.
ИИ для Университета 4.0, а «Королев ИИ» для МГТУ им. Н.Э. Баумана
Ключевой вызов для любого вуза, стремящегося к лидерству, — это не просто автоматизировать отдельные процессы, а создать единую «нервную систему», которая пронизывает все сферы деятельности: от образования и науки до управления и работы с талантами. Именно такую задачу мы ставим перед собой в МГТУ им. Н.Э. Баумана, разрабатывая научно-образовательную платформу «Королев ИИ».
Эта платформа — не просто набор модных чат-ботов. Это многоуровневая архитектурная среда, которая агрегирует и семантически обогащает данные, развёртывает специализированные сервисы на основе больших языковых моделей (LLM) и предоставляет единые интерфейсы для студентов, преподавателей, учёных и сотрудников. По сути, мы создаём «интеллектуальное ядро» цифровой экосистемы Университета 4.0.
«Королев ИИ»: архитектура будущего
В основе платформы лежит трехуровневая архитектура, которая обеспечивает её масштабируемость и адаптивность.
1. Уровень сбора и агрегации данных. Здесь формируется цифровой профиль каждого участника образовательного процесса. Это не просто сухие данные об успеваемости, а глубокий семантический анализ: тексты работ, участие в проектах, интересы и даже стиль мышления. LLM анализируют этот массив, выявляя латентные характеристики и создавая многомерный портрет человека.
2. Уровень интеллектуальных сервисов. Это «фабрика моделей» и «озеро научных знаний». Здесь развёртываются специализированные LLM-сервисы: от генерации персонализированных образовательных траекторий и адаптивного контента до интеллектуальной поддержки научных исследований и автоматизации управленческих процессов. Мы протестировали более 30 больших языковых моделей и создали первый рабочий прототип ИИ-ассистента, который понимает голос, обрабатывает запрос и даёт ответ естественным голосом.
3. Уровень взаимодействия. Это единая точка входа для всех пользователей. Студент получает персонализированного наставника, преподаватель — ассистента для автоматизации рутины, а учёный — инструмент для ускорения исследований.
Платформа «Королев ИИ» — это инструмент для достижения стратегических целей Программы развития МГТУ до 2030 года. Вот лишь несколько примеров того, как LLM меняют привычные процессы:
Образование. Мы решаем фундаментальную проблему «масштабируемой персонализации». ИИ-ассистент работает 24/7, помогая каждому из тысяч студентов осваивать материал в комфортном темпе. Платформа «Путь инженера» позволяет выявлять талантливых школьников и сопровождать их на всём пути: «школа — университет — индустрия».
Наука и инновации. LLM становятся катализатором продуктивности учёного. Сервисы семантического поиска, генерации гипотез и кода, поддержки публикационной активности помогают увеличить объём НИОКР и повысить количество публикаций в ведущих журналах. Мы создаём «озеро научных знаний», которое позволяет капитализировать интеллектуальный потенциал научных школ.
Управление и кадры. Интеллектуальная автоматизация документооборота, прогнозная аналитика и ИИ-агенты для консультирования сотрудников помогают сократить долю административного персонала при одновременном повышении качества сервисов.
Доверенный и этичный ИИ
Мы понимаем, что внедрение ИИ несёт не только возможности, но и риски. Поэтому этика — не внешнее ограничение, а внутренний принцип проектирования. В архитектуру каждого сервиса мы встраиваем механизмы объяснимости, аудита и защиты персональных данных.
Что дальше?
Мы уже прошли путь от идеи до действующего прототипа. Впереди — масштабирование, интеграция с отечественными программно-аппаратными комплексами и тиражирование нашего опыта. «Королев ИИ» — это не просто проект. Это прообраз новой операционной модели технического университета эпохи экономики данных, где технологии работают на человека, расширяя его творческие и когнитивные возможности.
Тестирование в 2026: API, UX, QA Lead и ИИ
Тестирование давно перестало быть просто поиском багов. Сегодня QA‑инженеру важно разбираться в автоматизации, пользовательском опыте, метриках команды и понимать, как ИИ меняет профессию.
Собрали ближайшие открытые уроки для тестировщиков и QA Lead, которые помогут прокачать практические навыки и посмотреть на развитие карьеры под новым углом.
30 июня, 20:00. Тестирование UX для мобильных приложений: чек‑лист по основным проверкам. Записаться
Разберем, на что смотреть при проверке мобильного UX: сценарии, интерфейс, ошибки взаимодействия и типовые проблемы, которые влияют на пользовательский опыт.
30 июня, 20:00. Gitlab CI как конструктор workflow. Записаться
Покажем, как устроены workflow в GitLab CI и как автоматизация сборок помогает быстрее проверять изменения в проекте.
2 июля, 20:00. От API до экрана: создаём Android‑приложение на рекомендуемой архитектуре. Записаться
Полезно для QA, которые тестируют мобильные приложения и хотят лучше понимать, как связаны API, логика приложения и пользовательский интерфейс.
2 июля, 20:00. REST Assured & JSON Schema Validator: автоматизация тестирования API на практике. Записаться
Разберем практический подход к автоматизации API‑тестов на Java: проверки ответов, схем данных и стабильности интеграций.
7 июля, 19:00. Как читать баги: метрики для руководителей команд тестирования (QA Lead). Записаться
Поговорим о метриках дефектов, качестве баг‑репортов и том, как QA Lead может видеть реальные проблемы процесса, а не просто количество задач.
14 июля, 20:00. Развитие команды без найма: инструменты наставничества для QA Lead. Записаться
Разберем, как усиливать QA‑команду через наставничество, внутренний рост и передачу экспертизы без расширения штата.
16 июля, 20:00. Профессия тестировщика в эпоху ИИ — угроза потери работы или суперсила? Записаться
Обсудим, как ИИ меняет работу тестировщика, какие задачи можно усилить с помощью инструментов и какие навыки останутся критичными.
21 июля, 20:00. UI и API тестирование с Java и Playwright. Записаться
Покажем, как объединять UI‑ и API‑проверки в автотестах и использовать Java и Playwright для более устойчивого тестового покрытия.
21 июля, 20:00. Оценка трудозатрат в QA: как перестать ошибаться в сроках. Записаться
Разберем, как QA оценивать задачи точнее, учитывать риски, сложность проверок и не попадать в ловушку заниженных сроков.
23 июля, 20:00. Тестирование интернет‑магазина (eCommerce): от каталога до оплаты. Записаться
Покажем, какие сценарии критичны при проверке eCommerce: каталог, карточки товаров, корзина, оформление заказа, оплата и ошибки на пути пользователя.
Больше уроков по тестированию, разработке, искусственному интеллекту и не только смотрите в дайджесте.
Пока выбираете урок, обратите внимание на материалы по тестированию:
Как тестировать связку продуктов, не сойдя с ума?
В этом докладе рассказали, как выстроить «танец команд»: от smoke-планов до совместной стратегии развития. Обмен экспертизой, интеграционные кейсы и живые воркшопы — всё, чтобы совместимость не хромала.
Ещё больше о мероприятиях — в нашем TG-канале.
РБПО по ГОСТ Р 56939—2024: вебинар №24 из 30 — Поиск уязвимостей в программном обеспечении при эксплуатации
Предлагаю вашему вниманию запись вебинара, где мы разбираем безопасную разработку ПО. Вебинар посвящен процессу из раздела 5.24. – "Поиск уязвимостей в программном обеспечении при эксплуатации". На YouTube. Слайды.
Цели 24-го процесса по ГОСТ Р 56939—2024:
Организация систематического и углублённого поиска ошибок и уязвимостей в ПО при его эксплуатации в целях упреждающего реагирования: обработки ошибок кода ПО и его конфигураций (настроек) до того, как они будут выявлены сторонними лицами и повлекут инциденты информационной безопасности.
Общее количество вебинаров — 30. Каждому из 25 процессов ГОСТа посвящён отдельный вебинар и ещё 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.
Методика ВУ и НДВ в ПО приведена в соответствие с ГОСТ Р 56939—2024
Материалы будут полезны всем, кто знакомится с темой РБПО и заинтересован во внедрении зрелых подходов в работу по созданию и сопровождению качественных программных продуктов. Материал по ГОСТ Р 56939—2024 весьма актуален, так как 12 мая 2026 утверждена обновлённая "Методика ВУ и НДВ в ПО". См. заметку "Методика выявления уязвимостей и недекларированных возможностей — 2026".
НЕкурс про РБПО
Суммарное время предлагаемых к изучению вебинаров составляет около 50 часов. Это достаточно большая задача, поэтому мы решили помочь и разбили материалы на отдельные уроки по РБПО. Возможно, так вам будет проще усваивать материал, а интерфейс позволяет отмечать, с чем вы уже ознакомились.
Тестовое задание для тестировщика AI-приложений
Ранее меня просили рассказать про subj. Итак, домашнее задание по оценке навыков ML Evaluation Engineer: как оно выглядит и чего ожидают работодатели?
Сценарий тестового задания: Приложение для медицинских консультаций получает шквал жалоб от пользователей, хотя внутренняя модель анализа настроений (sentiment model) по-прежнему рапортует о высокой «глобальной точности» (Global Accuracy). Ваша миссия: найти «слепые зоны», которые скрывают метрики.
Данные: 1000 пользовательских отзывов (в формате JSON), содержащих эталонные значения (ground truth), предсказания модели и показатели уверенности (confidence scores).
Что ожидается в качестве результата?
Просто показать навыки кодинга недостаточно. В Evaluation главное – это ответ на вопрос «Ну и что?».
Структурированный аудит: Текстовое объяснение того, где именно находятся слепые зоны, подкрепленное цифрами.
Визуальные доказательства: Калибровочные кривые (Calibration Curves) и матрицы ошибок (Confusion Matrices), которые покажут, почему старые метрики пропустили провалы.
Какими навыками нужно обладать?
Чтобы блеснуть, вам понадобится «гибридный» профиль:
Теоретическая база: Понимание того, как именно модели ошибаются, и какие метрики применимы к конкретным edge cases.
Интуиция данных: Способность искать пробелы как вручную, так и автоматически.
Инженерная строгость: Навыки работы с Python для создания пайплайнов и внедрения LLM-as-a-Judge.
Стратегическая коммуникация: Умение излагать выводы структурированно, точно и грамотно.
Давайте разберем выполнение этой гипотетической задачи по фазам:
Фаза 1: «Детектив» (Анализ данных)
Прежде чем писать хоть одну строчку кода, нужно провести аудит распределения данных:
Проверка дисбаланса классов: Если «позитивных» отзывов в 10 раз больше, чем «негативных», ваша метрика Accuracy вам нагло врет.
Поиск предвзятости (bias): Не падает ли качество модели на специфических срезах (например, медицинский жаргон против разговорного языка)?
Критика статус-кво: Почему старая «глобальная точность» подвела? Сравните её с метриками, которые реально важны для несбалансированных данных.
Фаза 2: «Архитектор» (Реализация)
Теперь строим фреймворк для оценки:
Python-архитектура: Используйте чистый, модульный код. Будь то Scikit-learn или Pandas, покажите, что вы заботитесь о поддерживаемости.
LLM-as-a-Judge vs. метрики: Решите, где нужны статистические библиотеки, а где не обойтись без LLM, чтобы «рассудить» нюансы сарказма или сложного медицинского контекста.
Уверенность vs. Правильность: Напишите проверку на «уверенно неверные» (Confidently Incorrect) предсказания. Это ваши самые высокорисковые ошибки.
Фаза 3: «Стратег» (Отчетность)
Работа Eval-инженера – это на 20% получение цифр и на 80% объяснение того, что они значат.
Визуализация: Приложите калибровочные кривые и матрицы ошибок.
Бриф по «слепым зонам»: Структурируйте выводы. Где именно пробел? Модель пропускает «негатив», потому что там используются сложные термины? Объясните, почему старые метрики проглядели эти критические сбои.
Совет кандидатам
Работодатели в сфере ML Eval ищут не «Data Scientist Lite», а инженеров по качеству и надежности. В вашем GitHub должны быть не просто .py файлы, а README, который рассказывает историю рисков и их минимизации.
Это перевод моего англоязычного поста A take-home assignment for an AI QA role (другие переводы)
TXORDER-01: 7 тестов прошли, 8-й нашёл баг
Как domain state в одном тесте сделал видимым баг в порядке операций внутри транзакции — и что это говорит о том, что на самом деле проверяют “зелёные тесты”
7 тестов прошли.
8-й нашёл баг в production flow.
Не потому что был написан лучше. Потому что запустился с другим начальным состоянием системы.
Операция и транзакция
PATCH /reschedule — перенос appointment пациента на другой слот. Атомарная транзакция: освободить старый слот, занять новый, переместить запись. Плюс promoteFromWaitlist: если на освобождённом слоте есть очередь, первый из неё автоматически получает appointment.
Порядок операций в транзакции:
free_old_slot(slot1)
promoteFromWaitlist(slot1)
book_new_slot(slot2)
move_appointment(appointment → slot2)
Почему 7 тестов ничего не нашли
Тесты 1–7 проверяли стандартные сценарии: перенести pending, перенести confirmed, попытаться перенести на занятый слот. Ни в одном из них не было пациента в вейтлисте.promoteFromWaitlist в каждом тесте — no-op. Очередь пуста, функция вызывалась, ничего не делала, возвращала успех. Это важная деталь: функция не падала. Она просто не активировалась. Порядок операций вокруг неё не имел значения — потому что одна из операций ничего не делала.
7 зелёных тестов говорили: reschedule работает корректно. На самом деле они говорили: reschedule работает корректно когда вейтлист пуст.
Что нашёл 8-й тест
Пациент 2 встал в очередь на slot1. Пациент 1 запустил reschedule на slot2.
Ответ: 409 SLOT_IN_USE.
Слот был свободен. Пациент имел право переноса. Транзакция откатилась.
Механизм
free_old_slot(slot1) ← слот доступен
promoteFromWaitlist(slot1) ← пациент 2 получил pending на slot1
book_new_slot(slot2)
move_appointment → slot2 ← appointment пациента 1 ещё на slot1
После шага 2 на slot1 два active appointment одновременно: пациента 1 (ещё не переехал) и пациента 2 (только что из промоушна). UNIQUE constraint one_active_per_slot. Откат. 409.
Транзакция дисциплинированно выполняла логически неверную последовательность — и откатывалась на constraint.
Фикс
Appointment должен покинуть slot1 до того как promote вставляет нового пациента:
book_new_slot(slot2)
move_appointment → slot2
free_old_slot(slot1)
promoteFromWaitlist(slot1)
8-й тест прошёл
Что означают 7 зелёных тестов
Тест проверяет поведение системы при конкретном начальном состоянии. Если в наборе тестов нет нужного domain state — класс ошибок невидим, сколько бы тестов ни прошло.
В данном случае критическое условие — пациент в вейтлисте — отсутствовало во всех семи тестах. promoteFromWaitlist` был no-op в каждом из них. Баг в порядке операций существовал с момента написания — просто не было состояния которое его активировало.
Атомарность транзакции гарантирует: либо все операции выполнятся, либо ни одна. Она не гарантирует что операции написаны в правильном порядке. Это разные гарантии — и мы путали их семь тестов подряд.
Скрытое предположение “Я решилf что если транзакция атомарна — порядок операций внутри неё можно не тестировать. На самом деле транзакция защищает от частичных обновлений, но не от логически неверного порядка внутри.”
Код проекта: GitHub
Из серии “Тихие отказы в тест-автоматизации” Разборы таких кейсов — в Telegram-канале Тесты как система
Как построить фронтенд-тесты от перехвата payload до кастомных отчётов?
В этом докладе — полный путь: выбор инструментов (Playwright + TypeScript), первые тесты, внедрение в CI/CD и расчёты покрытия. Без воды, только практика и реальные боли, с которыми столкнулись и которые решили.
P.S. В нашем TG-канал рассказываем о технических мероприятиях и конференциях, делимся выступлениями экспертов, обсуждаем подборки на технические и ИБ темы.
Рутина убивает? А если её возглавить?
Эксперт ИнфоТеКС на совместном митапе Moscow QA #23 x ИнфоТеКС & Юзтех представил методику двойной матрицы рисков: как оценить рутинные процессы, не выгореть и понять, что автоматизировать, а что оставить.
Доклад будет полезен, если ты устаёшь от бесконечной рутины, но не знаешь, с чего начать её оптимизацию и как сохранить себя и команду.
Ещё больше о мероприятиях — в нашем TG-канале.
Почему тесты проходят, но система всё равно сломана
Классы скрытых ошибок в QA automation, которые не приводят к падению CI
Пайплайн прошёл. Логи без ошибок. Значит всё работает.
Но в реальных QA automation системах это предположение часто не выдерживает проверки.
Тесты могут проходить, даже если система сломана.
И это не редкий edge case. Есть несколько типов проблем, которые не приводят к падению CI:
False positives — тест подтверждает поведение, которое уже не соответствует бизнес‑логике. Проверка формально зелёная, смысл потерян.
Missing assertions — тест проходит, потому что не проверяет ничего критичного.
Flaky suppression — флаки ретраят или игнорируют. Шум скрывает реальные проблемы, CI выглядит стабильным.
Duplicated execution — один и тот же набор тестов запускается несколько раз из‑за конфигурации runner'а.
Contract drift — API или поведение системы меняется, но тесты продолжают проверять старые ожидания. Пока не появится явный конфликт — всё зелёное.
В проекте была добавлена пагинация к одному из API эндпоинтов. До изменения ответ выглядел так:
json [{ "id": 1 }, { "id": 2 }]
После — так:
{ "data": [...], "total": 10, "page": 1, "limit": 20 }
API тесты не упали: они проверяли статус и структуру нового формата — всё корректно.
Я была уверена что если API возвращает 200 и схема верна — клиент получает данные.
Но в клиентском коде была строка:
cachedRows = Array.isArray(rows) ? rows : []
Для объекта Array.isArray возвращает false. Список записей стал пустым.
Формально всё работало корректно. Просто данных больше не было.Никаких ошибок в консоли. Никакого 500. Просто пустая страница.
CI остался зелёным — потому что API тесты проверяли API, а не то, как клиент использует ответ.
Дальше сработал каскад: fixture teardown тоже вызывал этот эндпоинт, получал объект вместо массива, не чистил данные — и следующие тесты падали с совершенно другой ошибкой, в совершенно другом файле.
Три теста упали из-за одного изменения shape ответа.
Ни один из них не указал на настоящую причину.
Почему CI это не ловит
CI отвечает на вопрос: «выполнились ли тесты без ошибок?»
Но не отвечает на: «имеют ли тесты смысл относительно текущей системы?»
CI реагирует только на падения. Он не знает про бизнес-инварианты, не отслеживает правильность выполнения и не видит contract drift.
Что с этим делают в зрелых системах
Начинают появляться дополнительные слои:
контрактные тесты (contract testing) — фиксируют ожидания потребителя API
явно наблюдаемость тестов — метрики не как %, а как сигналы поведения
контроль изменений API через diff-инструменты
Ни один из них не заменяет хорошие тесты. Но каждый закрывает слепое пятно, которое тесты не видят.
Финальный вывод
Тесты не доказывают, что система работает.
Они только доказывают, что система не сломалась определённым способом.
Признаки сбоя
CI зелёный
UI показывает пустой список
API возвращает 200
fixture teardown не чистил данные, занимал слот
Скрытое предположение
«Я решила что статус 200 означает, что потребитель по‑прежнему правильно читает ответ»
Как это выглядит в реальной системе
Contract drift — один из тех классов ошибок, которые можно воспроизвести намеренно. В проекте есть buggy branch именно с этим кейсом: API возвращает изменённый shape ответа, все API тесты зелёные, но клиентский код получает пустой список — без ошибок, без 500, просто тишина.
Код и структура проекта: GitHub
Из серии «Тихие отказы в тест-автоматизации»
Разборы таких кейсов с кодом — в Telegram-канале Тесты как система
РБПО по ГОСТ Р 56939—2024: вебинар №19 из 30 — Нефункциональное тестирование
Предлагаю вашему вниманию запись вебинара, где мы разбираем безопасную разработку ПО. Вебинар посвящен процессу из раздела 5.19. – "Нефункциональное тестирование". На YouTube. Слайды.
Цели 19-го процесса по ГОСТ Р 56939—2024:
Подтверждение того, что поверхность атаки, модель угроз и архитектура ПО содержат необходимую информацию.
Обнаружение недостатков программы путём выполнения нефункциональных тестов, в том числе имитирующих действия потенциального нарушителя.
Общее количество вебинаров — 30. Каждому из 25 процессов ГОСТа посвящён отдельный вебинар и ещё 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.
Цикл вебинаров проведён компанией ООО "ПВС" совместно с учебным центром "Маском". Организаторами выступили Андрей Карпов и Виталий Пиков. Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.
P.S.
Суммарное время предлагаемых к изучению вебинаров составляет около 50 часов. Их можно смотреть на ускорении. Однако даже в этом случае с учётом дополнительных материалов и отсылок на внешние ресурсы изучение займёт около двух рабочих недель.
Это достаточно большая задача, поэтому мы решили помочь и разбили материалы на отдельные уроки. Так будет проще усваивать материал, а интерфейс позволяет отмечать, с чем вы уже познакомились.
Подробнее: НЕкурс про разработку безопасного программного обеспечения (РБПО).
Как профессиональное сообщество помогает расти — и почему это не про нетворкинг
Первый сезон «Не воспроизводится» заканчивается — и последний выпуск мы решили посвятить не багам и процессам, а людям.
QA часто воспринимают как профессию для одиночек. Но самые важные открытия в карьере случаются не в одиночестве, а рядом с другими. В финальном эпизоде Оля Шнайдер и Сережа Атрощенков поговорили с Юлей Трусовой, QA в BDUI и организатором QA Community в Авито, о том, зачем тестировщику вкладывать время в профессиональные сообщества. Юля не только развивает комьюнити внутри компании, но и победила в Технотексте-8 Хабра со статьёй именно на эту тему — так что разговор получился особенно предметным.
Обсудили, чем живые встречи комьюнити отличаются от конференций, можно ли приносить туда нерабочие проблемы — спойлер: можно, и даже нужно — и как участие в сообществе помогает расти в карьере, не дожидаясь, пока кто-то сверху заметит твою экспертизу.
🎧 Слушайте выпуск подкаста на всех подкаст-платформах:
Обсуждение тем, тренды в QA и, конечно, мемы — в Telegram-канале «Не воспроизводится».
Добро пожаловать в мир тестирования. Баги прилагаются.
Ещё больше экспертизы собрали для вас на сайте: смотрите наши лонгриды, новости, и видео. А узнать, как стать частью команды AvitoTech, можно вот здесь.
Один день тестировщика AI-приложений (разумеется, без нарушения NDA!)
09:30 – 10:30 Смена архитектуры
Начала день с синка по нашему агентскому воркфлоу (agentic workflow). Команда разработки представила нового агента.
Задача: мне нужно убедиться, что появление нового агента не повлияло на качество системы. Предстоит сравнить старую версию системы с новой.
11:00 – 12:00 Споры о метриках
Встретились с ML-командой, чтобы решить, как мы будем оценивать этого красавца. Мы уже выходим за рамки простой точности (accuracy).
Итог: остановились на Faithfulness (отсутствие галлюцинаций) и Efficiency (не делает ли агент 10 шагов там, где достаточно двух?).
12:00 – 14:00 Python
Пора приступать. Добавляю метрики в пайплайн с помощью Python-библиотек или подхода LLM-as-a-Judge — посмотрим, что сработает лучше. Здесь я работаю напрямую с кодом проекта, а не с AQA-кодом. И должна признать: это на порядок сложнее того, к чему я привыкла. AQA-код обычно базируется на отдельных фреймворках типа Selenium, его проще понять и написать. Так что изначально для меня это был серьезный вызов.
14:00 – Обед!
15:00 – 16:00 Посмотрим свежим взглядом
Финальный взгляд на код, прогон юнит-тестов (чтобы убедиться, что я ничего не сломала) и пуш на ревью.
(Представим, что коллеги поревьюили мой код сразу же после пуша :)). Прилетела пара комментов по поводу edge cases для неанглийских запросов.
16:30 – 17:30 Фикс
Доработала логику, закрыла комментарии и получила то самое заветное «LGTM». Мердж в main!
17:30 – 18:30 Запуск пайплайна оценки
(Идея в том, чтобы сравнить старую и новую версии системы на заранее подготовленных данных).
Прогоняю новый набор тестов на обеих версиях на разных датасетах. Чтобы учесть фактор недетерминированности, каждый прогон делаю несколько раз. При первичном анализе наткнулась на странность: новая версия «ест» меньше токенов, но работает дольше. Пытаюсь понять, в чем подвох.
18:30 – 19:00 Отчеты
Завершаю день презентацией Evaluation-отчета команде. Обсуждаем результаты в чате.
это перевод моего англоязычного поста Working day of AI QA engineer (другие переводы)
FixProtocol: как тестировать то, о чём мало кто слышал?
Эксперт B2Broker на совместном митапе Moscow QA #23 x ИнфоТеКС & Юзтех рассказал, с какими неочевидными сложностями столкнулась его команда при работе с FixProtocol и как они нашли выход. Без скучной теории — только реальный кейс и рабочие решения.
Сталкиваешься с редкими или непопулярными протоколами и ищешь подходы к их тестированию без готовых решений? Этот доклад точно будет полезен тебе.
P.S. В нашем TG-канал рассказываем о технических мероприятиях и конференциях, делимся выступлениями экспертов, обсуждаем подборки на технические и ИБ темы.
РБПО по ГОСТ Р 56939—2024: вебинар №18 из 30 — Функциональное тестирование
Предлагаю вашему вниманию запись вебинара, где мы разбираем безопасную разработку ПО. Вебинар посвящен процессу из раздела 5.18. – "Функциональное тестирование". На YouTube. Слайды.
Цели 18-го процесса по ГОСТ Р 56939—2024:
Контроль полноты реализованных функциональных возможностей, обнаружение и исправление ошибок с использованием технологий функционального тестирования.
Общее количество вебинаров — 30. Каждому из 25 процессов ГОСТа посвящён отдельный вебинар и ещё 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.
Цикл вебинаров проведён компанией ООО "ПВС" совместно с учебным центром "Маском". Организаторами выступили Андрей Карпов и Виталий Пиков. Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.
P.S. ООО "ПВС" регулярно проводит вебинары и подкасты, и не только по теме РБПО :) Приглашаем желающих принять в них участие как в качестве зрителей, так и в качестве экспертов.
Когда регрессия уже не спасает: что почитать тестировщику про современный QA
QA больше не живёт в мире, где достаточно прогнать чек‑лист, закрыть пару багов и сказать: «ну вроде работает».
Сейчас тестировщику приходится думать шире: какие ошибки реально блокируют релиз, почему зелёные E2E‑тесты могут ничего не проверять, как flaky‑тесты ломают доверие к CI и где ИИ помогает, а где просто уверенно угадывает.
Начать стоит со статьи «Почему классический подход к QA больше не работает (и виновата ли в этом эпоха ИИ)». Это не очередной текст про «ИИ заменит тестировщиков», а разбор того, как меняется сама роль QA: от проверки готового продукта к работе с качеством на уровне архитектуры, данных, инфраструктуры, процессов и поведения системы после релиза.
В статье объясняется, почему старый подход уже трещит: современные продукты зависят от микросервисов, облаков, внешних API, ML‑моделей, пользовательских данных и цепочек интеграций. Поэтому тестировщику всё чаще нужно не просто находить баги, а понимать, где система может сломаться, как это повлияет на пользователя и что делать с качеством до, во время и после релиза.
А чтобы глубже разобраться в отдельных QA‑болях, собрали ещё несколько материалов:
«Ты QA и у тебя баги. Какие из них блокируют релиз?»
Практичный разбор для ситуаций, когда до релиза осталось два часа, багов несколько, а чинить всё уже невозможно. В статье — как оценивать дефекты не по страшности описания, а по последствиям: деньги, данные, доступ, личная информация, заявки, отчёты и возможность быстро откатиться.
«5 распространенных ошибок новичка в E2E‑тестах»
Для тех, кто пишет автотесты и не хочет получать зелёный, но бесполезный отчёт. На примерах Playwright разбираются ошибки вроде проверки интерфейса без проверки реального взаимодействия, неправильного ожидания событий, слабых локаторов и опасного использования force.
«Могут ли LLM находить flaky‑тесты по одному только коду теста? Разбор одного исследования»
О том, почему идея звучит красиво, но на практике всё сложнее. Flaky‑тесты часто зависят от контекста: окружения, хелперов, кода под тестом, истории изменений и скрытого состояния. Поэтому одной LLM и одного куска теста часто недостаточно.
А если хочется не только читать, но и разбирать QA‑подходы на практике — присмотритесь к бесплатным открытым урокам OTUS. Разделили ближайшие темы по направлениям: от ИИ в автотестах до мониторинга и инцидент‑менеджмента.
ИИ в тестировании и автотестах
2 июня, 20:00. «Нейросети и глубокое обучение в тестировании ПО: как приручить ИИ». Записаться
16 июня, 20:00. «ИИ в автотестах: помощник или угроза?». Записаться
18 июня, 20:00. «Тесты, которые чинят себя сами: практика ИИ в UI‑тестировании». Записаться
API, автотесты и инструменты
4 июня, 20:00. «API под контролем: тестирование сервисов с помощью Postman». Записаться
4 июня, 20:00. «Быстрая настройка конвейера автотестирования для 1С с хранилищем и Git». Записаться
Надежность, мониторинг и инциденты
10 июня, 20:00. «Мониторинг распределенных систем». Записаться
16 июня, 20:00. «Инцидент‑менеджмент в SRE. Как быстро находить, устранять и предотвращать сбои в системе». Записаться
Выбирайте тему под свой текущий фокус: ИИ в автотестах, API, мониторинг или инциденты. А если хочется посмотреть всё расписание — полный календарь открытых уроков OTUS.
И подписывайтесь на канал OTUS в MAX — там делимся новыми статьями, анонсами открытых уроков и полезными материалами для IT‑специалистов.
Привет! На связи 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
Добавляйте свои новости в комментарии. И заглядывайте в наш канал, чтобы быть в курсе других активностей и мероприятий для тестировщиков.
Почему зелёный 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) разбираю такие кейсы с кодом и объяснением: что показывать, как объяснять решения, какие находки работают на собеседовании.
Коллеги, у нас на Хабре идет голосование по Veai.
Если вы уже пробовали агент в JetBrains IDE или просто следите за тем, как меняется разработка с AI, загляните и проголосуйте ссылка на голосование Ваше мнение поможет нам понять, что важно разработчикам, и развивать продукт в правильном направлении.
Хочется проверить, насколько разработчикам близка идея AI-агента, который работает не вслепую по grep и длинным логам, а использует IDE как источник фактов: структуру проекта, зависимости, ошибки компиляции, тесты, конфигурации запусков и поведение приложения.
Будем рады голосам, комментариям и особенно критике. Она помогает точнее объяснять, чем Veai отличается от чат-ассистента, который не видит проект так, как его видит IDE.
Если у вас есть опыт с Cursor, Continue, JetBrains AI Assistant или другими инструментами, тоже приходите в обсуждение. Нам важны честные сравнения, а не стерильный маркетинговый текст.
Тестировщик докапывается — и это не баг, а фича
Тестировщиков иногда упрекают в том, что они всё время сомневаются и докапываются. Но что, если это не особенность характера, а главный профессиональный инструмент?
В новом выпуске «Не воспроизводится» Оля Шнайдер и Сережа Атрощенков разбирают тестирование не как набор действий, а как способ мышления. Почему QA ищет не подтверждение своей правоты, а подтверждение реальности? В чём разница между «душнилой» и внимательным инженером — и как донести эту разницу до коллег? Как поиск сложных багов превращается в настоящий квест, и почему отсутствие результата — это тоже результат? И наконец, как справляться с ощущением, что «что-то не так», даже когда работа сделана хорошо.
Слушайте выпуск на всех подкаст-платформах:
🎧 Яндекс Музыка
🔵 VK Видео
📺 YouTube
Ⓜ️ Mave
Согласно проекту Zero Day ClockLive, с 2018 года значительно сократилось время от выявления уязвимостей в ПО до начала их активной эксплуатации в продуктивных системах (дельта между публичным раскрытием CVE и первым подтверждённым случаем эксплуатации в реальных условиях).
Открытый проект SecretScanner помогает парсить пароли, API‑ключи, токены и другие ценные данные из приложений. Сервис проверяет Docker образы и файловую систему, чтобы отыскать секреты. Внутри у каждой программы есть целая база важной инфы — можно почерпнуть множество полезностей.
Что дальше в Пайплайне? Первый выпуск — в эфире!
Мы запустили новый формат: никаких слайдов и скучных докладов.
Шоу «Что дальше в Пайплайне» — это дружеская встреча, где специалисты делятся своими историями из профессиональной жизни в формате живого повествования. Здесь нет докладов — только забавные, поучительные и неожиданные случаи из работы в пайплайнах разработки, тестирования и деплоя.
Первый выпуск посвящаем QA-специалистам. Вместе с коллегами из Столото и Юзтех собрались, чтобы рассказать о том, что пошло не так в реальных проектах и угадать, чем закончились кейсы.
Ещё больше о мероприятиях — в нашем TG-канале.
Самое быстрое — «хренак-хренак и в продакшн»: о статическом анализе и скорости выхода продукта
Иногда задают вопрос: "Как статический анализ ускорит Time to market?"
Никак. Статический анализатор не ускорит выход продукта/обновления на рынок. С ним будет дороже и медленнее. Причина — неправильный вопрос.
Аналогично можно спрашивать, как этап тестирования ускоряет Time to market? Точно так же — никак. Тестировщикам мало того, что надо деньги платить, так они ещё будут разработчиков багами отвлекать. Намного быстрее просто написать запускающийся код и выложить дистрибутив. Как говорится, "хренак-хренак и в продакшен". Это самый быстрый вариант.
Но про тестирование, в отличии от статического анализа, такой вопрос не задают. Все понимают, что тестирование — важный элемент создания ПО. Видимо, статический анализ — более молодая методология по сравнению с тестированием, и он просто ещё не стал неотъемлемой частью разработки. Хотя видится очевидным, что и то, и другое неразрывно связано с обеспечением необходимого качества создаваемых программных продуктов.
Какой вопрос правильный?
Как статический анализ ускоряет Time to market при выпуске продуктов заданного уровня качества и надёжности?
Другое дело. Если нужно выпустить качественный продукт, то статический анализ может выявить многие ошибки и дефекты безопасности быстрее и дешевле, чем другие методы. Некоторые виды дефектов лучше обнаруживаются статическим анализатором кода, чем юнит-тестами, динамическим анализом, ручным тестирование и так далее.
Впрочем, это свойство и других методик. Есть дефекты, которые наиболее эффективно будут обнаруживать юнит-тесты, поэтому профессиональные разработчики не пытаются выбрать какой-то один подход, а используют сразу несколько. Эти разные меры усиливают друг друга.
Статический анализ применяется на этапе конструирования, то есть написания кода, поэтому позволяет устранить многие ошибки ещё до этапа тестирования. Хотя на анализ предупреждений необходимо тратить время, это окупается сокращением числа дефектов, которые выявляются на других этапах проверки продукта и его эксплуатации. Известно, что чем раньше ошибка найдена, тем дешевле её исправление.
P.S. Если понадобится, то есть более формальный и развёрнутый вариант этой сентенции – Статический анализ кода и вывод программных продуктов на рынок.
Проблемы с производительностью обычно проявляются в самый неподходящий момент: когда резко растет нагрузка или система обрабатывает сложные сценарии.
Именно для таких ситуаций существует нагрузочное тестирование. Но сам процесс — это не только запуск тестов. Нужно собрать требования, подготовить инфраструктуру, настроить инструменты и синхронизировать работу команд.
Егор, аналитик в Naumen Contact Center, рассказал, как внутри продукта устроено нагрузочное тестирование и почему «запустить тест» — самая простая часть.
1️⃣ Что такое нагрузочное тестирование?
Нагрузочное тестирование показывает, насколько хорошо система справляется с большим количеством пользователей или объемом данных. В случае контакт‑центра это, например:
количество одновременно работающих операторов
нагрузка на входящие и исходящие вызовы
2️⃣ Почему аналитик вообще занимается нагрузочным тестированием?
У каждого аналитика в нашей команде есть свои зоны экспертизы. Я, например, начал погружаться в тему производительности, поэтому нагрузочное тестирование со временем стало частью моей работы.
Моя задача — анализировать требования и описывать, как именно должно проходить нагрузочное тестирование: что проверяем, какие сценарии запускаем и какие параметры считаем важными.
3️⃣ Когда нужно проводить нагрузочное тестирование?
Есть несколько типичных ситуаций, когда без него не обойтись:
Регулярные проверки перед релизом или после обновления серверов.
Тестирование новых фич — если изменения потенциально могут повлиять на производительность.
Запросы от клиентов или команды внедрения — когда нужно проверить нагрузку или конфигурацию.
Внутренние задачи разработки — когда команде нужно проверить свои решения под нагрузкой.
Однако протестировать все невозможно — это требует слишком больших ресурсов. Поэтому мы используем карту нефункциональных требований: проходим по чек-листу и смотрим, могут ли изменения повлиять на производительность системы.
4️⃣ Как принимается решение о проведении тестирования?
Обычно это происходит на встрече по оценке фичи. В обсуждении участвуют тимлиды разработки, архитекторы, тестировщики и другие cпециалисты. Аналитик приносит информацию по изменениям, а дальше команда совместно решает, нужен ли нагрузочный тест.
5️⃣ Как устроен процесс нагрузочного тестирования?
Процесс можно разделить на три этапа:
Первичная аналитика — собираем требования и определяем цель.
Детальная аналитика — описываем сценарии, метрики, инфраструктуру.
Проведение тестов — запускаем тестирование и анализируем результаты.
6️⃣ Почему нагрузочное тестирование требует отдельной инфраструктуры?
Для более-менее реалистичного тестирования недостаточно одного сервера. В нашем случае используются несколько гипервизоров, десятки виртуальных машин, серверы генерации и приема нагрузки, а также инструменты вроде Gatling, JMeter, Grafana и Ansible.
Отдельные компоненты эмулируют работу операторов и клиентов. Например, для проверки нескольких тысяч операторов фактически собирается отдельный контур.
7️⃣ Почему даже короткий тест может занимать полтора часа?
Потому что сам прогон — только часть процесса. До запуска нужно подготовить окружение, очистить старые данные, проверить сервисы, настроить мониторинг и применить параметры. После — собрать артефакты, метрики и результаты. Поэтому тест на 20 минут превращается в полтора часа работы.
8️⃣ Что происходит после тестирования?
После прогона команда анализирует логи, метрики, бизнес-отчеты и дашборды в Grafana. Есть основные метрики, которые проверяются постоянно. Для контакт-центра это, например, скорость установления соединения, скорость открытия экранных форм, переходов между ними и закрытия экранных форм.
Если эти показатели проседают, тест нельзя считать успешно пройденным, даже если сама фича формально работает.
После анализа команда либо фиксирует результаты, либо заводит задачи на доработку сервисов, окружения или инструментов.
Бесплатный сервис для базового мониторинга сайта и срока жизни ssl сертификата
Что умеет SaveTrace?
- Мониторинг доступности по HTTP/HTTPS для сайтов и API.
- Отслеживание времени отклика, чтобы замечать деградацию до реального падения.
- Контроль SSL-сертификатов и сроков их действия.
- Уведомления о проблемах и история инцидентов в понятном интерфейсе.
Thales опубликовала ежегодный отчёт Bad Bot Report, посвящённый автоматизированной активности в глобальной сети. Главный вывод документа — 53% всего мирового интернет‑трафика по итогам 2025 года пришлось на ботов, тогда как люди сгенерировали лишь 47% запросов. Аналитики компании подчёркивают, что почти 40% общемирового веб‑трафика относится к категории вредоносного и речь идёт не только о примитивных скриптах для подбора паролей или мониторинга цен. Авторы исследования прогнозируют, что в 2026 году интернет окончательно станет средой, где машинное боты и ИИ‑агенты будут доминировать. Это потребует от владельцев цифровых сервисов перехода к модели управления на основе политик: с детальным мониторингом, поведенческим анализом и сегментацией автоматизированной активности по уровню доверия.
Ты один QA на проекте? Это твой шанс или риск?
Соло-тестировщик — звучит гордо, но как не утонуть в задачах без онбординга и поддержки? Эксперт Юзтеха на совместном митапе Moscow QA #23 x ИнфоТеКС & Юзтех разобрала типичные сложности и показала, как соло-формат может стать точкой роста, а не дорогой к выгоранию.
Будет полезно, если вы хотите понять, как не выгореть и вырасти.
P.S. Заходите в наш TG-канал, там мы рассказываем о технических мероприятиях и конференциях, делимся выступлениями экспертов, обсуждаем подборки на технические и ИБ темы.
Ответственность за качество: почему это не только твоя проблема
Работа тестировщика — это постоянный поток задач, ожиданий и комментариев со всех сторон: менеджеры, разработчики, руководство.
Работа тестировщика — это постоянный поток задач, ожиданий и комментариев со всех сторон: менеджеры, разработчики, руководство. И где-то в этом потоке легко потерять и эффективность, и себя.
В новом выпуске «Не воспроизводится» Оля Шнайдер и Сережа Атрощенков поговорили о том, как в этой гонке сохранить голову. В гостях — Вася Юдин, тимлид команды, которая делает инструменты для тестировщиков Авито. Обсудили три вещи, о которых в профессиональном контексте говорят редко: почему ответственность за качество — это не груз одного QA, а дело всей команды; как давать и принимать критику, не превращая это в стресс; и стоит ли вообще пытаться вывозить всё в одиночку.
🎧 Слушайте выпуск подкаста на всех подкаст-платформах:
Обсуждение тем, тренды в QA и, конечно, мемы — в Telegram-канале «Не воспроизводится».
Добро пожаловать в мир тестирования. Баги прилагаются.
Ещё больше экспертизы собрали для вас на сайте: смотрите наши лонгриды, новости, и видео. А узнать, как стать частью команды AvitoTech, можно вот здесь.
Если тесты есть, а уверенности в них нет — 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‑инструментами.
Все уроки бесплатные и проходят в рамках онлайн‑курсов. Их ведут преподаватели‑практики, поэтому это не формат «послушать общую теорию», а возможность посмотреть на реальные подходы, познакомиться с экспертами, протестировать формат обучения и задать вопросы по теме или курсу.
📌 Посмотрите каталог курсов по тестированию: там уже не отдельные инструменты, а полноценные треки с практикой, архитектурой и реальными кейсами.
📝 Анонс бесплатных открытых уроков на неделю: 27–30 апреля
Привет, коллеги! Традиционная подборка открытых онлайн‑мероприятий для тех, кто хочет прокачать скиллы в IT, управлении, аналитике и автоматизации. На этой неделе — фокус на архитектуру, тестирование, Computer Vision и внутреннюю кухню разработки. Всё бесплатно, но нужна регистрация.
📅 Расписание по дням
Понедельник, 27 апреля
Вторник, 28 апреля
20:00 — «Коучинговые инструменты для мотивации и повышения продуктивности команды»
20:00 — «Архитектура тестового фреймворка: от хаоса к стабильности»
20:00 — «Контрактные тесты в Kotlin: как подружить фронт и бэкэнд»
20:00 — «Почему только 5% компаний получили реальную выгоду от ИИ в 2025 году?»
Среда, 29 апреля
20:00 — «Деревья решений для задач классификации и регрессии»
20:00 — «Свой язык на PHP за 60 минут»
20:00 — «Качество C#‑кода: от модульных тестов к системному подходу»
20:00 — «Продакт‑менеджер, маркетолог и PMM — в чём разница»
Четверг, 30 апреля
20:00 — «Yahoo Finance и не только — работа с российскими торговыми площадкам»
20:00 — «Поиск в базе знаний: где векторы ошибаются, а графы помогают»
20:00 — «Как управлять тимлидами?»
20:00 — «Битрикс24 + MAX: разработка чат‑ботов и автоматизация коммуникаций»
20:00 — «Планируем внедрение DevSecOps — что следует учесть?»
Мы перечислили 20 открытых вебинаров на эту неделю. Если вы не нашли в расписании тему, которая нужна именно вам, — загляните в полный календарь
23 апреля: Открытый бесплатный вебинар про ИИ-агенты
Сегодня 23 апреля в 11:00 рассмотрим прикладные сценарии, ограничения и старт внедрения. Разберем примеры разработки и внедрения под задачи тестировщиков, разработчиков, сотрудников непроизводственных направлений (маркетологи, рекрутеры, операционисты). Нужна предварительная регистрация, мероприятие бесплатное. в онлайн формате.
О чем расскажем на вебинаре
ИИ-агенты постепенно переходят из зоны демонстрационных прототипов в область прикладных внедрений. При этом между «работает в демо» и «работает в системе» по-прежнему есть разрыв — прежде всего в данных, процессах и сценариях применения.
Вебинар сфокусирован на разборе практических границ применимости: где ИИ-агенты уже дают эффект, а где их использование нецелесообразно.
Авторы и спикеры вебинара:
Роман Садрисламов, директор производственного направления, FabricaONE.AI (акционер — Softline)
Роман Смирнов, коммерческий директор, FabricaONE.AI (акционер — Softline)
Основной фокус обсуждения
Эксперты покажут опыт компании и заказчиков в трех базовых вопросах:
в каких сценариях ИИ-агенты дают измеримый эффект;
чем ИИ-агенты отличаются от чат-ботов в прикладных задачах;
какие сценарии стоит запускать первыми, а какие — отложить.
Среди кейсов:
Снижение ручных операций: сокращение доли рутинных действий в бизнес-процессах.
Ускорение процессов: Использование ИИ-агентов для сокращения времени выполнения задач.
Работа с информацией и знаниями. По направлениям: поиск информации, работа с корпоративными знаниями в разных отраслях, подготовка ответов и решений на основе доступных данных.
Работа с неструктурированными данными: включая упрощение обработки больших объемов неструктурированной информации.
Бонус: практический блок по кейсу участника
При предварительной регистрации, каждый участник может прислать собственный пример ИИ-агента. Самый интересный вариант спикеры подготовят в виде разбора и в прямом эфире покажут сильные стороны, архитектурные задачи и потенциальный эффект внедрения.
Регистрация открыта по ссылке:
https://clck.ru/3T3cYR
Кому будет особенно полезна встреча
руководители бизнеса (CEO, коммерческие директора) — влияние на экономику процессов
ИТ-руководители (CIO, CTO) — интеграции, архитектурные и безопасностные ограничения
операционные руководители — снижение нагрузки на команды
руководители цифровизации — выбор пилотных сценариев внедрения
Ручное vs автоматизированное тестирование: где заканчивается автоматизация и начинается здравый смысл
Спор между сторонниками ручного тестирования и автоматизации идёт давно — и обычно заходит в тупик. Потому что вопрос «что лучше» изначально поставлен неправильно.
В третьем выпуске «Не воспроизводится» ведущие подкаста Оля Шнайдер и Серёжа Атрощенков отошли от вкусовщины и попробовали разобраться по существу. Когда автотест — это инвестиция, а когда попытка автоматизировать бессмысленность? В каких сценариях ручное тестирование быстрее и точнее? И правда ли, что, уйдя с головой в автотесты, можно потерять связь с реальным пользователем?
Обсудить это пришли Игорь Стародубцев, тестлид в Авито Товарах, и Глеб Дмитриев, старший QA в Распродажах — люди, которые каждый день принимают именно эти решения.
🎧 Слушайте выпуск подкаста на всех подкаст-платформах:
Обсуждение тем, тренды в QA и, конечно, мемы — в Telegram-канале «Не воспроизводится».
Добро пожаловать в мир тестирования. Баги прилагаются.
Ещё больше экспертизы собрали для вас на сайте: смотрите наши лонгриды, новости, и видео. А узнать, как стать частью команды AvitoTech, можно вот здесь.
Начал потихоньку разбирать то самое чудо-юдо из одного из прошлых постов. И, честно говоря, в этот раз оно решило не сопротивляться — на сайте производителя неожиданно нашлась вполне вменяемая документация. Причём не просто общие слова, а с техническими деталями и даже распиновкой.
Выяснилось, что всё довольно прозаично: красный — это KL.30, чёрный — земля, а белый — тот самый загадочный третий провод, который раньше вызывал больше всего вопросов. Им оказался KL.15 — не просто «ещё один плюс», а линия, на которую питание подаётся только при включённом зажигании. То есть, в отличие от постоянного питания на KL.30, этот провод живёт своей жизнью: есть зажигание — есть питание, нет зажигания — тишина: всё, что не должно сажать аккумулятор на стоянке, вешается именно туда.
В ходе изучения устройства я долго пытался понять, как же оно осуществляет связь с оператором: где GSM сим-карта или тут все по новомодной технологии Mesh? :) Ну или мне стоит искать дополнительный модуль связи где-то у себя под задним сидением? Но нет — всё оказалось куда компактнее. Если верить документации на УВЭОС, внутри вполне взрослый набор: GSM, UMTS и LTE в нескольких диапазонах, а тип SIM-карты – резидентная (несъемная) многопрофильная SIM-карта, установленная на печатную плату по SMD-технологии.
И действительно, если присмотреться, то “симка” у нас в форм-факторе WSON 8, и даже обведена соответственно. Поэтому, одним из следующих шагов может быть ее выпаивание и установка в полнофункциональный мобильный аппарат: узнать оператора связи, номер телефона, есть ли безлимитный интернет и звонки на отличные от экстренных служб номера.
А то кто знает… ну вы поняли ;)
Про остальные составляющие расскажу в будущих постах, а вы пока можете делать ставки, что тут еще есть интересного.
🧠 Обязательно поделись с теми, кому это может быть полезно: 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте
Я знаю, что ничего не знаю (с) Сократ
Казалось бы, уже более 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 | 📝 Хабр | 💙 ВКонтакте
Инструкция по отключению в Windows 11 процесса NDU (Network Diagnostic Usage), который не несёт ничего полезного и нужен только для того, чтобы в Microsoft мониторили подключение ПК.
Как отключить эту опцию:
Win+R → regedit.
Заходим в директорию: Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Ndu
Меняем значение «Start» на «4».
Перезагружаем ПК.
Уронить прод специально: безумие или отвага?
Есть инженеры, которые боятся инцидентов. А есть те, кто устраивает их самостоятельно — по расписанию, с тикетом в Jira и полным пониманием того, что сейчас случится. Chaos Engineering — это не баг в процессах, а фича. Только вот объяснить это менеджеру, когда прод лежит намеренно — всё равно непросто.
Вместе с Дмитрием Баскаковым, Head of Platform в MindBox, разбираемся, что на самом деле стоит за этим методом — и почему компании, которые регулярно что-нибудь ломают, в итоге падают реже остальных.
Что на повестке
Chaos Engineering звучит красиво, но практика гораздо прозаичнее: нужна культура, нужны SLO, нужно понимать, что именно вы тестируете — систему или людей. В выпуске обсуждаем, чем хаос-тесты отличаются от нагрузочного тестирования, кто принимает решение «ломать» и кто за это отвечает, почему без blameless-культуры всё это превращается в поиск виноватых — и есть ли у хаос-инженерии реальный ROI или это дорогостоящее развлечение для зрелых команд.
Отдельно поговорили про выгорание: добавляет ли плановый хаос тревожности инженерам — или, наоборот, снимает её.
Если вы хоть раз думали «у нас и так всё нестабильно, зачем ещё специально ломать» — этот выпуск именно про вас.
Слушайте и смотрите на площадках
И подписывайтесь на телеграм-канал Avito SREда
Ещё больше экспертизы собрали для вас на сайте: смотрите наши лонгриды, новости, плейлисты видео. А узнать, как стать частью команды AvitoTech, можно вот здесь.
ИИ пришёл в QA. Что с этим делать?
У ИИ в тестировании есть две крайности: одни говорят, что он уже всё автоматизирует, другие — что это хайп и ничего толком не работает. Истина, как обычно, где-то посередине — и во втором выпуске «Не воспроизводится» мы попробовали её найти.
В этот раз в гости к Оле Шнайдер и Сергею Атрошенкову пришел Андрей Бровко, тестлид Авито Авто, AI-евангелист в тестировании и лидер AI Agent Dev Community. Андрей работает с этой темой изнутри, поэтому разговор получился конкретным: где ИИ уже реально помогает, где пока добавляет больше головной боли, чем пользы, какие риски стоит держать в голове — и что в работе QA-инженера искусственному интеллекту пока не под силу.
🎧 Слушайте выпуск подкаста на всех подкаст-платформах:
💬 Обсуждение тем, тренды в QA и, конечно, мемы — в Telegram-канале «Не воспроизводится».
Добро пожаловать в мир тестирования. Баги прилагаются.
Ещё больше экспертизы собрали для вас на сайте: смотрите наши лонгриды, новости, и видео. А узнать, как стать частью команды AvitoTech, можно вот здесь.
Как думает хакер: логика атак на бизнес
Как оценить безопасность компании с точки зрения злоумышленника? Одно дело — знать теорию защиты, другое — понимать логику взлома.
27 марта состоялся очный бизнес-интенсив, реализуемый в рамках курса повышения квалификации «Анализ типовых сценариев компьютерных атак на организации и их последствия» МГТУ им. Н.Э. Баумана совместно с компанией Бастион!
Программа построена на исследовании сценариев реальных компьютерных атак и включает три ключевых блока:
1️⃣ Разведка: как хакер выбирает жертву
2️⃣ Внутренний взгляд: как атака развивается внутри компании
3️⃣ Вас взломали: что делать в первые 24 часа
Спикеры:
Дмитрий Калинин, директор департамента по работе с уязвимостями и инцидентами ИБ, Бастион
Иван Глинкин, руководитель группы аппаратного тестирования департамента по работе с уязвимостями и инцидентами ИБ, Бастион
Для тех, кто по тем или иным причинам не мог присутствовать очно, представляю полную запись интесива во 📺 ВКонтакте (3 часа 5 минут).
🧠 Обязательно поделись с теми, кому это может быть полезно: 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте
