QA Сhannel

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

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

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! 🛡️ Спасибо, коллеги, что делаете продукты лучше 🚀