Релизить нельзя фиксить. Чего ждет бизнес от QA

22 сентября в Санкт-Петербурге прошел митап по тестированию VK Bug Talks, где выступил с докладом CEO Test IT Артём Кострюков. Он рассказал, как бизнес, проходя через этапы жизненного цикла, пересматривает приоритеты в QA и как это отражается на скорости разработки и взаимодействии с пользователями. Делимся его докладом с вами.

Основная задача любого коммерческого предприятия — получение прибыли. На нее можно повлиять разными способами, но основных два: повышение выручки при неизменных затратах и снижение затрат при неизменной выручке. Так или иначе прибыль зависит от:

• Качества продукции, связанного с удовлетворенностью клиентов

• Скорости выпуска продукции (time-to-market)

• Снижения затрат на жизненный цикл ПО

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

Как бизнес понимает роль QA

Тестирование ПО вносит вклад в экономические показатели бизнеса. Согласно исследованиям, QA отвечает за качество продукта, положительный пользовательский опыт и сокращение скорости вывода продукта на рынок.

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

• Shift-left предполагает перенос контроля качества на ранние стадии жизненного цикла продукта, начинается с этапов анализа, прототипирования, проектирования интерфейсов, построения пайплайнов, окружений, разработки и тестирования. 

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

• Shift-right заключается в переносе тестирования на более поздние стадии разработки и подходит для команд, у которых большие объемы данных и сравнительно небольшие риски при протечке дефектов на прод.

Сдвигаясь «направо», используют канареечное тестирование и сплит-тесты, большая аудитория разделяется на когорты. Эта методология позволяет положиться на обращения пользователей в техподдержку или на бета-тестеров. 

Можно сказать, shift-right стремится к post-production testing. Здесь важно наличие продуктовой аналитики, большого количества трафика, множества активных пользователей, на которых можно проверять свои фичи, и т. д.

Фазы развития бизнеса 

Есть четыре основные фазы развития бизнеса, через которые проходит каждая из бизнес-моделей: Proof of concept, Startup, Scaleup и Enterprise. Разберемся, на каких этапах QA путешествует «слева направо» и наоборот.  

Proof of concept

На этой стадии разрабатывается прототип продукта, который позволяет оценить жизнеспособность задумки. Нужен ли QA на этом этапе? Рано! Зачастую лучше быстро разработать рабочий вариант концепции и сразу запустить его на рынок. Основная задача прототипа — как можно быстрее отработать критический happy path. 

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

Так тестировали прототипы в далеких двухтысячных годах. Тем не менее proof of concept сработал отлично — Instacart одним из первых стал единорогом. Если бы на том этапе разработчики решили написать бэкенд, то в скором времени потратили бы первые деньги и закрылись.

Startup

Это вторая ступень. На нее заходят, когда уже набиты шишки и прототип работает — вы получили первое подтверждение от рынка, что все не зря. В этот момент необходимо сосредоточиться на трех основных задачах:

• Минимальный жизнеспособный продукт. Выработать его — главная из трех задач стартапа. MVP, minimum viable product, фокусируется на фичах, которые удовлетворяют ключевые потребности пользователей. Это три или четыре проблемы, которые помогает решить ваша разработка. 

• Приемлемый пользовательский опыт. Не стоит выпускать продукт с вырвиглазным дизайном, но важно вовремя остановиться: откажитесь от темной темы — это дополнительная разработка, которая потребует денег, сил и времени. 

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

На этапе стартапа важно максимально быстро проверять гипотезы ценности, аудитории и платежеспособности: насколько важно то, что вы делаете, кому это важно, и сколько денег эти люди готовы платить за ваш продукт. Если вы делаете это медленно, вы проиграли. 

Венчурный фонд Andreessen Horowitz еще 10 лет назад выявил, что 42% стартапов погибают, потому что не находят рынка, которому нужен их продукт. Продукт не доживает до MVP.

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

Как организовать тестирование в стартапе

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

Здесь важно пойти от конца, формализовать обратную связь с пользователями и начать измерять ее продуктовыми метриками, которые связаны с customer development, методологией jobs-to-be-done и т. д. К продуктовым методологиям следует привязывать методологии разработки: обратную связь собирать по шаблону, баг-репорты описывать по шаблону. Документацию и регламенты заводить сразу, как появляется потребность. 

На этом этапе уже можно делиться QA-скиллами с другой командой. С этого же момента нужно доносить разработчикам, что пора писать юнит-тесты. 

Scaleup

Допустим, у вас получилось сделать MVP, вы нашли ранних последователей, пересекли долину смерти, и ворвались на рынок. Здесь важно отработать Product-market fit и начать стабильно зарабатывать.

PMF определяет соответствие продукта потребностям рынка:

• На продукт есть спрос, и он растет.

• В продукте есть функции, которые соответствуют спросу, и вы успеваете доносить их до рынка. 

• Продукт уже воспроизводим, то есть вы смогли поставить на поток его разработку.

На стадии масштабирования бизнеса пора масштабировать и контроль качества. У вас уже должны быть процессы, которые позволяют поддерживать и улучшать качество продукта из релиза в релиз. 

Если вы не разработали процессы ревью, тестирования требований, тестирования дизайна, если у вас нет регламентов заведения баг-репортов, нет регламентов описания покрытия кода юнит-тестами и не сложилась пирамида тестирования, то на этапе Scaleup все посыпется.

Как организовать тестирование на этапе Scaleup

В момент быстрого роста начинаются пиковые нагрузки, и вы начинаете задумываться о перформансе. Среди пользователей появляются люди, которые пытаются сломать вашу систему — вы начинаете думать о граничных кейсах. На этом этапе имеет смысл обращать внимание на покрытие требований. Это в первую очередь test coverage и трассируемость. 

На этапе scaleup самое время начинать автоматизацию, так как часть продукта уже разработана до конца. Ее покрытие автотестами позволит сократить регресс. Можно запускать health-checks, избавляться от flacky tests, анализировать и классифицировать причины падений. В это же время появляется много клиентов с разными конфигами и устройствами. А если вы зашли на массовый B2C-рынок с разными локалями, то без автоматизации будет очень трудно. 

В момент масштабирования можно сдвигаться «вправо» и запускать первые продуктовые метрики, например, NPS — оценку лояльности клиентов. 

На фазе роста бизнеса обычно уже сформирована команда QA и настроены некоторые процессы: метрики тестирования фиксируют факты, но не дают аналитики, а баг-репорты заводятся, скорее всего, в трекере. Этот трекер живет отдельно от разработчиков, автоматизатор читает только allure reports, а тест-кейсы ведутся в Excel.  

В таком виде лучше не продолжать. В этот момент пора сдвигать процессы «влево», чтобы задействование команды QA начиналось на этапе работы с аналитиками, системными требованиями и дизайнами. В это время уже должны быть регламентированные процессы: workflow в Jira, workflow в TMS, пайплайн. И главное, как уже сказано выше, — самое время для автотестов.

Enterprise

Когда бизнес стал толстым, грузным и с деньгами, вы можете позволить себе измерять многое. Правильно ли это? 

В тот момент, когда у вас появляется много коммитов, SLA, несколько продуктов и тысяча поставок, бизнес как коммерческое предприятие начинает сильно довлеть над разработкой и требовать все больше и больше: «Нам нужно и то, и это, и будем проводить экспансию за рубеж. Нет, не в этот за рубеж, а в другой за рубеж, поэтому быстро поддерживайте другую локаль» и т. д. Основная проблема здесь — потеря фокуса, потому что деньги вкладываются в бюджеты и прогорают очень быстро. 

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

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

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

Одна North Star Metric вместо тысячи

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

Если вы принимаете неправильные решение, метрика стагнирует или падает. Тогда ее можно декомпозировать, чтобы понимать, где точка просадки. Обычно North Star Metric и ее производные выбирает вся команда: продакты, QA, лиды разработки. 

Показательный пример такой консолидации измерений — у приложения для отслеживания репродуктивных циклов Flo. Его North Star Metric — это активные пользователи за месяц и привязанное к ним количество платных лицензий. Так как Flo — это календарь, компании важно, чтобы люди заходили в приложение каждый месяц. Если количество пользователей уменьшается, значит календарь их не устраивает.

Поэтому для Flo критически важны юзабилити на устройствах, возможность использовать календарь и платежи от подписчиков. Если проседает производная метрика по получению платежей и по взаимодействию с устройством, значит, что-то надо менять.

У нас в Test IT три основных метрики, но самая главная — это lifetime value. Для нас как для b2b-продукта в первую очередь важно, насколько удовлетворены клиенты, как долго они с нами работают. 

Как объединять команды вокруг правильных метрик

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

Одна из самых серьезных проблем в том, что ручники не доверяют автотестерам и перепроходят многие автотесты, что растягивает регресс. Множественные метрики по тестированию, которые расплодили энтузиасты, не приводят к правильным решениям. Их слишком много, их тяжело анализировать, они становятся вещью в себе и в итоге превращаются в ритуальный дашборд. Более качественный подход — это бранчевание и разбиение на фич-команды, которые объединены общей культурой кода, общей базой знаний. 

Если весь путь развития бизнес прошел эффективно, то QA размазан «слева направо». То есть shift-left и shift-right произошли в разное время, но они произошли. Значит, обеспечение качества идет от момента сбора аналитики и проектирования интерфейсов до сбора данных с постпродакшна. 

Документация при этом должна храниться в общем инструменте. Тест-кейсы лучше хранить в TMS. Если требования хранятся в Confluence, с ним в связке хорошо работали Jira и Zephyr, но в России их больше нет. Альтернатива есть у нас в Yoonion holding: помимо Test IT мы разрабатываем TeamStorm — настраиваемый таск-трекер и хранилище данных. 

Инструменты вторичны. Главное — договориться о своем индикаторе здоровья продукта. Выделив North Star Metric, вы сможете понять, как на нее реагировать. Это приводит к быстрым и ясным действиям.