Code, maturity, tools: как мы развиваем QA-практики в МТС

Это Алексей Гарцевич, Сергей Чепкасов и Антон Кадников — эксперты в Центре практик направления QA в МТС Диджитал. У нас тысяча тестировщиков, и они работают в совершенно разных условиях и продуктах. В рамках крупной экосистемы приходится прибегать к централизованному развитию QA: оно позволяет компании держаться в одном стеке, накапливать и обмениваться опытом, создавать собственные инструменты и не только. И эта нелегкая задача ложится на наши плечи. Мы помогаем внедрять новые практики, наращивать компетенции внутри команд. В этом посте мы расскажем, что конкретно делаем и как со всем справляемся. В конце покажем, куда приводит такое централизованное развитие технологий и кому оно может быть интересным.

Как мы прокачиваем тестирование во всей экосистеме

Так как МТС — компания большая, развитие технологий идет в ней централизованно. До 2020 года продукты и приложения МТС жили отдельно друг от друга: код практически не переиспользовался, команды слабо взаимодействовали между собой. Решением этой проблемы стал запуск цифровой трансформации и объединение всех в экосистему. Одним из шагов было внедрение методологии Capability Maturity Model Integration (CMMI). Она включает рекомендации и стандарты работы, которые помогают синхронизировать и поддерживать развитие разных направлений деятельности компании (практик).

Этим занимается Департамент управления технологиями aka TechGov, включающий в себя Центры компетенций и Центры практик. Наша команда объединяет функции обоих центров и работает на два фронта: и на обучение коллег, и непосредственно с кейсами, стандартами и процессами.

Наша работа вытекает из общей технологической стратегии и включает пять направлений:

• Помощь с HR-процессами и работа с компетенциями. Мы занимаемся всеми материалами, которые помогают оценивать и отслеживать навыки в QA: разрабатываем матрицы компетенций, тесты для переводов между должностями, помогаем с текстами вакансий.

• Автоматизация процессов тестирования. Например, к нам обратилась команда, которой нужно было внедрять автотесты. Мы помогли им выбрать инструмент и сейчас пилотируем его.

• Тестирование производительности. К нам обращаются, если не знают, с чего начать, и с вопросами по дальнейшему развитию решения. Стек инструментов для нагрузки в командах совершенно разный: Gatling, Jmeter, Locust и k6 — и мы помогаем сразу со всем.

• Обучение. Мы готовим курсы для внутреннего университета, участвуем в программах менторинга. В прошлом году мы провели два курса, куда QA-инженеры могли привести всю команду. Он выступает в роли лида и в процессе курса организует для своего продукта тестирование производительности. Мы по шагам рассказываем, как его проводить, и команды внедряют его под нашим контролем. За три с половиной месяца они получают рабочий процесс тестирования. Эта методика себя показала хорошо — мы внедрили практику нагрузочного тестирования в пятидесяти продуктах. Сейчас записываем этот курс, чтобы запускать потоки с готовыми материалами.

• Координация и оценка работ QA: разработка quality-чеков, quality-гейтов, дефект-менеджмент. Мы актуализируем, улучшаем, ищем точки роста внутри процессов, чтобы они подходили под все продукты.

• Работа с комьюнити: выступаем на конференциях, менторим, отвечаем в чатах на любые вопросы, проводим митапы. Так, в декабре устроили совместный митап с Moscow QA.

Работа с практиками

На уровне компании придумываем, как процесс починить, запустить или оптимизировать, выступаем в роли продакт-оунеров. Например, совместно с коллегами из интеграционной платформы внедряем сервис, который позволяет создавать «заглушки» и выполнять контрактное тестирование на основе спецификаций. Мы развернули инструмент, проверили его работу, провели несколько демо и теперь открыли доступ пользователям.

Сейчас активно работаем над сервисом тестирования производительности: он позволяет автоматически собирать метрики из разных источников, проверять их, формировать отчет о результатах и публиковать его в Allure. Планируем внедрить в него ML-решение для автоматического поиска проблем в метриках по результатам теста производительности и автогенерацию скриптов.

Еще готовим материалы, которые коллеги из продуктов могут применить в работе:

• шаблоны документации, используемые многими командами, — получаем положительные отзывы;

• шаблоны кода для проектов автоматизации и нагрузочного тестирования.

На уровне продуктов к нам обращаются с конкретными вопросами вплоть до починки какого-нибудь застрявшего pipeline. В одной из команд уволился лид тестирования, и мы помогли оставшимся инженерам с их проектом API-тестов. Посмотрели их решение и предложили использовать OpenAPI-спецификацию, чтобы из нее сгенерировать код для автотестов, оценить покрытие тестами OpenAPI-специфики и валидировать относительно нее поведение сервиса.

Часто обращаются за помощью в старте процесса тестирования производительности, и мы отвечаем на вопросы: 

• Как разработать стратегию и создать скрипты?

• Мы провели тест и не можем разобраться в результатах, что делать?

Иногда приходится организовывать тестирование связанных продуктов, когда нужна сложная коммуникация с командами из разных частей экосистемы. 

Основной точкой входа в продукты для нас являются лидеры практик. Это опытные тестировщики, которые общаются со своими командами и внедряют фреймворки и методологии, проводят обучения и преподают на наших курсах. 

Работа с ними идет в двух направлениях: они берут что-то от нас, мы — от них. Например, в одном из продуктов есть своя команда стажирующихся ML-инженеров, которые разрабатывают различные утилиты для тестирования. Мы с их лидером практик решаем задачи автоматизации, генерации заглушек, анализа и предсказания метрик нагрузочного тестирования. И потом планируем использовать на всю компанию. 

Развитие тестирования в продуктах

Существуют разные модели оценки зрелости процессов тестирования, например TPI (Test process improvement) и другие. Можно использовать любые удобные, а в МТС для QA мы выделяем пять уровней: начальный, повторяемый, определенный, управляемый и постоянно улучшаемый. На последнем уровне команды делятся своей экспертизой, рассказывают о своих решениях и выступают драйвером развития практик в компании. 

Для понимания текущей зрелости QA своего продукта необходимо заполнить опросник в отдельной системе: он выдает уровень, и мы его подтверждаем. Затем даем обратную связь, помогаем, советуем дальнейшие шаги развития. Опрос нужно заполнять минимум раз в год, но многие продукты проходят оценку раз в квартал, чтобы держать руку на пульсе и быть актуальным. 

Мир не стоит на месте: практики тестирования постоянно меняются и у нас в компании, и в целом по рынку, поэтому мы поддерживаем опрос в актуальном состоянии и меняем в нем требования. 

Естественно, в большой экосистеме все продукты и сервисы находятся на разных уровнях: им надо помогать и двигать в общем направлении. Да, мы стараемся помочь всем, внедрить что-то новое и полезное, но упираемся сразу в несколько барьеров:

• Так как нас всего трое, а векторов много, то мы везде работаем по чуть-чуть и не хватает времени реализовать все идеи. Из-за этого наше влияние дает результат не сразу, а постепенно. Но по обратной связи от продуктов мы идем в правильном направлении. Мы часто выступаем в роли сервисной команды, но нас мало, мы не можем бросить текущие задачи и помочь всем сразу.

• Разный стек технологий в командах: из-за этого мы должны уметь все и сразу, и очень сложно внедрить общие инструменты.

• Мы работаем в рамках технологической стратегии, которая занимает 25% времени у продуктов, и не навязываем конкретные решения, а подсвечиваем варианты развития. В таком формате любые изменения требуют времени, терпения и сплоченности вокруг людей. Да, мы, как профессионалы, хотим быстрые результаты, но при этом не всегда можем себе их позволить.

• Иногда мы воспринимаемся как внешняя команда. С одними продуктами хорошо взаимодействуем: мы помогаем с их локальными проблемами, а они транслируют свой опыт на всю компанию. А другие, наоборот, могут сопротивляться изменениям: «У нас и так задач много, а тут еще вы со своими идеями». Особенно остро проблема стоит при автоматизации и внедрении нагрузочного тестирования, где требуются узкие компетенции.

Планы на развитие QA в МТС 

Ядром технологической трансформации МТС является цифровая платформа The Platform. Она объединяет все сервисы, которые нужны продуктам в рамках нашей экосистемы, автоматизации и стандартизации решений. Одно из ключевых направлений ее развития — внедрение инструментов на основе технологий искусственного интеллекта (AI). 

Мы вносим свой вклад в развитие The Platform, работая над одной из ее частей — Product Factory Test Tools, где планируем сделать процесс тестирования полностью автоматизированным как раз благодаря AI. Когда в экосистеме будут появляться новые сервисы и продукты или возникнет потребность в текущей тестовой модели, то можно будет загрузить на платформу спецификацию API, а на выходе получить автоматизированные и нагрузочные тесты с автоматическим анализом. В таком варианте любой аналитик cможет накликать кнопки интерфейса и получить готовый тест. В идеальном мире не нужно будет вообще ничего заполнять, так как уже будут готовы инструменты, процессы и метрики для тестирования, управляемые при помощи AI.

Но пока мы только идем к этому идеалу, перед нами стоят конкретные задачи: автоматизация тестирования, тестирование производительности у отдельных команд. Их можно выстраивать под ключ как внешний сервис. Когда в компании много разных продуктов, есть возможность сформировать из опытных специалистов отдельную бригаду для решения сложных задач. Сейчас мы сформировали роадмап развития платформы на 2 года и стараемся его придерживаться. 

Централизованное развитие технологий — это особенность бигтеха. Оно позволяет накапливать и обмениваться знаниями и компетенциями, вместе решать сложные задачи и двигаться в общем направлении. 

А еще благодаря ему появляется запрос на команды инженеров с прокачанными скилами и богатым профессиональным опытом. Эксперты могут повышать техническую зрелость продуктов, обучать коллег, развивать внутренние процессы и инструменты — так и появилась наша команда. Это достаточно необычный вариант карьеры, и он может быть интересен тем, кто не видит себя в тимлидерстве и в одном продукте. 

В МТС направление QA — это не только технологии, но и координация, обучение, обмен опытом. В следующем посте мы расскажем, какие навыки нужны для такого экспертного карьерного трека в QA и почему мы выбрали именно его. На этом у нас все, с гордостью ответим на ваши вопросы.