Могли ли создавать или изменять данные в базе данных на тестовом стенде

Что проверяют

Какой у вас уровень работы с базой: умеете ли вы сами подготовить данные для проверки или каждый раз просите разработчика. Заодно проверяют аккуратность, потому что тестовый стенд обычно общий. Следом часто просят написать запрос с JOIN или спрашивают, почему вы правили данные напрямую, а не через API.

Как отвечать

Опишите свой реальный уровень доступа и практику:

• права: только чтение или запись тоже, и через какой клиент: DBeaver, DataGrip, pgAdmin;
• что делали: SELECT для проверки результата операции, INSERT и UPDATE, чтобы получить редкие состояния: заблокированного пользователя, просроченную подписку, заказ в промежуточном статусе;
• API против прямой записи: по возможности данные создают через API или интерфейс, тогда отрабатывает вся бизнес-логика. Прямая запись нужна для состояний, до которых через продукт идти долго или невозможно, и здесь важно помнить о связанных таблицах и ограничениях;
• безопасность правок: сначала SELECT с тем же WHERE, потом изменение внутри транзакции BEGIN и проверка числа затронутых строк до COMMIT;
• общий стенд: свои записи помечаете узнаваемым префиксом, чужие не трогаете, после тестов убираете за собой;
• автотесты: данные готовят фикстуры и фабрики, а изолированную базу поднимают в контейнере или восстанавливают из дампа.

Пример лучше взять свой: какой сценарий без правки базы проверить было нельзя и что вы для этого сделали. Если доступ был только на чтение, так и скажите и расскажите, как получали нужные состояния через API и какие запросы писали для проверки. Если SQL пока слабое место, честнее это признать и назвать, что вы уже умеете.

Где спотыкаются

Выполняют UPDATE или DELETE без WHERE или с неверным условием на общем стенде. Даже если это не прод, работа коллег встаёт.

Создают вручную состояние, до которого система сама никогда бы не дошла, и заводят на него баг. Разработчик закрывает его как невоспроизводимый, и доверие к вашим дефектам падает.

Копируют на стенд боевые данные с персональной информацией без обезличивания. Это уже риск нарушить закон о персональных данных, а не просто неаккуратность.