Привет, читатель Хабра! В этой статье я не собираюсь изобретать велосипед, не планирую напечатать обучающий материал или прямое руководство к действию. Текст, изложенный ниже, всего-лишь мои наблюдения и опыт, который я бережно пронёс с собой сквозь несколько насыщенных лет упорного труда в крупных продуктовых компаниях. Присаживайся, пожалуйста, поудобнее и погнали.

Когда мы говорим про среднестатистическую продуктовую команду или про какой-то продуктовый отдел, мы можем его условно разбить на 2 большие части:

Discovery - это те, кто придумывают что-то
Delivery - это те, кто реализует придумки и доставляет их пользователям

Если между Discovery и Delivery (далее я буду их называть D&D) нет взаимопонимания, или кто-то из них сильно проседает по исполнению своих обязанностей, мы получаем несколько серьёзных рисков:

Продукт может значительно отстать от конкурентов и двигаться не туда (компания теряет пользователей, потому что продукт становится для них нерелевантный);
Продукт начинает проседать в качестве (компания теряет пользователей, потому что никто не хочет пользоваться тормозным приложением, которое не работает нормально);
Продукт теряет связь со своими пользователями (если компания не учитывает желания и потребность пользователей, то юзеры пойдут туда, где их услышат).

Вывод из всего этого один, если нет нормальной работы всего D&D - нет нормальной прибыли компании, нет ресурсов на премии, зарплаты, на новые рабочие места и вот это вот всё. Поэтому бизнес так сильно любит нам рассказывать, что нужно быть вовлечённым в продукт, интересоваться происходящим вокруг и смотреть на свою работу чуть шире, чем базовые скиллы твоей компетенции. И если инженер упорно отвергает и не понимает это желание бизнеса, то скорее всего получит блокер на дальнейший рост внутри компании, оставаясь рядовым работягой (что собственно не является ничем плохим или постыдным).

В этой статье я хочу разобраться в роли QA в процессах между Discovery и Delivery, должен ли инженер по тестированию участвовать как-то в продуктовом развитии проекта, чего ожидает бизнес от современного тестировщика в большой компании и почему больше не получится просто тихо сидеть и тестировать в сторонке, если человек хочет роста? Давай разбираться.

Для начала возьму на себя смелость разделить тестирование на два типа:

Техническое тестирование - это тестирование задач исключительно архитектурного и инфраструктурного характера. Поднятие различных версий библиотек, поднятие версий API, установка новых протоколов, рефакторинг легаси кода. Критерием успешности такого тестирования является технически работающий продукт, который встал в прод;
Продуктовое тестирование - это тестирование продуктовых задач, через призму продуктовых метрик и бизнесовой выгоды. Критерием успешности таких задач является не только технически работающий продукт, поставленный в прод, но и его успешность и востребованность с точки зрения бизнеса.

Я слышу громкий и справедливый вопрос из зала "А причем здесь QA??? У компании есть куча продактов, аналитиков, исследователей и всяких менеджеров! Мне как тестировщику это всё зачем? Моя задача - баги не пропускать!". Согласен, вопрос крайне уместный и возможно QA должен жить в полном отрыве от всего, что связано с Discovery, но давай всё же попробуем посмотреть, чем тестировщик может быть полезен в решении таких вопросов.

Из чего вообще состоит продуктовый цикл разработки? Если упростить то это будет что-то типа:

Самая активная жизнь QA проходит на этапе "Разработка и Тестирование", и в зависимости от процессов в компании может смещаться чуть левее или чуть правее. Поэтому, как правило, QA отлично ориентируется в процессах, которые протекают на этом этапе, и примерно представляют, что происходит на соседних. Большинство команд такой расклад устраивает полностью.

Когда работа QA смещается влево, обычно все ожидают увидеть тестирование требований (атомарность, полнота, отсутствие разночтений, понятность и тд), макетов, подсвечивание рисков на этапе проектирования. Если смещение идёт вправо, то все ожидают участие в релизе фичи, сопровождение ее на проде, мониторинг приборов и общение с саппортом. И оба смещения - это классные практики, которые помогают заткнуть много дыр и отловить самые неочевидные упущения.

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

Идея -> Планирование -> Дизайн

Эти этапы находятся в руках наших креативщиков и придумщиков из Discovery. Если коммуникации между D&D построены прозрачно, то PO или CPO могут проводить встречи с Delievery своей команды, где презентуют инициативы и идеи на квартал или полугодие. Могут быть представлены концепты или результаты исследований, рассказывается какие гипотезы проверяются и на какие метрики ожидается влияние.

В идеальном мире это всё превращается в красиво оформленный Epic в Jira, где есть ссылка на статью в Confluence с описанием боли, гипотезы, планируемых метрик и что вообще делаем (хотя бы верхнеуровнево). Если QA проявляет продуктовую вовлеченность, то он/она обязательно заглянет в эти документы и убедится, что все эти продуктовые метрики там реально присутствуют и они хоть немного обдуманы. Ну а если там пустота, то стоит задать вопрос автору эпика "А точно ли мы понимаем, чего хотим добиться этим решением? Осознаём ли, на что конкретно повлияем? Есть ли вообще понимание того, чем мы будем измерять успешность нашего решения?"

Не стесняйся задавать эти вопросы продактам, исследовател��м, дизайнерам. Даже если они тебе не дают внятных ответов - всё равно спрашивай. Ведь уместный и правильный, вовремя заданный вопрос способен заставить их задуматься или переосмыслить свою идею.

Генерировать нетоксичные сомнения - важная способность QA на всех этих этапах.

Разработка и Тестирование

Перед стартом разработки постарайся убедиться, что:

Команда понимает, на какие события нам надо вешать метрики, а на какие нет. Будет обидно после запуска фичи в прод осознать, что мы не можем корректно замерить сколько и каким образом пользователи пользуются нашей разработкой.
Команда технически готова к запуску нормального продуктового AB тестирования, у аналитиков есть чёткое понимание какие группы должны быть в эксперименте, что именно мы замеряем и что считаем статистически значимым значением.
Проследи, чтобы релизные регламенты были соблюдены и запланированы, в противном случае может произойти оказия, что PO ожидает релиз в конкретную дату, а дата откладывается, потому что команда не запланировала сроки проведения AB тестов и экспериментов.

Тебе, как QA, не нужно быть глубоким экспертом в каждом пункте, лишь только немного побыть совестью команды и продолжать задавать уместные и правильные вопросы про метрики. Можешь попробовать интегрировать лёгкий чек-лист в команде, что-то типа:

Проработаны события и метрики, которые мы будет логировать
Подготовлены и запланированы AB тесты и эксперименты
Назначен ответственный, кто будет проводить AB тесты и эксперименты
У команды есть четкие критерии успешности AB тестов и экспериментов

Я думаю, что PO и аналитики тебе с радостью помогут в разработке такого чек листа

Релиз и Поддержка

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

Итог

На мой взгляд QA инженер, применяя подходы продуктового тестирования, может закрыть сразу две очень важные хотелки:

Улучшение качества продукта. Ведь если D&D совместными усилиями позаботились о метриках и продумали, на что мы хотим влиять - продукт становится более осознанным и хорошо спроектированным. Вплоть до того, что разработчики откажутся от неправильно выбранных технологий и подходов, потому что из-за них могут быть достигнуты неправильные продуктовые цели и метрики.
Увеличение собственного кошелька. Да, мы все работаем за зарплату, а зарплата во многом зависит от владельцев бизнеса. Если каждая новая разработка не будет удовлетворять пользователя и не будет решать каких-то его конкретно измеримых проблем, то денег у бизнеса особо не будет. Значит прощай частые повышения зарплаты, прощай большие премии, прощай новые ставки и расширения отделов. Здравствуй ~~сокращения~~ оптимизации!

Надеюсь тебе было интересно читать эту небольшую статью, а если хочешь что-то обсудить или даже подискутировать - welcome в комментарии или в мой небольшой уютный телеграм чатик по тестированию.

Продуктовое тестирование