Расскажите об опыте работы с OpenShift и модернизацией
Что проверяют
Насколько тестировщик самостоятелен рядом с инфраструктурой. От QA не ждут администрирования кластера, ждут бытовой уверенности: поднять и обновить тестовый контур, посмотреть, почему упал под, встроить автотесты в конвейер, не ждать неделю чужой помощи. Вторая часть вопроса про модернизацию проверяет, понимаете ли вы, что изменилось в процессе тестирования после переезда.
Как отвечать
Сразу честно обозначьте глубину: вы пользователь кластера OpenShift или сами его настраивали. Дальше по делу: как разворачивали окружение в своём проекте, где лежат конфигурации и секреты, как читали логи и события пода, как пробрасывали порт до сервиса, как откатывали версию, где брали тестовые данные.
Про модернизацию расскажите через до и после. Было: общий стенд, очередь за окружением, ручная выкладка, невоспроизводимые дефекты. Стало: отдельное окружение под ветку, прогон тестов в конвейере, предсказуемая версия сервиса под проверкой. Полезно назвать, что вы как тестировщик добавили: проверку готовности сервиса перед стартом сценариев, отдельные данные под прогон, перезапуск упавших по инфраструктуре тестов.
Если сталкивались со спецификой платформы, скажите об этом: работа через oc, маршруты вместо привычного входного контроллера, устаревающий формат описания деплоя.
Где спотыкаются
Пересказывают чужой опыт: перечисляют систему сборки, мониторинг и графики, хотя сами их не настраивали. Пара уточнений про то, где смотрели события пода и как разбирали бесконечный перезапуск контейнера, это вскрывает мгновенно.
Не отличают OpenShift от обычного Kubernetes и путают команды и сущности. Достаточно сказать, что знаете разницу и работали через штатный клиент платформы, чтобы вопрос закрылся.
Не могут сказать, что изменилось в самих тестах. Переезд в кластер обычно приносит новые нестабильные падения: сценарий стартует раньше готовности сервиса, два стенда делят одну базу, миграции не успели пройти. Именно это от QA и хотят услышать.