QA Сhannel

По пятницам скидки 🛍

🧪 50 тестовых сущностей за минуту без Postman Попалась статья на Хабре может быть полезным для QA 👀. Один из вариантов как создать 50 тестовых пользователей за минуту без Postman? Используйте fetch в DevTools браузера: 🔹 DevTools → Console. 🔹 Network → Copy as fetch. 🔹 Запустите цикл. 🔹 Для параллельных запросов — Promise.all. 🚀 Зачем это QA: 👉 Быстрое создание тестовых данных. 👉 Проверка валидации и граничных значений. 👉 Исследование API без лишних кликов. ⚠️ Важно: fetch не гарантирует успех. Проверяйте HTTP-статусы, не запускайте массовые операции на production без разрешения. Итог: фреймворк не всегда нужен. Пара строк JavaScript экономит время. 💬 А вы используете DevTools Console для тестирования API, Postman или что-то еще? #QA #тестирование #API #JavaScript #автоматизация

Лид помогает команде 👌

📊 Allure Report Storage: наконец-то храним отчетики, а не теряем их Знакомая ситуация? Запустили автотесты, получили красивый Allure Report, посмотрели результаты... А через неделю хочется сравнить прогоны, найти начало флака или понять, когда именно поползла стабильность. И тут у некоторых начинается квест: где старый, как открыть его удаленно и с чем сравнивать текущий прогон? В Allure 3 появился официальный Allure Report Storage, который помогает решить эту проблему. Что интересного? 👇 🔹 История запусков. Отчетики хранятся централизованно, их можно открывать удаленно и сравнивать результаты разных прогонов. 🔹 Связка с CI. Allure 3 может публиковать отчеты в хранилище после запуска тестов. 🔹 Свое развертывание. Можно запустить storage в Docker через Docker Compose. 🔹 Гибкость хранения. По умолчанию отчеты сохраняются локально, а при необходимости можно настроить S3-совместимое хранилище. 🔹 Управление историей. Отчетики организуются по репозиториям и веткам. Можно настроить количество отображаемых запусков и удалять ненужные. ⚙️ Как быстро попробовать? Установить Allure 3 и Docker. В статье разобраны настройка Docker, подключение Allure 3, токены, ветки, хранение и удаление отчётов. Есть примеры конфигурации и команд. Подготовить compose.yaml с образом allure/allure-report-storage. Запустить хранилище командой docker compose up -d. Получить токен через API и добавить его в allurerc.js. Включить publish: true для нужного плагина и запустить тесты через Allure 3. После настройки отчёты будут доступны через веб-интерфейс хранилища. 🧠 Зачем это QA? История нужна не только для красивых графиков и презенташек. Она помогает разбираться с флаками, отслеживать тренды стабильности и видеть, как меняется качество продукта от запуска к запуску. А еще это удобнее, чем искать старый HTMLку в артефактах очередного CI jobа. Что важно, storage не исправляет флаки автоматически. Но дает инфру, чтобы системно анализировать историю тестирования. 💬 А как у вас организовано хранение? GitLab Pages, артефакты CI, собственный сервер или уже используете Allure Report Storage? #QA #AllureReport #автотесты #тестирование #DevOps

Врываемся правильно в рабочую недльку 😎

Лучше не делать этого по пятницам 😎

🤖 AI пишет код. А кто ловит баги? Полгода две команды разработки не пишут код руками. Вместо этого AI-агенты пишут код, создают тесты, проводят ревью и даже помогают выпускать релизы. Звучит как мечта: разработка ускорилась, значит, и качество должно вырасти? А вот и нет. Цифры оказались куда интереснее. Автор статьи разобрал 268 багов за год и обнаружил неприятную закономерность: 📈 Кода стали поставлять в 3 раза больше. 🐛 Технических багов на проде стало в 4 раза больше. 👥 Количество тестировщиков осталось прежним. И самое интересное: функциональные дефекты команда по-прежнему ловит достаточно хорошо. Проблема оказалась в другом. 💥 Какие баги стали проскальзывать? Не те, которые легко поймать кликом по кнопке. А инженерные проблемы, которые проявляются под нагрузкой или на стыке сервисов: • гонки и конкурентные обновления, перетирающие данные; • проблемы обратной совместимости при релизах и миграциях БД; • ошибки интеграций, контрактов и обработки ответов соседних сервисов; • неудачные SQL-запросы, индексы и блокировки; • проблемы с нагрузкой, которые сложно воспроизвести на обычном тестовом стенде. На прод уходит примерно каждый шестой функциональный дефект. А из технических два из трёх. И вот здесь привычное «давайте больше тестировать руками» уже не выглядит универсальным решением. 🧪 Что команда делает вместо этого? Выстраивает целую систему проверок вокруг AI-агентов: → генерирует функциональные тесты без моков; → проверяет сами тесты мутациями, чтобы убедиться, что они действительно ловят поломки; → использует статические анализаторы, ArchUnit и проверки БД; → запускает E2E-сценарии на стенде; → проверяет нагрузку и планы запросов; → анализирует метрики, логи и трафик при канареечном релизе. То есть задача уже не в том, чтобы просто написать больше тестов. Нужно научиться ловить те дефекты, которые возникают из-за резко выросшего объёма кода и сложности системы. 🤔 И что теперь будет с ролью QA? В статье есть ещё одна интересная цифра: за квартал количество мерж-реквестов тестировщиков в репозиторий автотестов выросло с 6 до 34. QA всё больше становится инженером, который проектирует проверки, определяет риски и строит систему контроля качества. А часть исполнения делегирует агентам. Но здесь возникает неудобный вопрос. Если код пишет агент, тесты пишет агент, а проверяет себя он тоже сам, кто в итоге отвечает за качество? И можно ли доверять системе, если человек уже не читает каждую строчку сгенерированного кода? Автор считает, что доверять можно, если вокруг агента выстроен правильный инженерный процесс. Но это уже совсем другая модель разработки. 📌 Мой главный вывод: AI ускоряет не только разработку. Он ускоряет и появление ошибок. Если увеличить пропускную способность команды, не изменив стратегию контроля качества, узкое место просто переедет в другое место. Полный разбор читайте на Хабре: «Полгода не пишем код руками. Посчитал, что стало с багами». 👇 Вопрос к QA и тимлидам: вы уже заметили, что с внедрением AI багов стало больше, или пока измеряете только скорость разработки? #QA #AI #AIAgents #автоматизация #тестирование

С началом рабочей недельки удаленщики👨‍💻

Стабильность 🤯

SRE-инженеры, общий сбор 21 октября Т-Банк проведет онлайн-встречу «SRE-техтолк». Приглашают SRE и DevOps-инженеров. На техтолке расскажут: Какие подходы к надежности работают в Т-Банке. Как в бигтехе отслеживают бизнес-операции и автоматизируют дежурства. Какие решения можно адаптировать под свои задачи. Приходите слушать доклады экспертов из разных команд Т-Банка, обсуждать реальные кейсы и проверенные инструменты. Встреча пройдет онлайн, а для инженеров из Екатеринбурга и Новосибирска Т-Банк организует трансляцию в ИТ-хабах. Участие бесплатное. А регистрация тут!

До релиза и после это две разные игры 🎮 До релиза главная задача: быстро доставить рабочий MVP 🚀 Поэтому логично делать ставку на: * быстрые API-проверки * контракты * unit/integration * проверки новых фич * автоматизацию того, что часто меняется Ошибка здесь относительно дешевая: её увидела команда → поправили → поехали дальше. Но продукт выходит в production 🏭 И правила меняются. Теперь баг может увидеть не разработчик, а пользователь 👀 А значит, появляются совсем другие приоритеты: * E2E и реальные бизнес-сценарии * UI/UX * регрессия * обратная совместимость * мониторинг * алерты * стабильность и скорость восстановления В статье это хорошо сформулировано: до релиза вы бежите марафон на скорость, после релиза удерживаете крепость 🏰 😎

Утро доброе 😏

Пирамида тестирования умерла. Просто мы 10 лет делали вид, что не замечаем 📈 Наткнулся на статью с неожиданно простой мыслью. Классическая пирамида Фаулера от 2012 года отвечает на один вопрос: сколько тестов какого типа держать, с акцентом на стоимость и скорость. Но когда на собесе просят "расскажи про пирамиду тестирования", все начинают перечислять unit, integration, e2e, и разговор незаметно съезжает с "сколько и почему" на "какие виды тестов бывают". Это уже другой вопрос, и пирамида на него плохо отвечает. Автор предлагает смотреть на quality checks не как на слои одной фигуры, а через три координаты сразу: этап жизненного цикла, окружение, и что именно проверяется. Шесть этапов по DevOps Infinity Loop: Write → Commit → Build → Verify → Release → Operate. И у каждого свои допустимые окружения: Local, CI, Staging, Pre-prod, Prod. Write происходит только локально. Operate только в проде. А Verify, то есть собственно тестирование, может жить и в CI, и на стейдже одновременно. Что цепляет: проверки идут даже на этапе написания кода, когда ещё ничего не закоммичено. Линтер, статический анализ, подсказки IDE это тоже quality check, просто не "тест" в привычном смысле. Автор специально развёл термины: не каждая проверка является тестированием, и это снимает вечный спор "это юнит-тест или уже интеграционный". Финальная мысль простая, но по делу: чем раньше поймали ошибку, тем меньше шагов до исправления. А отсутствие проверок на каком-то этапе и размытые зоны ответственности это не абстрактный риск, а конкретная дыра, которая рано или поздно вылазит в проде. Полезно не как замена пирамиде, а как дополнение. Особенно когда защищаешь процесс перед командой и нужно показать не просто "у нас есть unit-тесты", а где именно в цепочке что проверяется и кто за это отвечает. Статья

🤖 Кто нашёл больше багов 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. Почитать целиком: [статья] А какие у вас были случаи, когда зелёный негативный тест на самом деле не проверял то, что должен был? Делитесь в комментариях 👇