Зачем это спрашивают
Это кейсовый вопрос, и он проверяет сразу две вещи. Первая — техническая: умеете ли вы систематически искать, чем ваши условия отличались от условий разработчика. Вторая — командная: как вы ведёте себя в ситуации, когда вашу находку ставят под сомнение. Интервьюер хочет услышать спокойный план действий, а не обиду и не капитуляцию.
Ситуация «у меня работает» случается в любой команде. Почти всегда это не значит, что кто-то ошибся. Это значит, что в репорте не хватило какого-то условия — и задача тестировщика его найти.
Как построить сильный ответ
Покажите, что вы начинаете с себя и с фактов, а не со спора. Удобная структура — четыре шага.
1. Повторить самому
Сначала убедитесь, что баг повторяется у вас на актуальной сборке. Возможно, его уже починили попутно другим исправлением. Если ошибка исчезла, это тоже результат — его нужно зафиксировать.
2. Искать разницу в условиях
Пройдите по списку того, что могло отличаться:
- Стенд и сборка — тот же ли сервер, та же ли версия фронтенда и бэкенда.
- Клиент — браузер и его версия, расширения, размер окна, устройство и версия ОС для мобильных.
- Аккаунт и данные — роль, права, история действий, конкретный товар или заказ. Часто ошибка проявляется только на определённых данных.
- Состояние клиента — кэш, cookie, localStorage. Проверьте в окне инкогнито или после очистки данных сайта.
- Последовательность и темп — порядок шагов, двойной клик, быстрые действия подряд, медленная сеть.
- Время — истёкшая сессия, смена суток, часовой пояс.
3. Собрать доказательства
Видео с экрана, запросы и ответы из вкладки Network с включённым Preserve log, HAR-файл, ошибки из консоли, точное время воспроизведения. По времени и идентификатору запроса разработчик найдёт записи в серверных логах.
4. Обновить репорт и договориться
Дописать найденные условия в предусловия и шаги, приложить артефакты. Если остались сомнения — предложить разработчику созвониться на пять минут и пройти шаги вместе на одном стенде. Это часто быстрее любой переписки.
Если баг плавающий
Слова «воспроизводится иногда» ничего не дают разработчику. Нужна частота числом и условия попыток: «3 из 10 попыток, Chrome, один и тот же аккаунт, между попытками страница перезагружалась». Помогает простая таблица попыток — по ней видно закономерность.
| Попытка | Аккаунт | Действие | Результат |
|---|---|---|---|
| 1 | новый | обычный темп | ок |
| 2 | новый | двойной клик по кнопке | ошибка |
| 3 | старый | обычный темп | ок |
| 4 | старый | двойной клик по кнопке | ошибка |
Здесь уже видна гипотеза: ошибка связана с двойным кликом, а не с аккаунтом. Такую гипотезу стоит записать в репорт отдельно от фактов.
Пример ответа
Сначала я сам повторяю баг на актуальной сборке — может, его уже исправили. Если повторяется, ищу, чем мои условия отличаются от условий разработчика: стенд и версия сборки, браузер, аккаунт и его данные, состояние кэша и localStorage, порядок и скорость действий. Проверяю в инкогнито, чтобы исключить кэш. Затем собираю доказательства: видео, запросы из Network с Preserve log, HAR, ошибки консоли и точное время, чтобы разработчик нашёл записи в логах. Найденные условия дописываю в баг. Если ошибка плавающая, указываю частоту числом, например три из десяти, и веду таблицу попыток, чтобы найти закономерность. А если остаются вопросы, предлагаю пройти шаги вместе на одном стенде — это быстрее переписки.
Частые ошибки
- Спорить и переоткрывать баг с комментарием «посмотрите внимательнее» без новых фактов.
- Сразу соглашаться и закрывать баг, не проверив условия.
- Писать «воспроизводится иногда» без частоты и условий попыток.
- Забывать про данные: проверять на своём аккаунте, когда ошибка была на другом.
- Не фиксировать время и запросы — потом сопоставить с серверными логами невозможно.
- Подменять факты догадками о причине в шагах воспроизведения.
Пример на MarketCove
Допустим, в учебном магазине MarketCove вы завели гипотетический баг: после входа в аккаунт в профиле не отображается последний оформленный заказ. Разработчик отвечает, что у него всё видно. Как можно действовать:
- Повторить на текущей сборке. Учесть, что заказы и аккаунты в магазине хранятся в памяти сервера, — после перезапуска сервера ваши данные могли исчезнуть, и это нужно отличать от ошибки.
- Сравнить условия: оформляли ли вы заказ гостем, а потом вошли, или сразу под аккаунтом. Это два разных сценария, и разработчик мог проверять второй.
- Проверить состояние клиента: токен и корзина лежат в localStorage. Повторить в чистом профиле браузера.
- Открыть вкладку Network, обновить страницу профиля и найти запрос, которым она получает данные пользователя и его заказы. Сверить, с каким токеном он ушёл и что вернул сервер, например:
GET /api/users/me HTTP/1.1
Authorization: <заголовок с токеном из localStorage>
Если в ответе сервера заказ есть, а на экране нет — это повод смотреть на клиентскую часть; если в ответе заказа нет — на серверную. Подробнее об этом разборе — в статье фронтенд или бэкенд.
- Дописать в репорт сценарий (гостевой заказ, затем вход), приложить HAR и время.
Задание для практики
Выберите в MarketCove любой сценарий, например выход из аккаунта и повторный вход или отображение статуса заказа после его смены, и составьте для него список условий, которые могут отличаться у вас и у разработчика: не меньше восьми пунктов по категориям из раздела выше. Затем пройдите сценарий десять раз, меняя по одному условию, и заполните таблицу попыток.
Отдельно потренируйтесь собирать артефакты: включите Preserve log, сохраните HAR после оформления заказа и найдите в нём нужный запрос. В этом помогут квесты по DevTools. Полезно также перечитать, из чего состоит баг-репорт, — большинство случаев «не воспроизводится» начинается с пропущенных предусловий.
