QA Lead в Miro отвечает за стратегию качества большой части продукта, реализацию крупных инженерных инициатив и развитие QA-инженеров.

Я как Head of QA расскажу о зонах ответственности QA лида, но прежде кратко расскажу о наших структуре разработки и процессе обеспечения качества, потому что это даёт понимание основных принципов работы.

Интро: структура разработки и процесс обеспечения качества в Miro

Вся продуктовая разработка поделена на направления — стримы. Все стримы кросс-функциональные и кроме разработчиков в стримы входят и другие функции: аналитика, маркетинг, продакт, дизайн. Каждый стрим развивает часть продукта, объединённую общей идеей. Например, Growth стрим — это команды, которые работают над ростом продукта. Или Platform стрим — команды, которые разрабатывают публичную платформу и SDK. Есть стрим Stability and Scalability, команды в котором создают инструменты для доставки, инфраструктуры и обеспечения качества. Здесь разрабатываются системы для автотестирования. Все QA лиды и инженеры пользуются результатами работы этого стрима.

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

Например, практически с каждой Scrum командой работает выделенный QA инженер, который руководствуется ценностями Agile-тестирования:

"Testing throughout over testing at the end". Тестирование — это не дополнительный этап, а часть каждого этапа разработки.

"Preventing bugs over finding bugs". Процесс обеспечения качества в первую очередь направлен на предотвращение ошибок, а не на их эффективный поиск. Но это не значит, что процесс поиска ошибок нужно исключить.

"Testing understanding over checking functionality". Мы в первую очередь обеспечиваем качество продукта, а не только производим проверку на соответствие требованиям. 

"Building the best system over breaking the system". У нас нет цели найти все ошибки — мы фокусируемся на предотвращении и поиске важных. Ошибки, что встречаются крайне редко, можно пропустить, потому что их поиск будет очень дорогим.

Все предыдущие пункты не будут системно работать, если в команде только один QA инженер думает о качестве — нужна командная ответственность за качество. Поэтому у QA инженера две главные роли: напарник тимлида и технический эксперт. В роли напарника QA инженер помогает строить качественный процесс разработки. В роли технического эксперта — учит разработчиков всем видам тестирования, помогает проводить сложные функциональные и нефункциональные тесты, даёт необходимые инструменты и обеспечивает команду необходимой инфраструктурой для проверки.

Подробнее процесс обеспечения качества описан в статье.

Зоны ответственности QA лида

QA Lead в Miro отвечает за стратегию качества большой части продукта, реализацию крупных инженерных инициатив и развитие QA-инженеров.

QA lead как стратег

QA лид отвечает за стратегию качества в стриме. Для этого он напрямую работает с Head of Stream Engineering и Head of QA.

Работает с Head of Stream Engineering

Вместе с Head of Stream Engineering QA лид определяет видение процесса разработки в части качества в перспективе минимум на год — что нам нужно сделать, чтобы достичь цели бизнеса. Head of Stream Engineering отвечает за техническую сторону достижения целей бизнеса: масштабируемую архитектуру, предсказуемую разработку, масштабирование команды (найм) и, конечно, качество продукта. 

В данном случае обеспечение качества — это не дополнительная работа, которая удлиняет t2m, это, наоборот, история про сокращение издержек. Мы хотим уделять время фичам, но тратим много времени на исправление ошибок — нужно сделать так, чтобы мы не порождали ошибки. Мы хотим, чтобы добавление кнопки заняло один день, а это занимает три недели из-за легаси в коде — нужно устранить сложный код, так как в него невозможно быстро и качественно вносить изменения. То есть при должных ограничениях качества, единственный способ ускорить t2m — это сразу делать качественнее. Этот вопрос и решает QA lead в связке с Head of Stream Engineering.

Работает с Head of QA

Однако есть не только бизнес цели стрима. Есть принципы качества, единые для всех стримов, потому что мы работаем над одним продуктом. Есть эффективные подходы и инструменты, которые можно использовать всеми стримами для экономии ресурсов. Это всё задает видение стратегии обеспечения качества на уровне компании. Head of QA помогает QA лидам совместно определять принципы и подходы.

QA lead как Project manager

Часто для решения технических инициатив в рамках всей компании формируются кросс-функциональные команды, проектным менеджером в которых становится QA лид.

Реальные примеры таких проектов:

• Обеспечить 80% покрытия тестами на разных уровнях;

• Уменьшить втрое стоимость ответа на тикеты для команды поддержки;

• Провести исследование доверия метрикам;

• Улучшить качество релизных веток на Х;

• Внедрение JS test framework для non-Canvas команд.

QA lead как People manager

Есть цели компании, цели стрима, цели QA команды. Задача лида — транслировать эти цели каждому участнику команды, чтобы каждый сотрудник понимал ценность решаемых задач и то, как они приближают нас к целям. 

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

Чем ещё занимается QA lead

Он проверяет на прочность всё вокруг.

Процесс планирования и его контроль. Например, команда на квартал берёт больше фичей, чем может произвести, или не учитывает время на технический долг или исправление ошибок. Это увеличивает t2m, снижает качество и свидетельствует о проблемах в процессе планирования и контроля.

Архитектура. Архитектура может не позволять покрывать код тестами из-за сильной связности. Это не дает гарантий надёжности изменений.

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

Создание и тестирование инфраструктуры для новых сервисов. Инфраструктура-как-код не отличается от любого другого кода и должна покрываться тестами и тестироваться нефункционально.

Тестовые окружения. Это часто сложная техническая область, где нужно строить удобные тестовые окружения для деплоя и проверки своей версии приложения.

CI/CD в части выполнения тестов всех уровней. Если получение результатов е2е тестов занимает более 10 минут, разработчик переключает контекст на другую задачу, а это порождает издержки.

Тестирование на проде. Важно, чтобы это был действительно полезный эшелон защиты, например, chaos monkey testing. Большая проблема — когда используется тестирование на проде, потому что раньше не получается.

А также: 

• Нефункциональное тестирование и его автоматизация;

• Канареечные релизы и процесс анализа пропущенных до прода ошибок;

• Релизы и действия на проде;

• Мониторинг вышедших фичей и компонентов;

• Инциденты;

• Health monitoring.

Вывод

QA лид в Miro — это в первую очередь человек с системным мышлением, который измеряет текущее состояние качества со всех сторон (качество продукта, процессов разработки, техническое качество), определяет видение и создаёт стратегию как направленное движение к видению.

Это человек, который проверяет на прочность всё вокруг: процесс планирования и его контроль, архитектуру, тестовые окружения, релизы и действия на проде, инциденты, тестирования на проде, health monitoring и многое другое. 

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

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

Это People менеджер QA инженеров стрима, который помогает QA инженерам расти. Необходимо понимать тенденции в профессии, привносить идеи, пробовать новое.