Тестирование

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

Всем привет, хочу поделиться некоторым наблюдением над инфополем в тестировании. На мой взгляд, после имперского расцвета мы лет 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де.

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

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.

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

Тестирование в 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 на практике: как находить баги, о которых вы не подумали

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

Хотел просто тестировать свои OTP, а выкинул почтовый сервер

Я пилю штуки, где есть регистрация и 2FA. И регулярно упираюсь в одно и то же. Чтобы проверить, что письмо с кодом доходит и парсится на фронте правильно, мне на каждый прогон нужен свежий ящик. Заводить настоящие почты муторно. Сервисы временной почты это отдельная боль: их выпиливают, лимитируют, суют рекламу, а код то приходит через три минуты, когда он уже не нужен, то не приходит вовсе. В какой-то момент надоело.

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

Приёмник почты без приёмника почты

Cloudflare Email Routing бесплатно ловит catch-all на мой домен и отдаёт письмо прямо в Worker, в email()-handler. Не пересылкой на другой ящик, а сырым письмом в код. Ни sendmail, ни Postfix, ни IMAP-поллинга. MX поднимается за меня, я только пишу обработчик.

Дальше то, ради чего я, собственно, и сел писать. Приём держит Email Routing. Доставку готового результата мне в чат держит Telegram Bot API. И то, и другое это инфраструктура, которую я не админю. На выходе рабочий транспорт для входящей почты без единого своего сервера, без SMTP, без IMAP и без своего IP, который можно потерять под блокировкой.

письмо → MX → Email Routing (catch-all) → Worker.email() → разбор → Telegram

По команде /start выдаётся адрес, вставляешь куда надо, письмо падает в чат. Адрес живёт сутки и умирает сам.

Самое интересное это достать код

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

Поэтому не регэксп в лоб, а скоринг. Сначала нормализую тело: срезаю шапки пересылки, невидимый мусор, превращаю Текст <url> в нормальные ссылки, иначе скорер спотыкается об id из урлов. Потом собираю кандидатов: цифровые и буквенно-цифровые последовательности правдоподобной длины, от 4 до 8 символов. И раздаю баллы.

Вверх:

• близость к триггерам: код, code, verification, OTP, подтвержд…;

• стоит на отдельной строке;

• выделен жирным или моноширинным.

Вниз, анти-паттерны:

• похоже на год (19xx/20xx);

• похоже на телефон;

• стоит после заказ/order;

• сидит внутри ссылки;

• рядом знак валюты.

Кто набрал больше, тот и код. Уезжает в первую строку сообщения, тап, скопировал. Вот эта часть и заняла итерации, остальное обвязка.

Честные границы

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

Сервис эфемерный by design. Сутки, и адреса нет. На стороне бота ничего не хранится: письмо разбирается на эдже и улетает в чат, где живёт уже у тебя. Это не замена нормальной почте, а одноразовый ящик под отлов кодов.

Inbound-only. Отправить с него нельзя. Под мою задачу, тестировать собственные флоу, этого ровно достаточно.

И про экономику честно. Лично мне бесплатного тира хватало за глаза. Но KV на free это 1000 записей в сутки, и стоило решить сделать из поделки сервис для братьев по клаве, как квота на записи кончилась. Так что перед тем как открыть доступ наружу, я доплатил за Workers. «На чужой инфре» это правда, но не «бесплатно из воздуха»: транспорт всё равно стоит пять долларов в месяц.

Итог

Завернул в опенсорс: https://github.com/investblog/mailbot. Если тоже гоняешь регистрации и 2FA и устал от рулетки временной почты, может пригодиться целиком. А нет, забирай хотя бы скоринг OTP к себе, он отвязан от Telegram и переносится легко.

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

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

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

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

Тестовое задание для тестировщика 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 (другие переводы)

Как стать ручным тестировщиком?

Освоить профессию помогает не только сухая теория, но и практика. А ещё — понимание инструментов, с которыми тестировщики работают каждый день.

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

— Postman.

Помогает отправлять запросы к API и проверять, правильно ли работает серверная часть приложения.

— Swagger.

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

— Test IT.

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

— Browserling.

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

— Charles.

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

→ Больше курсов на витрине Хабр Карьеры

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-канале.

Веб-поиск и генерация изображений

Развивается не только наша инфраструктура, но и сервисы. Сегодня — про AI-агентов.

За последние три месяца количество активных агентов выросло в 4 раза, а пользователи тратят больше миллиарда токенов в день.

Теперь можно закрывать больше сценариев в одном диалоге: поиск актуальных данных и создание визуалов под запрос.

➖ Веб-поиск

Агент ищет информацию в интернете перед ответом, а вы получаете актуальные цены, тарифы, новости, данные с сайтов. Под капотом — интеграция с Яндексом.

Функция включается в настройках агента. Стоимость — 0,49 руб. за запрос.

➖ Генерация изображений

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

Доступные модели: Gemini 3.1 Flash Image Preview и Gemini 3 Pro Image Preview, они же Nano Banana. Список будет пополняться.

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

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

Использовать новые функции для своих проектов →

Почему тесты проходят, но система всё равно сломана

Классы скрытых ошибок в 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-канале Тесты как система

Как профессиональное сообщество помогает расти — и почему это не про нетворкинг

Первый сезон «Не воспроизводится» заканчивается — и последний выпуск мы решили посвятить не багам и процессам, а людям.

QA часто воспринимают как профессию для одиночек. Но самые важные открытия в карьере случаются не в одиночестве, а рядом с другими. В финальном эпизоде Оля Шнайдер и Сережа Атрощенков поговорили с Юлей Трусовой, QA в BDUI и организатором QA Community в Авито, о том, зачем тестировщику вкладывать время в профессиональные сообщества. Юля не только развивает комьюнити внутри компании, но и победила в Технотексте-8 Хабра со статьёй именно на эту тему — так что разговор получился особенно предметным.

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

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

• Яндекс Музыка

• VK Видео 

• YouTube

• Mave

Обсуждение тем, тренды в 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-канал рассказываем о технических мероприятиях и конференциях, делимся выступлениями экспертов, обсуждаем подборки на технические и ИБ темы.

Когда регрессия уже не спасает: что почитать тестировщику про современный QA

QA больше не живёт в мире, где достаточно прогнать чек‑лист, закрыть пару багов и сказать: «ну вроде работает».

Сейчас тестировщику приходится думать шире: какие ошибки реально блокируют релиз, почему зелёные E2E‑тесты могут ничего не проверять, как flaky‑тесты ломают доверие к CI и где ИИ помогает, а где просто уверенно угадывает.

Начать стоит со статьи «Почему классический подход к QA больше не работает (и виновата ли в этом эпоха ИИ)». Это не очередной текст про «ИИ заменит тестировщиков», а разбор того, как меняется сама роль QA: от проверки готового продукта к работе с качеством на уровне архитектуры, данных, инфраструктуры, процессов и поведения системы после релиза.

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

Читать статью

А чтобы глубже разобраться в отдельных QA‑болях, собрали ещё несколько материалов:

1. «Ты QA и у тебя баги. Какие из них блокируют релиз?»
   _{Практичный разбор для ситуаций, когда до релиза осталось два часа, багов несколько, а чинить всё уже невозможно. В статье — как оценивать дефекты не по страшности описания, а по последствиям: деньги, данные, доступ, личная информация, заявки, отчёты и возможность быстро откатиться.}

2. «5 распространенных ошибок новичка в E2E‑тестах»
   _{Для тех, кто пишет автотесты и не хочет получать зелёный, но бесполезный отчёт. На примерах Playwright разбираются ошибки вроде проверки интерфейса без проверки реального взаимодействия, неправильного ожидания событий, слабых локаторов и опасного использования force.}

3. «Могут ли 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

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