Business driven testing: как тестировщику решать задачи бизнеса

Меня зовут Раткин Кирилл, я из Контура. Я пришел в компанию в 2011 году на позицию тестировщика, с 2014 года потихонечку начал QA-лидить, а с 2019 года руковожу уже в кластере команд. 

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

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

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

1. Узнайте ожидания от бизнеса

Пойти и явным образом спросить своего руководителя

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

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

Выяснить про работу с клиентской базой

Эта работа актуальна для большинства продуктов на рынке. Здесь я выделяю два аспекта: сохранение текущей клиентской базы и привлечение новых клиентов.

Сохранение текущей клиентской базы

Задайте себе вопрос: «А каковы вообще причины выхода?» Чтобы собрать список этих причин, нужно найти человека, который отвечает за экзитполы, опросы пользователей, NPS и так далее. Дальше посмотрите, есть ли в этом списке причины, связанные с функциональным качеством? 

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

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

Привлечение новых клиентов

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

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

Еще можно подумать о разных практиках, которые уменьшают time to market. Например, такие практики как Shift Left Testing, когда тестировщик подключается к ранним этапам разработки. Это спорная практика, но именно здесь она кажется вполне выгодной. 

2. Наследуйтесь от вышестоящих целей

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

Совет простой, но не секрет, что мало кто из тестировщиков и вообще разработчиков ему следует. Узнайте цели вашей компании на следующий год или квартал, цели команды, цели руководителя. Если цели ваших руководителей публичны, вы на них просто берёте и завязываетесь. Если непубличны, то цепляйтесь за другие: доклады руководителей на внутренних конференциях, OKR и тд. 

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

3. Думайте об автотестах и их покрытии с точки зрения бизнеса

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

Как оценить качество продукта с точки зрения бизнеса? Давайте поймем, какие у нас есть варианты. 

• Экспертная оценка?

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

• Процент покрытия кода?

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

• Покрытие требований?

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

• Количество багов?

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

• Пользовательские сценарии!

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

Частотные мы даже научились считать автоматически. У нас есть инструмент, который выдает приватизированный список. В нем тестировщик может найти что-то полезное. Например, что кнопку ПФР пользователи тыкают в 2 раза чаще, чем кнопку Росстат. 

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

Так у нас получилась наша система координат. Критичные должны быть покрыты на 100%, а частотные – некий оговоренный топ. 

А что касается дизайна тестов, здесь, на самом деле, вы должны использовать принципы User-Driven Development. В фокусе вашего внимания всегда должен быть пользователь. 

4. Отправляйтесь в целевые стажировки в другие команды

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

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

1. Тушение пожаров

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

2. Помощь с автотестами

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

3. Помощь важнейшим проектам компании

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

4. Внутренний аудит

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

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

5. Следите за трендами: в компании, в мире

Это уже такая, не совсем тестировщиская тема. Но надо смотреть шире. Например, ваша компания или ваш конкретный продукт просто берет и переходит от монолита к микросервисам. Вы должны понимать, как должна измениться ваша работа в тестировании. Или, например, как тестировать сервис, SOA, event-driven, SPA и так далее. Всегда есть своя стратегия тестирования.

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

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

6. Читайте не только про тестирование

И последний мой небольшой совет  касается профессиональной литературы. Добавляйте в перечень книг, который вы читаете, книги на следующие темы:

• Процессы организации разработки в разных командах

• Построение сложных систем и связи в них

• Дизайн команд разработки 

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