QA Сhannel

🤖 Кто нашёл больше багов AI-агент или человек?

Я бы поставил на человека и не списывал со счетов.
За 11 недель работы с AI-тестировщиком:
🐛 AI-агент - 77 подтверждённых находок
👨‍💻 Человек - только 16
⏱️ Агент отработал 277 часов, человек 213

На первый взгляд разгром.
Но дальше начинается самое интересное.
Агент оказался очень хорош в систематическом переборе состояний, сверке с ТЗ и макетами, анализе API и заглядывании под капот. При этом человек находил то, что агенту пока сложно заметить: визуальные проблемы, неожиданные регрессии и дефекты, которые обнаруживаются только при живом исследовании продукта.
А ещё выяснилось, что примерно 130 кандидатов агента не пережили проверку, а промежуточный подсчёт находок однажды оказался завышен почти вдвое.
То есть вопрос оказался не в том, «кто лучше тестирует, человек или AI?»

Гораздо интереснее:
👉 где агент действительно эффективнее человека?
👉 какие задачи дают ему максимальную отдачу?
👉 сколько на самом деле стоит AI-тестировщик?
👉 какие баги он пропускает?
👉 и можно ли вообще считать его заменой QA?

В статье приведены замеры за 11 недель, методика подсчёта, экономика, примеры найденных и пропущенных дефектов и выводы о том, где AI действительно приносит пользу QA.
Читайте на Хабре 👇
#QA #AI #AIAgents #Тестирование #Automation #ClaudeCode

Доброго понедельничка!

20 проверок API 📋. Мы юзаем половину, называем это «тестированием», и удивляемся, когда прод падает 📉.

Попалась статья на Хабре - разбор про 20 конкретных проверок для одного эндпоинта заказа.
Решил пройтись честно: что из этого у нас реально в привычке, а что мы молча пропускаем.

С чем согласен полностью:
Статус-код + структура + типы + значения + бизнес-логика это база, но именно расчёт total независимо от ответа API, а не по формуле из того же ответа, часто упускают. Проверять сумму так, как её вернул сервер, это не всегда тест, иногда тавтология.

Отдельная проверка на «нет закрытых полей» в ответе (password_hash, внутренние ID) мало у кого в чек-листе, хотя это прямая рекомендация OWASP. Обычно про это вспоминают уже после security-аудита, а не до 🔓.

Идемпотентность и повторный DELETE казалось бы, база базовая, но многие тестируют happy path один раз и не проверяют, что будет при повторе запроса после обрыва соединения. А в проде именно так и происходит.

С чем не согласен или дополнил бы: то, что автор предлагает проверять BOLA и BFLA (чужие объекты и чужие роли) как отдельные пункты 14-16. Согласен, но я бы вынес это не в общий список из 20, а в обязательный security-чеклист, который прогоняется для каждого нового эндпоинта отдельно. Это слишком критичная зона, чтобы теряться между «граничными значениями» и «идемпотентностью».

Момент про retry/polling для асинхронных операций (202 Accepted) описан хорошо, но не хватает конкретики про таймауты сколько ждать, прежде чем считать тест упавшим. На практике команды либо ждут слишком долго (тест на 30 секунд ради проверки одного заказа), либо слишком коротко и ловят false negative на нормальном async-переходе.

И ещё: список сфокусирован на одном сквозном REST-сценарии. Отдельно жаль, что не затронуты webhooks (хотя в разделе «куда копать дальше» упомянуты), но на практике именно повторная доставка событий и нарушение порядка чаще всего ловится постфактум, а не на этапе тестирования.

Что реально годится взять как чек-лист:
Таблица в конце статьи как удобный формат для ревью тест-кейсов, которую стоит адаптировать под свои нужды. Можно сверяться, особенно с middle-специалистами, которые ещё выстраивают привычку проверять не только happy path.

Сколько из 20 у вас реально в привычке, а не только в теории? Особенно интересно, кто уже гоняет idempotency-тесты на постоянку, а не только «когда вспомнили» 🔁

С Днём QA! 🛡️
Спасибо, коллеги, что делаете продукты лучше 🚀

Негативный тест. Зелёный. Баг всё равно в проде 🐛
Знакомая история: метод должен отклонять quantity: 0. Передали ноль, получили 422, тест прошёл, галочка поставлена ✅.

А потом выясняется: сервис прекрасно создаёт заказ с нулевым количеством. Просто в тесте вместе с quantity подставлялся случайный productId, которого нет в базе. 422 прилетел из-за отсутствующего товара, а до проверки количества дело вообще не дошло 📉.

Попалась статья на Хабре про эту проблему, и оказывается она системная, а не разовая случайность 📊. Мы меняем несколько полей, ждём любой 4xx, и считаем, что валидация работает. А запрос мог остановить кто угодно: API Gateway, парсер JSON, просроченный токен, вообще другое бизнес-правило 🚧.

Разбирается там несколько практических моментов:
- почему невалидный запрос лучше собирать из валидного, а не с потолка 🧱
- почему в одном тесте стоит нарушать только одно правило 🎯
- почему 422 не равно 409, и "любой 4xx" на самом деле ничего не доказывает 🤷‍♂️
- почему одного статус-кода мало, и нужен стабильный код ошибки в теле ответа 📝
- и главное: как проверить, что после ошибки система действительно не поменяла состояние: заказ не создался, остаток не изменился, событие не улетело в очередь 🔒

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

Почитать целиком: [статья]

А какие у вас были случаи, когда зелёный негативный тест на самом деле не проверял то, что должен был? Делитесь в комментариях 👇

От разовых промптов к повторно используемым AI-флоу в QA🤖

AI в тестировании это уже не только про "напиши мне 10 тест-кейсов по требованию"

Гораздо интереснее другой подход, а именно превратить удачные промпты в повторяемые рабочие процессы.

В новой статье на Хабре, как использовать AI в QA на практике:

🔹 анализировать требования и находить противоречия, пробелы и неоднозначности
🔹 генерировать test coverage, test cases и чек-листы
🔹 превращать фрагменты переписки и существующие баги в новые bug reports
🔹 анализировать логи, метрики и данные из разных источников
🔹 искать информацию в Jira, Confluence и других системах обычным языком
🔹 разбирать legacy-логику, когда документации уже почти нет

Но главный фокус статьи не на отдельных промптах

Prompt → Skill → MCP → Context

То есть от одноразового запроса постепенно переходим к полноценному AI workflow, который можно использовать снова и снова...

Например, один раз настроить для анализа требований, подключить MCP к Confluence и дальше получать структурированный QA-анализ уже для новых задач, без копирования огромного промпта каждый раз

При этом есть важное уточнить сразу что AI не заменяет QA-инженера. AI может забрать рутину, но результат всё равно нужно проверять и апровитьь через человека.

👉 Статья на Хабре: «От разовых запросов к повторно используемым ИИ-флоу в QA»

Если вы уже используете нейроночки в тестировании, особенно интересно сравнить такой подход с тем, как это устроено у вас😉

Три фреймворка, три архитектуры, один и тот же вопрос на каждом планировании: что берём? 🤔

Selenium не знает контекст приложения, общается через внешний WebDriver, отсюда Thread.sleep(3000) во всех легаси-проектах. Cypress живёт внутри браузера, топовый DX, но cross-domain переходы (SSO, платёжки) до сих пор боль. Playwright сразу строился под современный веб: auto-waiting, изолированные контексты, mocking из коробки. ⚡️

Самое интересное — во что выбор выливается через год. Посчитал на примере: команда с 3000 тестов на Selenium теряет четверть ставки инженера в неделю просто на разбор флаков. Playwright это лечит архитектурно, но миграция 3000 тестов — это не спринт, а 10+ недель на двух стеках одновременно. Про эту цену молчат в 90% сравнительных статей. 📉

Вывод простой: вопрос не «что лучше», а «что соответствует вашей системе и сколько вы готовы заплатить временем за архитектурный выигрыш».

Разбор с кодом, схемами и расчётами: [https://habr.com/ru/articles/1073646/]

А у вас был случай, когда выбор фреймворка на старте аукнулся через год?

Мысли, посетившие моих коллег, которые вроде бы старые, но не теряют актуальности))

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

Но в финтехе цена ошибки может быть не время, а деньги.

Как пример — сломанный или кривой диплинк в уведомлении о резком росте цены, и трейдер не успел закрыть позицию.

Не просто мелкая багулька. А чья-то реальная потеря.

Поэтому маленьких или неважных вещей не бывает. И даже диплинк уже не просто URL, а контракт между бизнесом и пользователем.

А задача тестировщика в этом всём — не только проверить, что «ссылка работает», но и заметить продуктовые конфликты. Например: что важнее в конкретном сценарии, безопасность или удобство?

В итоге тестирование не только чек-лист. Это ещё и умение думать о продукте и пользователе.

Работа, которую никто не замечает, пока она сделана хорошо.

Знакомо? 😉

Креативный подход

Последнее время стало заметной проблемой у меня и моих коллег лидов. Мы всё чаще замечаем одну неприятную закономерность, чем активнее команды внедряют AI, тем больше «невидимой» работы появляется у тех, кто отвечает за качество.

И это очень похоже на то, что описывает автор статьи на Хабре.

ИИшка действительно ускоряет разработку. Код появляется быстрее, ревью закрываются быстрее, задач в спринте становится больше. На дашбордах всё красиво. Но появляется нюанс, кто-то должен проверить, что всё это действительно работает. Поймать глюки AI + написать и прогнать нужные сценарии. Разобраться, почему автотест зелёный, а поведение системы нет. Увидеть риски. И задать тот самый неудобный вопрос "А мы точно хотим это?"😂

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

В статье автор называет это проблемой невидимого валидатора, когда инженеры постоянно доводят результат AI до состояния Готово в Prod и становятся невидимками в команде. Для QA это особенно знакомая история. Мы можем ускорить генерацию автотестов с помощью AI. Можем быстрее анализировать требования, создавать тестовые данные, писать чек-листы.

Но скорость генерации ≠ качество проверки
И если после внедрения AI у команды стало больше результата, но вместе с ним выросло количество ручной валидации, ревью, разборов и «разруливания» последствий, то возможно, мы просто перенесли стоимость работы из одного места в другое и добавили затраты на токены 🤖

Автор предлагает четыре идеи, которые, на мой взгляд, отлично ложатся и на QA:

👉 Закладывать валидацию в capacity, а не считать её «ну это же просто проверить»

👉 Измерять не только найденные дефекты, но и предотвращенные проблемы

👉 Распределять экспертизу. Если все сложные проверки постоянно делают одни и те же QA/лиды команда становится зависимой от нескольких людей

👉 Передавать проверки разным членам команды, а не оставлять её постоянно на одном и том же тестере. Решая проблему по трансформации специалистов в постоянный quality gate и подтягивая остальных)

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

Мне кажется, QA сейчас особенно важно обсуждать не заменит ли AI тестировщиков?, а: кто будет проверять работу AI, как мы будем оценивать эту работу и как не превратить самых сильных QA в бесконечный слой ручной валидации заменив поиск багов за разрабчиками, в поиск за ИИшечкой

А у вас уже появилось ощущение, что после внедрения AI работы стало меньше на бумаге, но больше в реальности?

Хороших выходных 👽

Пу пу пу

Playwright ни в чем не виноват 😂

Попалась годная статья про миграцию с Selenium на Playwright: статья на Habr
Главный тезис очень знакомый: команды мигрируют не тесты, а способ мышления, который годами формировался вокруг WebDriver.
Фреймворк новый, а голова старая 😄

Особенно узнаваемые анти-паттерны:
→ Thread.sleep(2000) после каждого шага «на всякий случай». Хотя Playwright сам умеет ждать, пока элемент станет доступен для действия.
→ Общий BrowserContext на класс тестов вместо нового контекста на каждый тест. В Java приходится контролировать самому ошибся, и получаешь флаки, которые потом неделями списывают на «инфраструктуру».
→ Логин через UI в каждом тесте вместо storageState. 500 тестов = 500 прокликиваний формы логина. И достаточно поменять форму и падает полсьюита.
В статье таких ошибок семь, плюс чек-лист из 15 пунктов.

И цифры там вполне реальные: в одном из кейсов E2E-прогон сократили с 35 до 7 минут.
Понравилась и честная оговорка автора: большинство этих практик вообще-то не эксклюзив Playwright. То же самое можно сделать и в Selenium просто там многое приходится собирать и дисциплинированно поддерживать самому.
Короче, при миграции недостаточно заменить WebDriver на Playwright.
Нужно ещё заменить мышление 😅

Кто уже мигрировал с Selenium на Playwright сколько из этих семи ошибок нашли у себя?
И какая оказалась самой болезненной?

требуется тестирование 😎

Прокачивал слабые стороны 5 лет. Фатальная ошибка 😂

Есть исследование, которое переворачивает всё, что нам говорят на курсах и тренингах «как стать тимлидом».

Если у вас низкий балл по компетенции, например, по стратегическому видению, и вы вложите месяцы, чтобы подтянуть её для восприятия вас как лидера, это не изменит вообще ничего. Ноль. Вы просто стали чуть менее плохим. А «чуть менее плохих» тысячи. 📉

Зато если взять то, что у вас УЖЕ хорошо получается, и докрутить до выдающегося уровня, кривая лидерства взлетает вертикально 🚀.

Для QA-лидов это особенно больно читать, потому что мы обожаем работать над слабостями. Плохо доносите статус до менеджмента? Идём на курс презентаций 🎤. Не умееете управлять конфликтами? Читаем книжку 📚. А по факту, если у вас уже топовая экспертиза и команда реально видит, что вы шарите глубже всех в продукте, то усиление именно этого куда мощнее, чем закрытие многих пробелов 💪.

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

Практический совет из статьи, который реально можно применить сегодня: спросите у команду не «что мне улучшить», а «вспомни момент, когда я повлиял на нас так, что результат оказался лучше, чем мы ожидали, и что именно я тогда делал» ✨. Ответ покажет вашу реальную суперсилу, а не список того, что вам вежливо посоветуют подтянуть.

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

Статья полезна, если ведёте команду или метите в QA Lead, но и для понимания своего лида. Может, он не «плохой менеджер», а просто управляет через должность, потому что другого рычага у него пока нет. А может, у него как раз есть та самая суперсила, просто вы её не замечали, потому что искали идеальность по всему и сразу 🔍.

Ребята выложили свой фреймворк для тестов на Go, буквально 60 тысяч уникальных тестов на 500+ сервисов, боевка, которая уже несет реальную нагрузку внутри компании 🚀. Идея понятная так как Go отличный язык для сервисов, но из коробки для больших e2e-сценариев его стандартная библиотека скудновата. И иногда веселая организация в сьюты) Раньше чинили через Allure-Go, но фреймворк и отчётность оказались настолько склеены между собой, что расширять стало больно 😖. Решили переписать с нуля и сразу модульно 👍🏻.

Что реально цепляет в реализации: так это Testo не тащит зависимости, только стандартная библиотека 🛠. А плагины подключаются буквально через встраивание структур:

type T struct {
    *testo.T
    *allure.PluginAllure
    *PluginParallel
}

Написал плагин один раз и вот у тебя уже автомат для всех тестов, без копипасты и разноса по каждому файлу. Отдельно понравилась параметризация: тест принимает параметры, а фреймворк сам прогоняет все комбинации и в Allure это разъезжается на отдельные тесты с понятными названиями. Ноль магии, чистый Go ⚡️. И вишенка на торте — хуки BeforeAll/AfterAll в стиле "включили печь перед сменой, выключили после" 🔥. Вроде игрушечный пример, а на деле ровно то, что нужно для настройки инфраструктуры перед тяжёлым regression-прогоном 💪.

Ссылка на репозиторий (он открыт) в статье, лицензия Apache-2.0, а документация и примеры на месте 📚. Кто пишет автотесты на Go сталкивался с болью от "мало отчётности из коробки", или у вас уже был свой велосипед под это? 🤔