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

Почему мониторинг, SRE и автотесты перестали работать по отдельности?

Digital Immune System (DIS) или Цифровой Иммунитет — это способность инфраструктуры почувствовать, что с ней что-то не так, и починить себя раньше, чем это заметит пользователь.

В новом выпуске «В SREду на кухне» Андрей Волхонский, Андрей Колесников и Василий Осипенко разбирается что такое DIS, из чего он состоит и почему это не просто модное словосочетание, а способ пересобрать подход к надёжности.

Гость выпуска: Михаил Савин, руководитель отдела SRE в H3LLO CLOUD

Смотрите и слушайте на площадках:
🔵 VK Видео 
📺 YouTube
📌 RuTube
Ⓜ️ Mave

Выделенный сервер на Xeon E3: разбираем варианты переезда 

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

В SpaceWeb мы держим линейку на Xeon E3-1270 v3 — процессоре не новом, но зато проверенном годами. Варьируя лишь объем RAM и тип накопителей, можно решить почти любую задачу: от легкого сайта до файлового хранилища на терабайты.

Какую выбрать конфигурацию:

• Сайт или несколько веб-проектов. 16 ГБ RAM и пара SSD — база для Битрикса, WordPress или интернет-магазина. Если проектов больше, тогда берем 32 ГБ.

• Интернет-магазин или портал с контентом. Тот же процессор, но диски побольше: под базы, картинки и логи.

• Бэкапы, архивы, почта. Здесь скорость SSD не нужна, поэтому ставим HDD на терабайты. Дешевле, а задачу решает.

• Сайт и файлы на одном сервере. Гибрид: SSD под приложение, HDD под документы. Удобно для корпоративных порталов и Bitrix24.

Посмотреть полные характеристики и заказать нужную конфигурацию можно на сайте SpaceWeb. А если не нашли подходящий вариант — просто напишите нам на почту dedic@sweb.ru, мы поможем подобрать решение вручную.

В команде Cloudflare представили скилл Security Audit Skill, который учить нейросети искать уязвимости. Проект запускает целый рой агентов, которые ищут разные уязвимости в проекте, а затем другие ИИ-агенты перепроверяют все находки и отбрасывают ошибочные срабатывания. В итоге получается полноценный ИБ-отчёт с обнаруженными проблемами.

Модульный фреймворк для гибкого тестирования на Go — Testo

Если у вас десятки тысяч тестов, сложные сценарии, а тестам не хватает наглядных отчетов – наше опенсорс-решение может вам помочь

Testo — это слой над testing.T внутри экосистемы Go. Мы наполнили его плагинами, чтобы гибко адаптироваться под потребности и быстро создавать тесты под любую задачу.

Что ещё может Testo

1. Параметризировать тесты.

2. Параллелить тесты.

3. Собирать тесты в Suite'ы.

4. Формировать Allure-отчёты.

5. Перезапускать упавшие тесты.

И многое другое, благодаря плагинам.

Больше информации о функционале и ссылка на GitHub — на страничке фреймворка.

Тестирование в эпоху ИИ

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

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

• Делегировать техническую рутину

Даша, младший тестировщик в команде релизного тестирования SMRM:

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

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

• Подключить дополнительную проверку

Катя, тестировщик в команде релизного тестирования SMRM:

Перед составлением тест-плана сначала анализирую задачу с ИИ. Потом сама внимательно все продумываю и еще раз возвращаюсь к нему, чтобы проверить, не пропустила ли что‑то.

После тестирования тоже разбираю с ИИ проведенные проверки — смотрю, все ли учла.

• Анализировать изменения и дефекты

Даша, младший тестировщик в команде релизного тестирования SMRM:

С помощью ИИ анализирую изменения в задаче и смотрю, какие части системы они могли затронуть прямо или косвенно. Еще разбираю с ним причины дефектов.

Когда не получается подобрать название дефекта, отправляю в ИИ свои идеи. Он помогает их структурировать, а итоговое название я формулирую сама.

• Использовать готовых ИИ-помощников

Катя, тестировщик в команде релизного тестирования SMRM:

У нас в команде уже есть несколько готовых ИИ-помощников. Один может пройтись по дефекту и подсказать, что стоит поправить. Другой анализирует покрытие автотестами — подсвечивает, что уже покрыто, а что нет.

Есть и ревьюер тест-кейсов, который помогает находить в них недочеты.

Важно: результаты ИИ тоже нужно проверять

Даша, младший тестировщик в команде релизного тестирования SMRM:

Пока ИИ не меняет процесс тестирования радикально. Но помогает не тратить время на долгий поиск информации и быстрее разбираться в сложном.

Для меня особенно важно критически подходить к ответам ИИ. Он может галлюцинировать, поэтому я использую его как помощника, а не как источник, которому можно полностью доверять.

Катя, тестировщик в команде релизного тестирования SMRM:

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

Автоматическое сравнение профилей нагрузки: как не потеряться между тестом и продом

Запустить нагрузочный тест мало — важно понять, что именно ты измеряешь и с чем сравниваешь. Эксперт Dodo Engineering на митапе «Гонка за производительностью» показал, как выстроить мониторинг профиля нагрузки и какие метрики реально работают.

Разобрали, почему без учёта исключений мониторинг теряет смысл, и при чём тут база данных. А главное — как сравнивать тестовый профиль с продакшеном и получать бинарный результат, а не просто «что-то пошло не так».

• Смотреть запись

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

На связи QA‑сообщество 2ГИС. И это снова дайджест релизов.

➡️ Python

Документация Python официально на русском. Перевод опубликован на docs.python.org и сделан сообществом. Теперь джуниоры могут ссылаться на официальный русский источник. Также появился общий стандарт переводной терминологии. Перевод будет обновляться параллельно с оригинальной документацией.

➡️ Polars 1.44.0

Основные улучшения в SQL: кэширование общих табличных выражений, корректная обработка join и подзапросов. Поддержка Iceberg расширена за счёт эволюции схем и других возможностей. Исправлены проблемы с вложенными списками в Arrow. Частично deprecated устаревшие параметры.

➡️ pip 26.2

Теперь учитывается Cache‑Control индекса, что влияет на обновление недавно опубликованных пакетов. Добавлены флаги для изолированных сборок, поддержка Python 3.15, а также исправления безопасности.

➡️ Playwright 1.63

Test Locks и новые API. Появилась возможность создавать именованные lock для тестов. Тесты с одним lock не запускаются параллельно. Улучшен поиск элементов во фреймах. Добавлен метод .visible() в локаторы, расширены параметры тестовых шагов и отчётов. Обновлены браузеры и исправлены баги.

Кто уже попробовал работать с lock в Playwright? А кто впервые увидел python docs на русском? Дайте знать, что оказало влияние именно на вашу практику! И заглядывайте в наш канал, чтобы быть в курсе других активностей и мероприятий для тестировщиков.

Ближайшие бесплатные вебинары:

🎬 «Как ИИ уже изменило тестирование ПО»
14 сентября, 18:00–19:00 (Мск).
Разберём, что реально делегировать, где нужна экспертиза человека и сколько это стоит. Отдельно обсудим роль QA как дирижёра ИИ-процессов, контроль стоимости токенов и логирование, а также инфраструктурные задачи и кейсы автоматизации рутины. В финале — риски: безопасность данных в LLM, рост затрат, организационные сложности и снижение компетенций при чрезмерной зависимости от ИИ.
✍️ Записаться

🎬 «Один SQL над Iceberg, PostgreSQL и ClickHouse: как Trino выполняет федеративные запросы, и где они начинают тормозить»
15 сентября, 17:00–18:00 (Мск).
Один SQL над Iceberg, PostgreSQL и ClickHouse: как Trino выполняет федеративные запросы и где они тормозят. На живом примере с EXPLAIN ANALYZE — план выполнения и способы ускорения, от фильтрации и материализации до вычислений в источнике. В финале — сравнение с PostgreSQL/Greenplum, ClickHouse и Spark SQL и что меняется в проде.✍️ Записаться

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

На круглом столе QA-days эксперты Okko, ИнфоТеКС, Piter QA прошлись по самым острым темам тестирования:

• Доверие к QA — как заслужить и не потерять

• Рутина — враг или союзник?

• Кросс-командное vs кроссплатформенное тестирование — в чём разница и как организовать без боли

• Интеграционное тестирование — где ломается чаще всего и как чинить

• Shift Left — почему на практике внедряется так тяжело, несмотря на очевидную пользу.

Смотреть запись

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

QA-дайджест за июль-август 2026

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

📊Рынок
Вышел The State of Testing™ Report 2026 от PractiTest. Статистика неутешительна: 56,4% QA-команд по-прежнему оценивают по покрытию тестами и 40,1% — по покрытию автоматизацией, тогда как бизнес-влияние учитывают лишь 8,6% организаций. Это явный перекос в сторону объема работы, а не ее ценности для продукта. Похожий перекос виден и в применении ИИ: 70% команд используют его для генерации тест-кейсов и только 19,9% — для стратегического риск-анализа. Самыми передовыми инструментами сейчас называют Selenium и Playwright, при этом за владение вторым соискателям дают на 38% больше денег в год. Впрочем, возможно, это всего лишь корреляция. 

Еще забавное: отчет Perforce/Perfecto по DevOps и ИИ в тестировании свидетельствует, что 66% компаний отметили рост общих затрат после внедрения ИИ. При этом комплексный трекинг затрат на ИИ-тестирование настроен лишь у 43% — то есть тестирование с использованием ИИ растет быстрее, чем контроль затрат над ним. 

🔧 Интересные материалы на Хабре
Команда из InfoWatch рассказала, как ввела регламент стыковки ручного и автотестирования для построения единой системы контроля качества. Можно утащить к себе в практику таблицу этапов/артефактов/критериев и список ошибок, ну и саму логику стыковки. 

Ozon Tech поделился Testo — open source фреймворком для E2E-тестов на Go (Apache-2.0, 60 тыс. тестов, 500+ сервисов). В статье описывают, как это меняет работу: теперь инженер пишет проверку как обычно, а Testo сам красиво оформляет отчет, параллельно запускает тесты на сотнях машин, повторно прогоняет упавшие и передает данные между этапами. Перспективно для тех, кому надо писать и поддерживать большие end-to-end-тесты на Go.

Ребята из 2ГИС описали свой опыт тестирования приложения «в поле», ведь баги геопозиции почти невозможно воспроизвести на тестовом стенде. Описанные практики возможно пригодятся тем, чьи продукты связаны с навигацией и страдают от «глушилок».

🤖Про агентов
Коллеги из TestOps построили «Агента Смита» — платформу агентной правки багов с целью «ноль багов в бэклоге». Суть следующая: выстраивается цепочка независимых шагов, каждый из которых создает артефакт, на который опираются последующие шаги. Итог: 100 прогонов, 76 закончились открытым мерж-реквестом, 62 из них влиты (81,6%). Из влитых 53 ушли в основную ветку без единой правки человеком. Можно утащить к себе логику шагов и потестить на своих кейсах. 

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

💼 Для карьеры
Вышел анонс осенней конференции Heisenbug 2026, обещают 36 докладов от гигантов рынка. От нас там выступит Александр Волков, который проведет воркшоп по тому, как собрать своего QAI-агента. 

Также анонсировали SQA Days / 39. Цены на участие немного кусачие, поэтому если хотите попасть, самое время начать согласовывать затраты с руководством.

У нас появилась целая пачка горячих вакансий, которая ждет ваших откликов:

• Fullstack QA (Infra Agent)

• Fullstack QA (IaaS Terraform)

• Fullstack QA (Distributed Train)

• Fullstack QA (Managed RAG)

• Fullstack QA (ML Inference)

👉Подписывайтесь, чтобы не пропустить следующую порцию пользы. 

Как не провалить пилот ESB: разберем два реальных сценария на онлайн-конференции

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

На практике вопросов гораздо больше.

• Что именно включать в пилот?

• Какие сценарии действительно показательны?

• Нужно ли проверять только функциональность или еще производительность, мониторинг и удобство сопровождения?

• Стоит ли отдавать пилот интегратору или пробовать силами внутренней команды?

15 сентября в 11:00 вместе с DATAREON проведем онлайн-конференцию «Архитектурная лаборатория: как выбрать ESB под вашу ИТ-архитектуру». Разберем не только возможности платформы, но и то, как организовать пилот так, чтобы он действительно помог принять решение.

Что будет в программе

Сергей Скирдин, технический директор «Белого кода», расскажет:

• как сегодня выглядит российский рынок шин данных;

• какие критерии стоит учитывать при выборе ESB;

• в чем преимущества DATAREON Platform;

• зачем пилотировать платформу на реальном ИТ-ландшафте;

• какие задачи стоит закладывать в пилот.

Иван Макушов, аналитик Ikon Tyres, поделится опытом пилота с внешним подрядчиком:

• как в компании подходили к выбору новой интеграционной платформы;

• какие технические требования сформировали;

• какие сценарии включили в пилот;

• на что стоит обратить внимание при работе с интегратором..

Дмитрий Сидоренков, архитектор 1С «Уральской Агропромышленной Группы», расскажет про другой путь — пилот и дальнейшее внедрение внутренними силами:

• почему одного обучения недостаточно, чтобы начать реальный проект;

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

• почему хотя бы один человек должен быть глубоко погружен в проект;

• где самостоятельной команде все же полезна внешняя экспертная поддержка;

• как перейти от первого работающего обмена к самостоятельному развитию интеграций.

По сути, сравним два сценария:

пилот с подрядчиком
и
пилот внутренней командой.

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

15 сентября, 11:00 по МСК

Участие бесплатное, нужна регистрация.

Регистрация

Еще одна интересная форма тупости у нейросеток (сначала Claude Sonnet 5, потом Claude Opus 5): оно не понимает, что если устройство (нетривиальное, то есть у которого есть внутреннее состояние) выдало глюк на тесте в первую секунду работы, то бесполезно минимизировать количество глюков, которое оно выдаст в следующий час. Оно уже глючное, нужно исправлять первый глюк. Прогресс - это не “было 100 глюков в час, стало 80”, а “был глюк на первой секунде теста, а теперь глюк появился только на второй”.

Дал нейросетке задание: исправить ошибку в сгенерированном ею модуле на языке описания аппаратуры SystemVerilog. Модуль погружен в тестовое окружение которое проверяет работу модуля против его модели (тоже написанной на SystemVerilog). На вход и модуля и модели подаются одни и те же входные транзакции (stimuli), после чего у них сверяется ответы. Ответы могут приходить в несколько разное время, но это не имеет значения, потому что перед проверкой они складируются в очередях. Как и исходные транзакции до отправления, чтобы не сравнивать детали латентности handshake-ов.

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

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

Это из той же оперы как “если ты услышал что часы на башне пробили 13 раз, то скорее всего неверным является не только 13-й удар колокола, но и 12 предыдущих”. Или если у тебя syntax error в коде на Си в строке 100, то зачем проводить всю ночь пытаясь минимизировать количество syntax errors в последующих строках?

Друзья!

Перед вами моя новая фантастическая повесть «Королев ИИ»: инженеры нооэры», которая родилась не на пустом месте. Она выросла из моей многолетней работы в сфере информационных технологий и бесценного опыта, который я получил во время работы над созданием Центра разработки и внедрения сильного и прикладного искусственного интеллекта МГТУ им. Н.Э. Баумана в 2021 году[1], а также из опыта работы над проектом создания научно-образовательной платформы «Королев ИИ».

Эта повесть выходит в преддверии важного события. В сентябре 2026 года в МГТУ им. Н.Э. Баумана стартует полноценное использование научно-образовательной платформы «Королев ИИ» для всех сотрудников, преподавателей и студентов. По нашей задумке, платформа должна стать, в некотором смысле, «фундаментом» нашего университета, в рамках реализации концепции «Университет 4.0» и будущей концепции, которую мы назвали «Нейроуниверситет» (над которой мы уже работаем). Сейчас, у нас большой потенциал и задел по ноу-хау, новым задачам и новым ИИ-сервисам для университета, по научным открытиям и публикациям полученных результатов, которые мы планируем реализовать в ближайшее время.  И, — это только начало.

В этой повести я попытался заглянуть за горизонт текущего момента. Попытался представить, какими могут быть новые технологии ближайшего будущего и каким может стать наш мир, где искусственный интеллект будет не просто инструментом, а станет незаменимым помощником человека, чьи технологии позволят человеку быть не просто «продвинутым» пользователем интеллектуальной автоматизированной системы, а помогут стать настоящим творцом и исследователем (то есть, так называемым, инженером нооэры), использующим знания и опыт для творчества, созидания и сохранения нашего мира и, возможно, покорения Солнечной системы.

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

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

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

2126 год начинается 1 сентября 2026 года.

Ваш Александр Чесалов.

QA-эксперт Авито о том, почему вход в IT через тестирование больше не работает

Всем привет! Гостья нового выпуска AviTalk — Соня Каребина, QA-эксперт Центра экспертизы обеспечения качества в Авито. До IT у неё были инженер-нефтяник и администратор фотостудии — то есть путь в тестирование получился совсем не прямым. Ведущий выпуска — Виктор Раев, руководитель разработки юнита Services Base.

Говорим о том, почему в тестировании нет универсального ответа «релизить или не релизить» и как QA оценивает риски для пользователей и бизнеса. Разбираемся, почему умение договариваться для тестировщика важно не меньше технической экспертизы, и каким становится процесс, когда человек и AI работают в связке. А ещё — про волонтёрство, эмоциональное выгорание, вязание, двести комнатных растений, мечту о Марсе и принцип, который в своё время помог Соне сменить профессию.

Смотреть выпуск:

🔵 VK Видео
📺 YouTube
📌 RuTube

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

Баг в проде — кто виноват?

На QA-days: Оkko, ИнфоТеКС и Piter QA эксперт из Okko показал, как в компании ZBP учитывают не только критичность бага, но и причины его пропуска. Результат: багов первой категории стало в 2,5 раза меньше. Просто показали разработчикам, сколько они выкатывают.

• Смотреть запись доклада

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

Эволюция ченжлога на сайте

Многие из вас предлагают идеи по развитию продуктов и следят за обновлениями. Чтобы отслеживать релизы было проще, даже если пропустили дайджест, мы переделали старый ченжлог в «Журнал обновлений». В нем записана вся история релизов, изменений и исправлений багов с лета 2024 года.

Что появилось:

1️⃣ Блок «Запланировано» — что сейчас в работе и выйдет в ближайшее время. Прежде чем нести фичу в «Идеи», стоит заглянуть туда.

2️⃣ Поиск — если нужно узнать, добавили ли нужные AI-модели или новую ОС в маркетплейсе.

3️⃣ Теги — показывают, к каким сервисам относится релиз.

4️⃣ Фильтр — по месяцам и сервисам, работает и вместе: например, все обновления S3 за июль.

А если следить за релизами удобнее в Телеграме, обновления дублируются в нашем канале @twc_changelog

Заглянуть в журнал обновлений →

QA без рутины: нагрузка, автоматизация, AI и новые инструменты

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

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

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

Нагрузочное тестирование

• 13 августа, 20:00. «Минимум для старта: как провести свое первое нагрузочное тестирование». Записаться

Автоматизация тестирования

• 20 августа, 20:00. «Как ускорить создание автотестов с помощью локальных ИИ‑моделей». Записаться

• 3 сентября, 20:00. «UI и API тестирование с Java и Playwright». Записаться

• 22 сентября, 20:00. «Playwright JS: как быстро начать писать автотесты?». Записаться

• 22 сентября, 20:00. «Автоматизация управления трафиком с mitmproxy». Записаться

ИИ в работе тестировщика

• 2 сентября, 20:00. «ИИ для тестировщика: инструменты, которые уже меняют профессию». Записаться

• 8 сентября, 19:00. «Автотесты 1С через ИИ: от запуска до контроля результата». Записаться

Game QA

• 24 августа, 20:00. «Тестирование игровых уровней: как находить ошибки, которые влияют на игровой опыт». Записаться

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

А если хочется посмотреть на QA шире — читайте материалы:

• «Почему классический подход к QA больше не работает (и виновата ли в этом эпоха ИИ)» — о том, почему качество всё сложнее подтверждать только набором проверок перед релизом и как меняется роль QA в постоянно меняющихся системах.

• «6 ошибок в метриках дефектов, из‑за которых QA теряет контроль над качеством» — о ситуациях, когда дашборды выглядят хорошо, количество багов снижается, а реальное качество продукта при этом может ухудшаться.

Полный список бесплатных уроков августа смотрите в дайджесте.

Подборка материалов: что почитать тестировщику 

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

➡️ Мифы о тестировании

Какие ожидания от профессии расходятся с реальностью и чем на самом деле занимается тестировщик.

➡️ Тестирование верстки

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

➡️ Как начинающему тестировщику выстраивать рабочий диалог в команде

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

➡️ Инструменты ручного тестирования

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

➡️ Как тестировать требования

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

Сохраняйте подборку, чтобы материалы всегда были под рукой ❤️

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

➡️ Playwright 1.62

Появилась новая модель тестирования компонентов — stories и galleries. Теперь можно быстро создавать сценарии с конкретными параметрами и моками, а затем запускать их из галереи. Добавили возможность прерывать долгие операции через AbortSignal. Скриншоты теперь поддерживают формат WebP с разным качеством. Улучшены фильтры тестов и добавлен режим изолированных повторов для минимизации мешающих друг другу тестов. Обновились API браузера и сетевых операций. Debian 11 больше не поддерживается.

➡️ uv 0.12.0

Усилена безопасность и совместимость: теперь запрещены устаревшие форматы архивов и опасные wheel-файлы, способные нарушить виртуальное окружение. Возвращена упаковка проектов по умолчанию с uv_build. Улучшена проверка хэшей зависимостей и работа с сертификатами. Добавлено много новых стабилизированных функций и исправлений.

➡️ Robot Framework 7.5b1

Поддержка документации в Markdown и Google Style форматах облегчает создание описаний ключевых слов. Консольное логирование расширилось — теперь можно использовать собственные логгеры. Появилась возможность запускать тесты прямо из Markdown-файлов. Несколько мелких правок и исправлений.

➡️ Python 3.15.0b4 (бета)

Финальный бета-релиз с важными исправлениями и новинками: ленивые импорты для ускорения старта, новые встроенные типы frozendict и sentinel, усовершенствованный JIT и UTF-8 по умолчанию. Многие мелкие улучшения и большая стабильность.

➡️ FastAPI 0.141.x

Исправлены ошибки с фоновыми задачами и заголовками. Появилась удобная функция app.frontend(check_dir="auto") для быстрой локальной разработки с fastapi dev. Улучшена поддержка SSE и JSONL стриминга.

➡️ Ruff 0.16.0

Значительно расширился набор правил линтинга — теперь по умолчанию включено 413 проверок вместо 59. Добавлена поддержка автоформатирования Python кода внутри Markdown. Добавлены новые форматы комментариев для подавления предупреждений и улучшен вывод исправлений.

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

Лишнее поле в ответе, которое никто не замечает

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

По документации ответ выглядит так:

{
  "traceId": "7c2a8410-56f2-4f59-b921-202607230001",
  "orderId": "ORD-2026-0723-001",
  "status": "CREATED",
  "customerId": "C-1042",
  "pricing": {
    "subtotal": 51960,
    "discount": 5196,
    "total": 46764,
    "currency": "RUB",
    "vatAmount": 0
  }
}

А это то, что реально пришло со стенда:

{
  "traceId": "7c2a8410-56f2-4f59-b921-202607230002",
  "orderId": "ORD-2025-0723-001",
  "stats": "CREATE",
  "customerId": "C-1042",
  "pricing": {
    "subtotal": 51960,
    "discount": 5196,
    "total": 46764,
    "curency": "RU",
    "price": 46764
  }
}

Засеките тридцать секунд и посчитайте расхождения. Девять полей, глазами — ровно так, как это делается в реальной задаче.

⁂

⁂

⁂

Восемь!

1. traceId заканчивается на 0002, а ждали 0001 — ответ пришёл не на наш запрос.

2. В orderId стоит 2025 вместо 2026.

3. Поля status нет: вместо него stats,

4. значение CREATE вместо CREATED.

5. Поля currency нет: вместо него curency,

6. значение RU вместо RUB.

7. Поле vatAmount пропало совсем.

8. Появилось поле price, которого в документации нет.

Все три суммы совпали, и глаз расслабляется именно там, где надо смотреть внимательнее.

В блоке pricing по документации пять полей, а в ответе приехало шестое: price. Сверка по списку из документации его не показывает — по определению: ты идёшь по перечню известных полей, а незнакомого в перечне нет. Плюс значение в нём совпадало с total, так что даже случайный взгляд ни за что бы не зацепился. Разошлись они позже, когда логику расчёта поправили, и к тому моменту это поле уже читал клиент.

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

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

Собирал я это без кода, в своём настольном приложении под Windows. Указываешь путь к параметру, оператор, ожидаемое значение из документации, при желании тип данных — и всё. Запускается руками, из CI не работает, так что если у вас уже есть автотесты и человек, который их пишет, вам это неинтересно, у вас задача решена лучше.

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

Вышел 9-й номер журнала Paged Out (#8 выпустили в июне), который включает в себя различные материалы на тему этичного хакинга и информационной безопасности. Издание публикуется в формате: 1 страница — 1 статья. Все остальные Paged Out выпуски можно скачать с сайта проекта.

Как делать ИПР для сотрудника: 8 правил от эксперта Okko

На QA-days: Оkko, ИнфоТеКС и Piter QA спикер из Okko поделился подходом к формированию траектории развития QA-специалиста через индивидуальные планы развития (ИПР). Доклад поможет выстроить систему, где сотрудники растут с интересом, а не «под кнутом».

Забирай 8 готовых правил в работу.

• Смотреть запись доклада

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

Представлен исследовательский проект STOLEN COMPUTE. Это каталог обнаруженных в сети открытых ИИ-серверов, часть из которых по разным причинам оказалась оставлена без защиты, включая ресурсы с ИИ-моделями Kimi 1T и DeepSeek V4.

Безопасность для «чайников»: зачем обычному тестировщику знать про уязвимости

На QA-days: Оkko, ИнфоТеКС и Piter QA эксперт из Гринатом поделился простыми, но важными вещами: «На волне вайб-кодинга безопасность стала проявлять себя всё ярче. Тестирование безопасности постепенно внедряется в процессы обычных тестеров».

Узнай, как QA может влиять на безопасность продукта.

• Смотреть запись доклада

В нашем TG-канале рассказываем о технических мероприятиях и обсуждаем подборки на технические и ИБ темы.

Адриан Мастронарди (занимается созданием и управлением инженерными организациями, стоящими за выпуском ПО) выпустил книгу под названием «Полсекунды». В ней подробно рассматривается попытка создания бэкдора в xz в 2024 году. Книга распространяется бесплатно под (несвободной) некоммерческой лицензией CC, запрещающей создание производных работ.

Публикации про инцидент с xz на Хабре:

• «Можно ли было обнаружить бэкдор xz при более продуманной работе с пакетами в Git и Debian?»

• «Бэкдор в xz нашли из‑за замедления работы sshd в полсекунды».

Тёмные века в теории тестирования

Всем привет, хочу поделиться некоторым наблюдением над инфополем в тестировании. На мой взгляд, после имперского расцвета мы лет 10-15 как вступили в тёмные века. В начале 2000-х Рекс Блэк и компания знатно потрудились над пропагандой единого глоссария, он стал общеупотребимым и более-менее исчерпывающим.

Если раньше раздробленность в терминологии и классификациях можно было встретить только в тестировании производительности, каждый крупный вендор (Microsoft, IBM, Google) придумывал свою иерархию, то теперь каждая заметная статья и/или перевод оной стремится ввести свой "уникальный" термин. Если в "имперские времена" можно было только у Microsoft прочитать про Capacity testing, за этим просматривалась некоторая логика - вендоры предлагали с терминологией свои фреймворки и подходы - то сейчас все чаще ловлю себя на мысли, что затруднительно сделать вывод о том, зачем совершенно не новаторские процессы описывают новыми терминами. Тем временем многие до сих пор путают integrated и integration...

Может мне кто-нибудь объяснить в чем "shift left" отличается от забронзовевшего раннего тестирования (early testing)? Чем модный концепт "quality gates" не просто набор "exit criteria"? T-shaped модель вполне укладывается один из 7 базовых принципов концепции тестирования - тестирование зависит от контекста, знание контекста (в том числе предметной области) необходимо для составления грамотных тестов.

Примеры можно множить и множить. А как вам кажется, имеет ли смысл кипа новых или относительно новых терминов?

Невидимый балласт: тесты, которые уже мертвы

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

Эксперт из Nexign на QA-days разобрал, как избавиться от балласта: чеклист, метрики и честный разбор ошибок.

• Смотреть запись доклада

В нашем TG-канале рассказываем о технических мероприятиях и обсуждаем подборки на технические и ИБ темы.

Cтaтья «BotSharp изнyтpи: ищeм cлaбыe мecтa в кoдe ИИ‑плaтфopмы нa.NET»

Пpинятo cчитaть, чтo в AI и ML бeз Python никyдa, a.NET — этo иcключитeльнo иcтopия пpo enterprise, вeб‑paзpaбoткy и гeймдeв. Ho пpoeкт BotSharp гoтoв пocпopить c этим cтepeoтипoм, пpeдлaгaя ИИ‑плaтфopмy нa экocиcтeмe Microsoft.

Mы peшили зaглянyть пoд кaпoт BotSharp и пpoвepить, какие ошибки есть в его иcxoдном кoде.

Экс-разработчик Microsoft Дэйв Пламмер показал, как миниатюрная копия двигателя Стирлинга может работать от тепловой энергии, выделяемой компьютером на базе процессора AMD Threadripper.

Элемент, представляющий собой двигатель Стирлинга, размещён на материнской плате в области процессора AMD Threadripper 3970X (32 ядра, 64 потока, архитектура Zen 2). Также можно увидеть, что для создания нагрузки на систему и выработки тепловой энергии используется Cinebench. В результате часть тепловой энергии преобразуется в механическое движение, за счёт чего работает поршень двигателя и вращается маховик.

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

Как собрать тестовый стенд, если опыта нет, а железо разное?

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: каталог, карточки товаров, корзина, оформление заказа, оплата и ошибки на пути пользователя.}

Больше уроков по тестированию, разработке, искусственному интеллекту и не только смотрите в дайджесте.

Пока выбираете урок, обратите внимание на материалы по тестированию:

• Как ИИ меняет работу тестировщика уже сегодня

• Навыки QA-инженера, которые остаются востребованными независимо от инструментов и трендов

• Property-based testing на практике: как находить баги, о которых вы не подумали

• Мы дали ИИ написать код и тесты: что обнаружило мутационное тестирование

Как тестировать связку продуктов, не сойдя с ума?

В этом докладе рассказали, как выстроить «танец команд»: от 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.

Порядок операций в транзакции:

1. free_old_slot(slot1)

2. promoteFromWaitlist(slot1)

3. book_new_slot(slot2)

4. 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.

Слот был свободен. Пациент имел право переноса. Транзакция откатилась.

Механизм

1. free_old_slot(slot1) ← слот доступен

2. promoteFromWaitlist(slot1) ← пациент 2 получил pending на slot1

3. book_new_slot(slot2)

4. move_appointment → slot2 ← appointment пациента 1 ещё на slot1

После шага 2 на slot1 два active appointment одновременно: пациента 1 (ещё не переехал) и пациента 2 (только что из промоушна). UNIQUE constraint one_active_per_slot. Откат. 409.

Транзакция дисциплинированно выполняла логически неверную последовательность — и откатывалась на constraint.

Фикс

Appointment должен покинуть slot1 до того как promote вставляет нового пациента:

1. book_new_slot(slot2)

2. move_appointment → slot2

3. free_old_slot(slot1)

4. 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-канале Тесты как система