Использовали ли Docker в работе и базовые моменты его использования

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

Можете ли вы сами поднять окружение для тестов, не дожидаясь DevOps. Интервьюеру важно, различаете ли вы образ и контейнер и справитесь ли с упавшим сервисом на стенде. Следом обычно спрашивают про Docker Compose или про то, как достать логи из контейнера.

Как отвечать

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

Базовые понятия и команды:

• образ и контейнер: образ это неизменяемый шаблон из слоёв, собирается по Dockerfile; контейнер это запущенный экземпляр образа со своим процессом и файловой системой;
• запуск: docker run -d -p 8080:80 -e ENV=test --name app image:1.4.2. Проброс портов, переменные окружения, конкретный тег вместо latest;
• диагностика: docker ps -a, docker logs -f app, docker exec -it app sh для входа внутрь, docker inspect для сети и переменных;
• данные: без тома всё внутри контейнера исчезает при его удалении, базу держат на -v или именованном томе;
• Compose: docker compose up -d поднимает приложение, базу и брокер по одному compose.yaml. Команда пишется через пробел, старый docker-compose на Python больше не развивается.

Где это нужно тестировщику: развернуть нужную версию приложения по тегу и воспроизвести баг; запускать браузеры для автотестов в контейнерах, например selenium/standalone-chrome или официальный образ Playwright; поднимать базу в интеграционных тестах через Testcontainers; в GitLab CI задавать окружение через image: и services:.

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

Называют Docker виртуальной машиной. Контейнер делит ядро с хостом, это изоляция процессов, а не отдельная ОС.

Внутри контейнера обращаются к localhost, ожидая попасть в соседний сервис. В Compose к другому сервису ходят по его имени в общей сети.

Тестируют на latest и потом не могут сказать, на какой версии нашли баг.