Где развернуто окружение: в Docker

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

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

Как отвечать

Опишите конкретный стенд и свою роль в нём:

• устройство: сервисы описаны в docker-compose.yml или стенд живёт в Kubernetes, образы собирает CI, у каждой ветки или релиза свой тег образа;
• что делали сами: поднимали локальную копию docker compose up -d, смотрели состояние docker compose ps, логи сервиса docker compose logs -f api, заходили внутрь через docker exec -it <container> sh, чтобы проверить конфиг или сходить в базу;
• версия под тестом: сверяли тег образа (docker ps, docker inspect) с версией в задаче, иначе баг заводится на старую сборку;
• тестовые данные: база в контейнере с томом (volume), сид-скрипты или миграции для начального состояния, чистый стенд через пересоздание тома;
• автотесты: прогон в CI против поднятого compose, браузеры в контейнерах (Selenium Grid, официальные образы Playwright), Testcontainers для интеграционных тестов.

Если стенд поднимали девопсы, а вы им только пользовались, так и скажите. Но покажите, что можете сами найти лог упавшего сервиса и приложить его к баг-репорту: для QA это главное практическое умение в Docker.

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

Отвечают одним словом «в Docker» и не могут объяснить, из чего состоял стенд и как попасть в логи. Звучит как «окружение было, но я его не видел».

Путают образ и контейнер или не знают, что docker compose down -v удаляет тома вместе с данными. Одна такая команда на общем стенде стирает базу, которой пользуется вся команда.

Заводят баг, не проверив версию сервиса и переменные окружения контейнера. Часть «багов» оказывается старой сборкой или неверным конфигом стенда.