Как разделены проекты: сервис с библиотеками или общие библиотеки для микросервисов
Что проверяют
Понимаете ли вы, как устроен код, который тестируете, и где в этой структуре живут автотесты. Вопрос задают про ваш прошлый проект, а кандидат может задать его сам работодателю, чтобы понять, где будет писать тесты и кто за них отвечает. Следом обычно спрашивают, как вы узнаете, что обновление общей библиотеки сломало соседний сервис.
Как отвечать
Опишите два типовых варианта и честно скажите, какой был у вас:
- сервис со своими библиотеками: у каждого микросервиса отдельный репозиторий, всё нужное лежит внутри. Юнит- и компонентные тесты запускаются на каждый pull request сервиса, изменения изолированы;
- общие библиотеки: логирование, авторизация, DTO, клиенты к API вынесены в отдельные артефакты и публикуются во внутренний репозиторий пакетов (Nexus, Artifactory, приватный PyPI или npm) с версиями. Сервисы подключают конкретную версию.
Для QA здесь важно вот что. При общих библиотеках один релиз может задеть десяток сервисов, поэтому нужны регрессия по потребителям и контрактные тесты, например на Pact или по схеме OpenAPI. Если сервисы закрепили разные версии библиотеки, поведение расходится, и баг воспроизводится только в одном из них.
Расскажите и про свои автотесты: лежат ли они в репозиториях сервисов или в отдельном проекте, есть ли общий тестовый модуль с клиентами, фикстурами и генераторами данных, как он версионируется и когда тесты гоняются в CI. Если деталей не знаете, так и скажите и покажите, где бы это выяснили: pom.xml, requirements.txt, настройки пайплайна.
Где спотыкаются
Отвечают «этим занимались разработчики». Для тестировщика незнание того, откуда приходит код и как он собирается, означает, что часть рисков он просто не видит.
Путают библиотеку с сервисом: общая библиотека не разворачивается и не имеет своего API, она попадает в сборку каждого потребителя.
Не думают о версиях. Фикс в библиотеке проверили, но сервис остался на старой версии, и в проде баг как будто не чинили.