В Купер.тех много микросервисов, интеграций и сценариев, которые завязаны друг на друга. Поэтому тестирование здесь редко ограничивается проверкой одной фичи: важно понимать, как изменение поведёт себя в системе целиком и что будет под нагрузкой.
В мини-интервью Арсений Лагутин, руководитель обеспечения качества тестирования, рассказал, как в большом e-commerce-продукте подходят к QA:
👉 Проверяете ли вы отдельные сервисы изолированно или чаще тестируете пользовательский путь целиком?
Основной объем нашей системы представляют собой микросервисы. Подход и уровни тестов зависят от задачи, модулей системы, которые она затрагивает или влиянию на пользовательский путь. Новую реализованную фичу в ветке стараемся проверять на изолированном окружении для сохранения гигиены master. Здесь же запускаем изолированные функциональные и интеграционные автотесты. Далее, при необходимости, проводится ручное интеграционное тестирование и Е2Е, а также приемочное на production или stage окружениях.
👉 Какие инструменты и подходы используете для автоматизации тестирования?
Тут у нас «сборная солянка». Для автоматизации используем Golang, Python, JS (Detox) и TS (Playwright). Определяем уровни автоматизации под потребности системы и команды, а зону ответственности делим между QA и разработчиком. Автоматизируем в рамках своей предметной области и стараемся запускать прогоны на каждое новое изменение сервиса. Автоматизацией занимается QA в продуктовой команде, а не отдельный департамент. За счет глубокого знания тестируемой области повышаем эффективность автотестов и стараемся привлекать разработку для разбора упавших автотестов в рамках создаваемых ими изменений.
👉 Как вы понимаете, что система готова к высоким нагрузкам и «переживёт» сезонный пик?
Ориентируемся на цели бизнеса прежде всего. Основным фактором для нас является ожидаемое число заказов. В компании имеется инструменты для проведения нагрузочного тестирования как на stage, так и на production окружениях изолированно для сервисов и Е2Е (в связке) на отдельных тестовых сущностях. Нагрузочное тестирование проводим на регулярной основе и в рамках валидации крупных изменений. Успехом является соответствие ожидаемой выдерживаемой нагрузки относительно бизнес-целей и реальной, полученной на production-окружении. В случае отклонений анализируем, проводим оптимизации и повторяем, пока всё не будет хорошо работать.
👉 Насколько QA вовлечён в продуктовые решения?
QA подключаем к ранним этапам SDLC. Для нас это окончание Discovery, когда продукт сформировал свое видение задачи и оформил по нему ожидания. Из-за отсутствия формализации требований не проводим классического анализа, а вместе с командой разбираемся, как задача должна работать технически, какие есть риски и какой подход выбрать.
Так удаётся заранее заметить, где ожидания продукта могут расходиться с техническими ограничениями или логикой системы. В итоге часть ошибок мы ловим ещё до разработки, а значит быстрее и дешевле доводим задачу до релиза.