Как была разделена ответственность по микросервисам в тестировании
Что проверяют
Понимаете ли вы, что в распределённой системе тестирование тоже распределяется, и знаете ли, чем закрывают стыки между сервисами.
Как отвечать
Опишите уровни и кто за что отвечает:
- внутри сервиса: модульные и интеграционные тесты пишет команда сервиса, они гоняются в его конвейере и блокируют слияние. Тестировщик участвует в разборе сценариев и крайних случаев;
- контракт между сервисами: контрактные тесты, где потребитель описывает ожидания, а поставщик проверяет, что их не сломал. Это дешевле сквозных прогонов и ловит ровно тот класс ошибок, который возникает при независимых выкатах;
- сквозные сценарии: небольшой набор проверок на ключевые пути через несколько сервисов. Их держат отдельно, потому что они медленные и нестабильные, и владеет ими обычно отдельная команда или тестировщик платформы;
- прод: наблюдение, синтетические проверки, оповещения по метрикам ошибок и задержек. В распределённой системе часть дефектов ловится только так.
Дальше расскажите про организацию: за каждым сервисом закреплена команда, у каждой свои автотесты и своё окружение; общий стенд собирает актуальные версии; при изменении контракта поставщик предупреждает потребителей заранее и держит обратную совместимость на время переезда.
Полезно назвать типичные болевые точки: недоступный смежный сервис ломает чужие тесты, поэтому заглушки; данные, разъезжающиеся между сервисами, поэтому проверка согласованности; дубли сообщений в очередях, поэтому проверка идемпотентности.
Где спотыкаются
Пытаются закрыть всё сквозными тестами и получают долгий нестабильный прогон, которому никто не верит.
Не проверяют обратную совместимость контракта и ломают соседей при выкате.
Считают, что за качество отвечает только тестировщик, хотя большая часть проверок живёт в командах сервисов.