Привет! Меня зовут Сергей, я в тестировании уже 11 лет и сейчас развиваю качество в компании QIWI. В этом посте я хочу рассказать вам, как сейчас выглядят наши продуктовые команды, куда подевалась роль тестировщика и поделиться некоторыми выводами.
Проблематика прошлого
Когда‑то у QIWI была довольно популярная структура. У нас были отделы разработки, аналитики, тестирования и прочее. Ребята из этих отделов объединялись в проектные команды и занимались проектом.
При этом одной из целей нашей компании — «Поставлять всё возрастающее количество качественных инкрементов, способствующих развитию приоритетных продуктов, не забывая при этом о людях в командах».
И в рамках этой цели у нас в фокусе всегда было две вещи:
Целеполагание. Это некоторые цели, которые мы хотим достигать и трансляция этих целей сотрудникам.
Самостоятельность команд, или по‑другому автономность. Важная штука, ведь мы хотим непрерывные поставки и никто не должен никого сбивать или заставлять ждать. Команда должна уметь отгружать готовый полезный код в любой момент. Никаких барьеров быть не должно.
Но целеполагание и автономность на самом деле являются разнонаправленными векторами. И, если развернуть их в декартову плоскость, получается следующая картинка
Низкая автономность и низкое целеполагание — это уровень «просто заткнись и делай». Никаких трансляций целей, чистая работа.
При высоком целеполагании и низкой автономности руководители уже начинают транслировать в команды наши цели и проблемы, при это указывая, как именно мы будем их решать.
При высокой автономности и высоком целеполагании руководитель фокусирует команду на задачах и проблемах, а команда уже сама решает, что и как будет делать, чтобы достичь результата.
Если автономность будет высокой, но целеполагание низким — это ситуация, когда каждый делает, что хочет.
К тому моменту мы поняли важную для себя мысль «Диалог и совместное движение очень важны для того, чтобы изменения происходили«.
При этом мы очень хотели быть в третьем состоянии, но, к сожалению, мы постоянно двигались между вторым и четвёртым. Почему? С диалогами у нас все было хорошо. В крупных компаниях никогда не было проблем со встречами:‑)
А вот с совместным движением у нас получалась следующая картина. У нас есть отделы, например, отдел тестирования, функция которого — поставлять своих специалистов в проектные команды. Ребята как будто на работу уходят в проектную команду, живут там по своим спринтам, общаются с коллегами по проекту, а иногда возвращаются «домой» в родной цех и обсуждают, что да как было сделано и как можно что‑то улучшить. Знакомая картина?
Получается, у этого сотрудника, с одной стороны, есть цели проектной команды, с другой стороны, у него как у сотрудника отдела тестирования есть цели отдела. У него могут быть свои личные цели. У каких‑то смежных отделов свои цели и прочее. В итоге рождается вот такое разнонаправленное множество векторов, и совместного движения не получалось. Это как на кораблях, которые идут на веслах. Если все одинаково гребут — корабль летит на полном ходу, но если каждый гребет, как хочет — корабль крутится на месте.
Получается, наша проблема как раз и состояла в том, что при текущей структуре с отделами, поставляющих специалистов в проектные команды, мы теряли по целеполаганию. С другой стороны, мы видели, что формирование таких проектных команд давало нам рост автономности, и не хотелось это терять.
Поэтому нашим решением было внедрить культуру продуктовой разработки. Мы трансформировали проектные команды в продуктовые (Product Team) с общим целеполаганием и крутой автономностью, сфокусированных при этом на высоком перфоминге.
Тут у нас вставал вопрос «Что делать с отделами в новых реалиях? Например, с отделом тестирования?».
Продуктовая команда по scrum
Мы сделали самое простое решение. Просто закрыли отдел тестирования, а ребят оставили в продуктовых командах 🙂
Все, больше не надо возвращаться в «цех». Его нет. Теперь твой дом и твоя семья — это твоя продуктовая команда. Было ли это решением проблемы? Отчасти да. Ребята, как и раньше, продолжали работу, просто у них из беклога задач пропали задачи отдела тестирования.
И вроде бы все ОК. Выравнивание по целям улучшилось. Но был еще один момент, который требовал нашего внимания. Какой?
Если мы откроем последнюю версию «Руководство по Scrum» и посмотрим на состав Scrum Team, то мы увидим следующие роли:
Product owner — тут вопросов нет. Кто‑то должен ставить цели продукта и цели спринта.
Scrum Master — куда же без него в Scrum Team?
Developers — очевидно. Кому делать задачи, как не ему.
Иииииии… все… По меркам современных реалий кого‑то не хватает:‑) В классических командах есть тестировщик, а тут его нет. Почему?
Дело в том, что суть продуктовой команды — это фокус всех участников именно на разработке продукта.
И вот с этим фокусом как раз у нас и были две проблемы.
С одной стороны, каждый человек в команде, неважно, какая у него была роль, был сфокусирован больше на своей функции, чем на разработке продукта. Например: я разработчик — я разрабатываю и пишу код. Я тестировщик — я тестирую и ищу баги. Я автоматизатор — я автоматизирую тесты. Я девопс — я готовлю инфраструктуру и подобное. С другой стороны, роли редко залезали в область деятельности друг друга. Вам знакомы ситуации, когда:
Получили ui‑сборку на тестирование. Запустили автотесты — там некоторые локаторы поменялись, и тесты свалились
Или пытаетесь запустить локально новый билд, а он не стартует
Или тестируете какое‑то API, и в ответе приходит код ошибки, без описания, что это за ошибка.
Что тестировщик обычно делает в этом случае? Правильно. Идет задавать вопросы к коллегам, и тем самым может отвлечь человека от важной работы по пустяку. Или будет долго ждать ответа, особенно, если команда распределенная. Все это влияло на перфоманс команды. Иногда даже значительно.
А ведь решения таких мелких проблем зачастую тоже простые:
В случае с API — открыть код и найти эту ошибку, посмотреть описание. С неподнимающимся билдом — проверить логи и какой‑нибудь yaml‑файл с конфигом (вдруг у вас занят порт?). А локаторы можно просто добавить для себя.
Все эти мелкие проблемы могли бы начать легко решаться, если бы участники команды начали развиваться в рамках разработки продукта в целом. И я говорю сейчас не только про тестировщиков, а про все роли в команде.
Тем самым мы могли бы поднять производительность команды еще выше.
Поэтому мы поняли еще одну важную мысль. Организационные решения необходимо подводить под культуру. Полумеры здесь не помогут.
Нам не хотелось оставлять команды в таком виде с этими проблемами. Мы хотели, с одной стороны, развивать T‑shape специалистов, с другой стороны, стремиться изменить фокус человека в команде с я‑функции (я тестер, значит, я тестирую код) на продуктовый подход (я — разрабатываю продукт и несу ценность пользователям.)
Поэтому мы убрали все прочие роли и ввели некую мета‑роль — Product Developer (Продуктовый разработчик). Эта мета‑роль, которой обладают все участники продуктовой команды. Но недостаточно, чтобы каждый человек мог что‑то разработать в продукте, ведь нам нужна команда! А в команде каждый участник имеет сильные и слабые стороны. И то, насколько сильные стороны одного перекрывают слабые стороны другого, и определяет эффективность такой команды.
Поэтому сперва мы начали определять компетенции, которые могли бы пригодиться команде. Их можно представить в виде такой карточки:
И теперь мы могли формировать команды, исходя из тех компетенций и их глубины, что нам нужны. Ага. Нам нужен бек на Java — ОК, ищем такого человека, который будет иметь действительно глубокую экспертизу в разработке бэка на Java.
Или нам нужна экспертиза в девопс. Мы ведь отгружать хотим и перформить. Нужно, чтобы команда умела это делать.
И вот сюда уже логично вырисовывается компетенция кого-то, кто будет работать с качеством. Quality Engineer.
Поэтому следующей нашей задачей стало «Как трансформировать роль тестировщика в компетенцию продуктового разработчика?»
Компетенция QE
Тут сразу напрашивается вопрос. Почему это надо выносить в отдельную компетенцию, а не просто включить все активности в базу продуктового разработчика?
Представляете, вот вы подходите к разработчику, который занят своим делом, и говорите: «Слушай, тестировщиков как отдельной роли теперь нет, поэтому тебе придется самому тестировать, писать тест кейсы, в TMS их заводить. Несколько регрессионных наборов там наберешь. За приоритетом надо будет следить. Поддерживать актуальность тест кейсов. Мы там какой‑нибудь процесс придумаем, стандарт или регламент. Подучишь практики тест дизайна и комбинаторики, чтобы тест кейсы были эффективные».
Представляете лицо этого человека? Какая реакция будет у него? Я не думаю, что первая реакция будет: «Вау! Супер! Я всегда об этом мечтал!». Поэтому нужно было сделать некую компетенцию, которая бы содержала в себе набор всех нужных практик и знаний. И чтобы эту компетенцию осваивали люди, которые к этой компетенции имеют тягу. Тогда у нас получались бы отличные T‑shape специалисты с глубокой экспертизой в качестве и еще по чуть‑чуть в рамках разработки продукта.
Поэтому задача по трансформации роли тестера в компетенцию продуктового разработчика свелась к вопросу: «Что мы должны сюда включить, чтобы, с одной стороны, мы эффективно перфомили, с другой стороны, не было overhead оставшегося от старых практик?«.
Мы подошли к этому следующим образом. Мы посмотрели, ОК, у нас есть наш некий тестировщик. Что может входить в зону его видения, работы или что может ему пригодиться?
Чек листы и тест кейсы. TMS.
Формировать тестовые модели и наборы кейсов под регресс, смок и так далее.
Работа с требованиями.
Участие в релизах (сборка/тестирование/деплой нужное подчеркнуть).
Баговедение.
Автоматизация тестов.
Процессы с разработкой (договоренности, регламенты).
Формирование требований к тестируемости.
Сбивать оптимизм команды.
И получается, вот это все плюс‑минус лежит на его плечах.
Выходит, что если на самом деле на все это посмотреть и все это обобщить, то можно получить некую емкую выжимку из этого набора, такую эссенцию роли тестера. Как если бы мы хотели написать в профиле вакансии.
Атрибуты компетенции QE
Покрытие тестами бизнес‑сценариев пользователей.
Работа с релизами.
Работа с требованиями.
Работа с метриками.
Автоматизация тестов.
Soft skills (уметь договариваться).
Какие‑то вещи можно будет склеить в одно. Например, покрытие тестами бизнес‑сценариев и автоматизацию этих сценариев. Сразу сформировали новый пользовательский сценарий и перевели его в код. И он сразу начал работать в CI. Не надо будет его где‑то отдельно хранить, потом поддерживать связи, эту связь потом обновлять и прочее.
Чем обычно занимается такой Product Developer с компетенцией QE?
Разработка продукта (но только простые фичи, не требующие глубокой компетенции в разработке).
Все вопросы, связанные с ручным тестированием (если оно еще есть или осталось) и приоритезацией целей тестирования. Чтобы достигнуть целей спринта.
Формирование подходов к автоматизации (На каких уровнях покрываем тестами? Что проверяем? Как писать тесты? Обучение команды).
Там, где это необходимо — формирование документации (Под документацией тут подразумевается расширенная информация по продукту. А техническая документация генерируется сама).
Шаринг знаний по тестированию внутри команды, включая практики и подходы
Но здесь нам кое чего не хватает. Чего?
ОК, смотрите. Команда делает продукт. Молодцы. Код поставляется, тесты пишутся и гоняются. И вроде бы команда двигается, продукт развивается. И в каждом моменте времени ребята все делают правильно. Но что будет на временном отрезке, например, год? Где они окажутся относительно начала?
Метрики Качества
Это можно узнать с помощью метрик качества. Мы уже знаем, кто главный судья качества в продукте — это пользователь. И ряд внешних метрик будет завязан на него. Но этого мало. Ведь мы тоже развиваем под капотом свой продукт и процессы его доставки. Внешне для пользователя ничего не меняется, но для нас меняется много. Эти изменения тоже надо отражать.
Поэтому качество для нас определяется внутренними и внешними метриками
Внешние:
Степень удовлетворенности пользователей
% решаемых проблем поддержкой
количество обращений от пользователей
unsuccessful release
новый баги после релиза
Внутренние:
unit test coverage
integrated test coverage
user cases test rate
requirement test coverage
non functional requirements coverage
PASS/FAILURE user cases test rate
problems in backlog
Но метрики сами по себе — это мало. Ведь каждая из них показывает некоторую динамику. А нам хотелось бы завязать их в одно число, чтобы можно было оценить продукт целиком. Поэтому мы ввели понятие — индекс качества, и считается он по формуле
То есть это разница между суммой полезных метрик и суммой негативных метрик.
Другим исловами, все наши усилия, прилагаемые для повышения качества, минус все проблемы, что мы создали. И эта дельта и есть индекс качества продукта.
Но просто внедрить метрики недостаточно. Ведь сами по себе метрики являются просто сигналами, помощниками. Это как ехать на машине. Перед вами есть приборная панель, которая показывает количество оборотов, скорость, количество масла и другое. Если вдруг загорится лампочка «Мало бензина», машина сама не поедет заправляться на заправку. Это решение принимает человек, а лампочка — просто сигнал. Поэтому надо еще научить команду реагировать на эти метрики, и это еще одна обязанность компетенции QE. Не только внедрить метрики, но и научить команду на них реагировать.
Резюмируя
В конце поста я хотел бы подсветить некоторые проблемы, связанные с тестированием, которые появились после трансформации. Куда уж без них?)
Из основных проблем можно выделить следующие:
шаринг знаний (увы, коммуникации между командами может не быть совсем),
шаринг инструментов и подходов(нет коммуникации, привет, велосипеды),
разные фокусы в задачах Product Developer и QE (DEV сфокусирован на создании, а QE — на разрушении, как совмещать это в одном человеке?)
При этом хочется поделиться положительными моментами, которые мы получили после того, как провели эту трансформацию:
Люди в точке, где надо принимать решение, начали принимать решение. Не боятся брать ответственность за решения в продукте.
Больше задач можно отгружать на продуктовые команды. Команды сами переваривают их. Уменьшение оверхеда из прослоек менеджеров
Рост отзывчивости — скорости реакции команд на новые обстоятельства. Адаптивность на максимум.
T‑shape специалисты. (У меня есть интересная мне глубокая экспертиза, при этом я развиваюсь еще по другим компетенциям).
Ребята ассоциируют себя с кем‑то, кто генерируют реальную ценность для клиента. (Я вместе со всеми разрабатываю продукт, но также и помогаю команде с качеством. Обучая их и внедряя полезные практики).
Развитие тестируемости продукта наряду с развитием самого продукта, так как все решения сразу на уровне продукта. Мы разрабатываем продукт и сразу нативные тесты вместе с ним. Почти никаких новых внешних решений. Если задача не покрыта тестами, она не релизится. Это прописано в DoD (definition of done).
Растет уровень запросов команды со стороны качества. Если раньше запрос от разработки в стиле «Я сделал, потестируй». Теперь уже все участники работают с качеством и к QE‑экспертам идут вопросы вида Что покрывать и как? Можешь сделать ревью моих тестов? и т. д.
В своем посте я попробовал показать вам путь, который мы начали, и решения, которые мы принимали. Как и любая дорога, наш путь тоже имеет свои крутые повороты и ямы. Но главное, что он ведет нас к нашей цели. Поэтому все хорошее мы стараемся усилить, а над проблемами стараемся активно работать.
Если у вас есть какие‑то вопросы, пишите в комментариях, буду рад ответить.
