Телеграм канал «QA-Логия»

⁣Вчера на созвоне с лидом обсуждали баг, который я нашёл ещё две недели назад. Критический — падает оплата в мобильном приложении. Но его до сих пор не починили. Почему? Потому что я просто кинул его в трекер с заголовком «Ошибка при оплате через Google Pay». И всё. Разработчик посмотрел, сказал «воспроизвести не смог» и закрыл. А я даже не уточнил, на каком устройстве тестировал, не приложил видео, не указал шаги до авторизации и версию Android.

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

А пара месяцев назад коллега нашёл похожий баг — и уже через неделю его пофиксили, а коллегу назначили старшим тестировщиком. В чём разница? Он умеет «продавать» баги.

Что значит «продать» баг? Это не про то, чтобы врать или приукрашивать. Это про то, чтобы донести ценность бага до всех участников процесса. Для разработчика: показать чёткие шаги, окружение, логи, скриншоты. Для менеджера: объяснить влияние на пользователя и бизнес. Например: «При оплате Google Pay падает — теряем 15% конверсии на этапе checkout». Для продукт-оунера: указать, какие сценарии блокируются и какой процент пользователей может столкнуться.

Типичная ошибка junior-тестировщика — думать, что баг-репорт нужен только разработчику. Нет. Это документ, который продаёт важность проблемы всей команде. Если вы просто кидаете баги, как в чёрный ящик, то быстро становитесь «тем, кто находит кучу мусора». А нужно становиться «тем, кто спасает релиз».

Что я изменил в своём подходе? Добавляю контекст бизнеса. В каждом баг-репорте пишу, на какую функциональность влияет и сколько пользователей может задеть. Пример: «Баг ломает сценарий быстрого заказа для 30% новых пользователей». Прикладываю доказательства. Видео, логи, снимки экрана — обязательно. Если баг редкий, пишу частоту воспроизведения (1 из 10 попыток). Прогнозирую последствия: «Если не починить до релиза, в продакшене получим всплеск жалоб в поддержку и потерю дохода». Общаюсь с разработчиком до отправки. Уточняю, что он уже знает, чтобы не дублировать. Спрашиваю, нужна ли дополнительная информация.

Результат? Разработчики перестали закрывать мои баги с пометкой «не воспроизводится». Менеджеры начали включать мои баги в список критических задач. А через три месяца меня повысили до middle с расширением зоны ответственности.

Находить баги — база. Уметь их продавать — навык, который отделяет junior от middle и выше. Потому что ваша ценность не в количестве найденных дефектов, а в том, как вы помогаете команде приоритизировать и решать проблемы.

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

Contract testing на Pact в 2026: как перестать латать интеграции после того, как всё упало

В статье разбираемся, как Pact закрывает дыру между модульными и E2E‑тестами, как работают consumer‑driven контракты, Pact Broker и команда can‑i‑deploy, и что важно запомнить, чтобы контрактное тестирование реально блокировало несовместимые релизы, а не плодило ещё одну головную боль.

Читать далее: https://habr.com/ru/companies/otus/articles/1058382/

👉 QA-логия

ИИ для QA: готовим критерии приёмки без километровых мучений

Йо, народ! Я Марго, QA из команды МС в Банки.ру. Этой весной мы с пацанами запилили автоматизацию написания Acceptance Criteria через AI. Теперь вместо тупой рутины — бах, и тестирование летит быстрее.

Все подробности выкатили на Хабре: Тыкай сюда

👉 QA-логия

Кажется, digital снова меняется быстрее, чем мы успеваем это осознать.

На днях Amazon Ads встроил кнопку «Добавить в корзину» прямо в пульт от телевизора. Теперь купить товар можно буквально во время просмотра фильма или сериала — без поиска сайта и переходов. Похоже, борьба за внимание закончилась. Началась борьба за одну кнопку.

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

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

Здесь можно почитать подборки, обзоры, реальные кейсы и идеи, которые помогают смотреть на digital и IT немного шире.

Сохранить подборку себе 📨

Если хочешь развиваться в машинном обучении — решать реальные бизнес-задачи или уйти в исследования — в Центральном университете есть магистратура под оба сценария. И на нее можно получить грант до 75%. Места ограничены, дедлайн подачи заявок — 20 августа.

«Машинное обучение» — это направление с несколькими форматами и треками. В офлайн-формате (пары по вечерам и в выходные в центре Москвы) можно выбрать один из трех треков:
⚫️Индустриальный — сильная база в ML, современные инструменты, реальные задачи от партнеров
⚫️Научный (AIRI × ЦУ) — сложные модели, исследования, подготовка к аспирантуре и работе в передовых лабораториях
⚫️ML в электронной коммерции × Lamoda — работа с реальными данными Lamoda, применение ML для бизнес-задач и возможность попасть на стажировку в компанию

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

Магистратура в Центральном университете — это 2 года обучения, которое можно совмещать с работой, и диплом государственного образца. Карьерная поддержка начинается еще во время учебы: консультации, тренировочные собеседования и помощь с трудоустройством. Студенты уже в процессе обучения выходят на новые позиции или повышаются в грейде в Яндексе, Авито, Т-Банке и других компаниях.

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

В 2026 году доступно 550 грантов на все программы магистратуры. Подробнее о программах и условиях участия в конкурсе — по ссылкам

➡️Офлайн программа
➡️Онлайн программа

⁣Как ответить на вопрос «Что ты делаешь, если не можешь воспроизвести баг?» - и показать уровень мышления middle, а не junior

Вчера на собеседовании слышу: «Если баг не воспроизводится - пишу подробный баг-репорт и двигаюсь дальше». Звучит как «я сделал, что мог». Но middle так не думает.

Junior обычно говорит: пробую ещё раз, пишу баг с тем, что есть, переключаюсь. Middle отвечает иначе. Невоспроизводимый баг - это не тупик, а зона для исследования. Вот что я делаю на самом деле.

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

Потом лезу в логи и инструменты. Backend, прокси вроде Charles или Fiddler, логи Sentry - там часто видно ошибку. Ищу аномалии по времени.

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

Формулирую гипотезу и тестирую её. Пишу: «вероятно, баг проявляется при условии X». Делаю 10-20 прогонов подряд.

Если всё равно тишина - добавляю пассивные проверки. Чекер в автотесты или мониторинг с тегом «flaky» и описанием.

Коммуницирую: «Пока не воспроизвёл, но вот гипотеза, логи, скриншоты. Давайте трекать».

Типичная ошибка middle - делать вид, что бага нет. Или закрывать задачу без анализа. Так не работает.

Коротко: если баг не воспроизводится - я провожу мини-расследование: анализирую окружение, логи, гипотезы. Если всё равно нет - фиксирую условия, коммуницирую с командой и оставляю задачу открытой с тегом intermittent.

Как автор на Cursor'е запилила отчет по дифференциальному тестированию

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

Может, и тебя этот пример подтолкнет сделать что-то похожее и не париться =))

Читать далее

👉 QA-логия