Где развернуто окружение: на виртуальных машинах
Что проверяют
Насколько вы понимаете инфраструктуру, на которой тестируете, а не только интерфейс приложения. Интервьюер хочет услышать, как устроены стенды, кто их поднимает и что вы умеете с ними делать сами. Следом обычно спрашивают, как вы узнаёте, какая сборка сейчас стоит на стенде, и где смотрите логи.
Как отвечать
Опишите свою схему окружений и место виртуальных машин в ней:
- набор стендов: dev, test, stage или preprod, прод. Скажите, какие из них ваши и чем stage отличается от прода по данным и конфигурации;
- на чём живут: виртуальные машины на VMware vSphere, Proxmox или KVM, облачные ВМ (Yandex Cloud, AWS EC2) либо контейнеры в Docker Compose и Kubernetes. Часто это смесь: база на отдельной ВМ, сервисы в контейнерах;
- как попадает сборка: пайплайн в GitLab CI или Jenkins собирает и выкатывает билд, а вы сверяете версию через служебный эндпоинт вроде
/versionили по тегу образа; - что делаете сами: заходите по
ssh, читаете логи черезjournalctl,docker logsилиkubectl logs, перезапускаете сервис, откатываете ВМ на снапшот перед деструктивными тестами; - тестовые данные: как они заливаются и сбрасываются, чтобы прогоны были воспроизводимыми.
Если вы работали только с готовыми стендами, так и скажите, но покажите, что понимаете разницу: ВМ даёт полную изоляцию ОС и снапшоты, но поднимается дольше, контейнер легче и быстрее, зато делит ядро с хостом. Всё чаще встречаются временные окружения на каждую ветку, которые пайплайн создаёт и удаляет сам.
Этот же вопрос полезно задать работодателю в конце: по ответу понятно, будет ли у вас свой стенд или очередь на общий.
Где спотыкаются
Отвечают «не знаю, этим занимались девопсы». Даже без прав администратора тестировщик должен знать, где лежат логи и как проверить версию сборки.
Путают виртуальную машину и контейнер или считают их одним и тем же.
Не упоминают состояние стенда. Баг, который воспроизводится только на грязных данных после чужого прогона, это частая история, и снапшоты или сброс данных её решают.