Телеграм канал «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 работает стабильно: «На предыдущем месте я реализовал задачи: выстроил регресс, наладил коммуникацию с разработкой. Дальше рост упёрся в отсутствие сложных интеграционных проектов. Хочу работать с большей неопределённостью и развиваться в нагрузочном тестировании. Поэтому я здесь».

Продавайте будущее, не объясняйте прошлое. Говорите, что хотите делать, а не от чего бежите. Тогда оффер ваш.

Слушай, если твой пайплайн тормозит, это почти никогда не из-за одной гигантской проблемы. Чаще всего драгоценные минуты просто незаметно сжирает мелочь: сдохший кэш, жирные образы, тупые очереди и циклические зависимости между джобами. Всё это по капле высасывает время, пока ты не замечаешь.

Давай разберем шесть классических идиотских ошибок при настройке GitLab Runner. И главное — как самому найти это узкое место, пока твоя команда не смирилась с двадцатиминутными сборками и не начала ставить чайник при старте.

Читать далее
Habr

👉 QA-логия

⁣Как отвечать на вопрос «Какие книги по тестированию вы читали?» и не потерять баллы на собеседовании даже без списка литературы

Вопрос «Какие книги по тестированию вы читали?» - ловушка. Не потому что интервьюер хочет проверить начитанность, а потому что проверяет твоё отношение к профессии.

Я сам провалился на этом. Сказал честно: «Ни одной не прочитал, всё изучал на практике». Потерял баллы. Понял почему: интервьюеру нужен был не список, а сигнал о системном подходе к росту.

В чём суть вопроса? На собеседовании (middle и выше) это проверка: интересуешься ли профессией вне работы, способен ли структурировать знания, умеешь ли учиться у опыта других.

Как отвечать, если книг не читал? Худшее: сказать «нет» и замолчать. Лучшее: честно признать и объяснить, как учишься иначе.

Шаблон ответа:
- честность - «Книг от корки до корки не прочитал, это моя зона роста, но я компенсирую это другими способами»
- альтернативы - «Читаю статьи и доклады на Хабре или YouTube по конкретным проблемам. Например, при внедрении API-тестов изучил кейсы коллег. Прохожу курсы с домашкой - это даёт структуру»
- конкретика - «Из книг открывал «Как тестируют в Google» и «Путь к изучению тестирования» по ситуациям. Планирую изучить «Тестирование ДОТКОМ» Криспина для agile-контекста»
- рефрейминг - «Для тестировщика важнее умение задавать вопросы и критическое мышление. При тесте нового функционала я сначала разбираюсь в бизнес-логике, а не в техниках из книги»

Почему работает? Показываешь осознанность: не читал, но знаешь о книгах. Даёшь равноценную замену: практика, статьи, курсы. Уходишь от обороны в диалог.

Типичная ошибка - врать. Опытный интервьюер легко прощупает: спросит детали, и ты поплывёшь. Лучше честно признать пробел и показать его осознание.

Совет: прочитай хотя бы одну прикладную книгу. Например, «Тестирование программного обеспечения» Савина. Не целиком, главу про техники тест-дизайна, чтобы привести живой пример.

Книги не самоцель. Цель - системное мышление и желание расти. Если книг нет, покажи, как растёшь иначе. Честность плюс аргументация дают контроль над мячом.

А вы сталкивались с таким вопросом? Как отвечали?