Был ли прямой доступ к базе данных
Что проверяют
Умеете ли вы проверять не только интерфейс, но и данные, и понимаете ли риски работы с базой напрямую. Заодно смотрят уровень SQL: следом почти всегда идёт задача на запрос.
Как отвечать
Скажите, был ли доступ, к какой среде и зачем он использовался. Важнее всего показать сценарии, где без базы никак:
- подготовка данных: создать нужное состояние (пользователь с истёкшей подпиской, заказ в редком статусе), которое через интерфейс собирать долго или невозможно;
- проверка результата: убедиться, что операция записала именно то, что нужно, включая поля, которых нет на экране;
- локализация дефекта: понять, на каком шаге потерялись данные, ошибка на фронте, в API или в базе;
- проверка миграций и фоновых задач: что после выкатки данные не поехали.
Обязательно скажите про осторожность: на бою доступ либо только на чтение, либо его нет вовсе, изменения делаются на тестовом стенде, персональные данные не выгружаются, а перед update и delete пишется select с тем же условием. Это ровно тот ответ, который ждут от зрелого тестировщика.
Полезно добавить, что предпочтительнее готовить данные через API, а не запросами: так не обходятся бизнес-правила и не появляется состояние, невозможное в реальной работе.
Уровень SQL стоит обозначить честно: соединения, группировка, подзапросы, оконные функции, если владеете.
Где спотыкаются
Отвечают просто «да, был» и не приводят ни одного сценария.
Рассказывают, как правили данные на проде, без тени сомнения. Это красный флаг.
Готовят тестовые данные запросами в обход приложения и потом ловят дефекты, которых в реальности быть не может.