QA-Логия

В Jira красиво: стори поаппрувлена, спринт собран, релиз висит в календаре. А по факту за одной цифрой прячется такой объем работы, о котором никто даже не заикнулся. И к концу итерации тестировщики внезапно становятся главным бутылочным горлышком. Разобрали семь типовых граблей — как раз на тему того, откуда берется эта разница между планом и реальностью, и что в процессах можно подкрутить, чтобы прогнозы не гаданием на кофейной гуще были. Читать далее 👉 QA-логия

ИИ ускорил разработку. Вот почему прод теперь сыпется чаще Искусственный интеллект реально подстегнул скорость написания кода, а вот механизмы безопасного принятия изменений застряли в прошлом. В итоге имеем: чинные пулл-реквесты, зелёные пайпы тестов и баги, которые вылезают только после деплоя. Статья разбирает, откуда берётся этот разрыв, и какие инженерные guardrails позволяют гнать быстрее, не делая систему хрупкой. Разобраться в рисках 👉 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-логия

⁣Как ответить на вопрос «Что ты делаешь, если не можешь воспроизвести баг?» - и показать уровень мышления middle, а не junior Вчера на собеседовании слышу: «Если баг не воспроизводится - пишу подробный баг-репорт и двигаюсь дальше». Звучит как «я сделал, что мог». Но middle так не думает. Junior обычно говорит: пробую ещё раз, пишу баг с тем, что есть, переключаюсь. Middle отвечает иначе. Невоспроизводимый баг - это не тупик, а зона для исследования. Вот что я делаю на самом деле. Сначала собираю контекст до отказа. Точное время, окружение, версию, данные, последовательность. Скриншоты, видео, логи, console errors. Спрашиваю, что делал до этого - мог ли повлиять другой сценарий. Потом лезу в логи и инструменты. Backend, прокси вроде Charles или Fiddler, логи Sentry - там часто видно ошибку. Ищу аномалии по времени. Дальше пробую граничные условия. Данные с спецсимволами, большие объёмы, состояние системы вроде кеша или сессии, порядок операций, старый браузер, медленная сеть. Формулирую гипотезу и тестирую её. Пишу: «вероятно, баг проявляется при условии X». Делаю 10-20 прогонов подряд. Если всё равно тишина - добавляю пассивные проверки. Чекер в автотесты или мониторинг с тегом «flaky» и описанием. Коммуницирую: «Пока не воспроизвёл, но вот гипотеза, логи, скриншоты. Давайте трекать». Типичная ошибка middle - делать вид, что бага нет. Или закрывать задачу без анализа. Так не работает. Коротко: если баг не воспроизводится - я провожу мини-расследование: анализирую окружение, логи, гипотезы. Если всё равно нет - фиксирую условия, коммуницирую с командой и оставляю задачу открытой с тегом intermittent.

Как автор на Cursor'е запилила отчет по дифференциальному тестированию Авторша раскатывает историю, как она сваяла отчет по дифференциальному тестированию — ну там, где две функции гоняют на одних и тех же данных, а ты смотришь, кто облажался. Раньше на такую хрень уходила прорва времени, а теперь тупой AI за пару минут выплевывает готовый отчет. Может, и тебя этот пример подтолкнет сделать что-то похожее и не париться =)) Читать далее 👉 QA-логия

OpenAI с Антропиком раздают халяву тем, кто вайбкодит — и это прекрасно. 🟢 В Codex поснимали лимиты и убрали пятичасовые ограничения для Plus, Business и Pro. Временно, но кайфуем. 🟢 Fable 5 погостит на платных тарифах до 19 июля. А Claude Code подняли лимиты на 50% аж на неделю. Да будет эта битва Альтмана с Амодеей длиться бесконечно 🙏 👉 QA-логия

⁣Как не слить статус middle в первой же неделе на новом проекте: правила входа в команду для тех, кто хочет расти дальше Ты прошёл собеседование, тебя взяли middle. Поздравляю. Но самое сложное - не дойти до оффера, а не потерять статус в первую же неделю на проекте. Я видел десятки случаев, когда крепкий middle приходил в новую команду и через месяц начинал выглядеть как переросший junior. Почему? Не потому что плохо тестировал. А потому что неправильно вошёл. Вот несколько правил, которые помогут не слить репутацию, а наоборот - закрепить статус и продолжить рост. Правило 1. Не пытайся всех впечатлить в первый день Самая частая ошибка - рваться "спасать проект". Ты хочешь показать, что пришёл профессионал. Но без контекста ты не видишь нюансов: почему баги в проде, почему тесты не покрывают всё, почему команда молчит. Вместо героизма - задавай вопросы. "Почему здесь так?", "Какие риски вы уже знаете?". Middle-мышление - это не "я всё исправлю", а "я сначала пойму". Правило 2. Найди своего "проводника" В каждой команде есть человек, который знает всё: от legacy-костылей до негласных правил. Найди его в первую неделю. Спроси: "Какие три самые опасные зоны в продукте?", "Где теряется время?". Не стесняйся. Middle должен уметь встраиваться в социальную структуру, а не только в код. Правило 3. Не критикуй вслух то, что не видел в работе Ты можешь заметить, что тест-кейсы устарели, документация хромает, баги не воспроизводятся. Сначала проверь гипотезу. Потом спроси: "А это точно так?" И только потом предлагай изменения. Если ты с порога скажешь "у вас тут всё не так" - станешь врагом, а не коллегой. Статус middle держится на дипломатии и фактах. Правило 4. Покажи, что ты умеешь приоритизировать Новый проект - поток информации. Ты не сможешь выучить всё за неделю. Определи: что критично для твоей первой задачи? Флоу главного сценария? Логи багов? Среда? Выбери 3 ключевых фокуса и сделай их глубоко. Легче показать одно качественное исследование, чем пять поверхностных. Правило 5. Задавай "умные" вопросы, а не "детские" Middle-уровень - это не стеснение. Но вопрос "А что это за кнопка?" лучше заменить на "Я вижу этот функционал, но не понял его зависимость от соседнего модуля. Можем разобрать его вместе?". Ты показываешь, что видишь систему, а не экран. Типичная ошибка Вспомни случай: пришёл middle на проект, на второй день нашёл баг в продакшене, побежал к менеджеру с криком "всё плохо". Оказалось, это было известное ограничение, которое команда документировала. Впечатление - сорвано. Уважение - потеряно. Статус - под вопросом. Первая неделя - это не про тесты. Это про контекст, доверие и стратегию. Если ты потратишь её на изучение, а не на доказательства, через месяц тебя воспримут как взрослого специалиста. И тогда статус middle станет не просто званием, а реальным уровнем. Этот подход я проверял на себе и на коллегах. Работает.

⁣Почему ты ушёл с прошлого места? Вопрос, на котором можно запросто потерять оффер. Сижу на собеседовании, всё норм. Потом эйчар спрашивает: «А почему вы ушли?». Ну я и выдал честно — токсичная атмосфера, менеджмент не слышит, микроменеджмент. Вроде правда. Оффер не прилетел. Потом знакомый из той компании сказал: «Ты звучал как человек, который будет жаловаться на любого нового тимлида». И я понял, в чём прокол. Интервьюеру плевать на вашу правду. Ему важно — притащите ли вы эту же драму к нему в команду. Как отвечать, если на прошлой работе реально было болото? Первое. Слово «токсичный» не произносите. Для эйчара это красный флаг: «конфликтный кандидат». Работает формула: «перестал совпадать по подходам». Второе. Смещайте фокус на себя. Лучший ответ: «Я упёрся в потолок. Новые задачи не появлялись. Хочу расти в направлении Х и решать задачи уровня Y». Третье. Если уволили — не врите. Скажите прямо: «Попал под реструктуризацию, команду расформировали. Разошлись хорошо, есть рекомендации». Четвёртое. Критикуйте не людей, а систему. Вместо «начальник был дурак» — «Было много хаоса в приоритетах, задачи меняли каждый день, не хватало структуры». Частая ошибка джунов — рассказывать драму. Собеседование не психотерапия. Чем суше ответ, тем выше шанс. Мой шаблон для QA работает стабильно: «На предыдущем месте я реализовал задачи: выстроил регресс, наладил коммуникацию с разработкой. Дальше рост упёрся в отсутствие сложных интеграционных проектов. Хочу работать с большей неопределённостью и развиваться в нагрузочном тестировании. Поэтому я здесь». Продавайте будущее, не объясняйте прошлое. Говорите, что хотите делать, а не от чего бежите. Тогда оффер ваш.