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 инженерам расти. Необходимо понимать тенденции в профессии, привносить идеи, пробовать новое.
