Как определить, в какой части системы может появиться ошибка
Что проверяют
Умеете ли вы распределять внимание тестирования по риску, а не проверять всё подряд с одинаковой глубиной. Иногда вопрос понимают как локализацию уже найденного бага, поэтому хорошо покрыть обе стороны. Следом обычно просят пример: какой модуль вы сочли рискованным и оказались ли правы.
Как отвечать
Для прогноза опирайтесь на источники риска:
- изменения: что поменялось в релизе, какие задачи и пулл-реквесты вошли, какие модули задеты косвенно через общий код;
- история дефектов: баги кучкуются, и модуль с частыми дефектами в прошлом с большой вероятностью даст их снова. Это видно по трекеру, если баги размечены по компонентам;
- границы и интеграции: стыки фронтенда и API, внешние сервисы, очереди, платёжные шлюзы. Контракт проверяют отдельно, например схемами в Postman или контрактными тестами;
- данные на границах: граничные значения, пустые и очень длинные строки, часовые пояса, валюты, одновременные действия двух пользователей;
- сложность и неясность: запутанные требования и места, где аналитик и разработчик поняли задачу по-разному.
Итог сведите в матрицу «вероятность на влияние» и распределите по ней глубину проверок.
Для локализации бага идите по слоям. Воспроизвели, открыли вкладку Network в DevTools или прокси вроде Charles и посмотрели запрос и ответ. Если ответ неверный, проблема на бэкенде: дальше логи по request id или trace id в Kibana, Grafana или Sentry, затем данные в базе. Если ответ верный, а экран показывает не то, ошибка на клиенте.
Где спотыкаются
Отвечают «ошибка может быть везде, поэтому тестируем всё». Это отказ от приоритизации, а время на тестирование всегда ограничено.
Судят по скриншоту и заводят баг на фронтенд, не взглянув на ответ API. Потом задача гуляет между командами.
Забывают про окружение: разные конфиги, фича-флаги и версии сервисов на стенде и проде. Часть «необъяснимых» багов живёт именно там.