Code, maturity, tools: как мы развиваем QA-практики в МТС. cmmi.. cmmi. qa.. cmmi. qa. автоматизация.. cmmi. qa. автоматизация. Блог компании МТС.. cmmi. qa. автоматизация. Блог компании МТС. Эдвард Де Боно. Серьёзное творческое мышление. Применение творческого мышления. Обучение.. cmmi. qa. автоматизация. Блог компании МТС. Эдвард Де Боно. Серьёзное творческое мышление. Применение творческого мышления. Обучение. платформа.. cmmi. qa. автоматизация. Блог компании МТС. Эдвард Де Боно. Серьёзное творческое мышление. Применение творческого мышления. Обучение. платформа. практики.. cmmi. qa. автоматизация. Блог компании МТС. Эдвард Де Боно. Серьёзное творческое мышление. Применение творческого мышления. Обучение. платформа. практики. продукты.. cmmi. qa. автоматизация. Блог компании МТС. Эдвард Де Боно. Серьёзное творческое мышление. Применение творческого мышления. Обучение. платформа. практики. продукты. сервисная модель.. cmmi. qa. автоматизация. Блог компании МТС. Эдвард Де Боно. Серьёзное творческое мышление. Применение творческого мышления. Обучение. платформа. практики. продукты. сервисная модель. тестирование.. cmmi. qa. автоматизация. Блог компании МТС. Эдвард Де Боно. Серьёзное творческое мышление. Применение творческого мышления. Обучение. платформа. практики. продукты. сервисная модель. тестирование. Тестирование IT-систем.. cmmi. qa. автоматизация. Блог компании МТС. Эдвард Де Боно. Серьёзное творческое мышление. Применение творческого мышления. Обучение. платформа. практики. продукты. сервисная модель. тестирование. Тестирование IT-систем. Управление разработкой.. cmmi. qa. автоматизация. Блог компании МТС. Эдвард Де Боно. Серьёзное творческое мышление. Применение творческого мышления. Обучение. платформа. практики. продукты. сервисная модель. тестирование. Тестирование IT-систем. Управление разработкой. экосистема.
Code, maturity, tools: как мы развиваем QA-практики в МТС - 1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

Автор: ekO_Oo

Источник

Рейтинг@Mail.ru
Rambler's Top100