Разбор на максималках: чем агентство тестирования может быть полезно бизнесу (кроме тестирования)

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

Просто на рынке как-то так сложилось, что представление о возможностях QA-специалистов/тестировщиков сконцентрировалось в двух задачах:

  • Самый топчик: они нужны только для тестирования продукта — поклацать по кнопкам, посмотреть — все ли ок и пустить со спокойной душой на прод (а если не все ок, но надо срочно выпускать — перекрестить и пустить на прод).
  • Продвинутый уровень: обеспечение и контроль качества.

И если с первым пунктом все ясно, то со вторым сложнее, какое-то размытое и обширное определение. А для тех, кто не так глубоко погружен в специфику, — не особо понятно, что это. Что-то про качество. Возможно, именно поэтому агентства тестирования и тестировщики граничат с образом манки-тестеров, которые то и дело тыкают по кнопкам.

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

В этой статье я хочу рассказать о неочевидных, но крутых скиллах, которые могут, умеют, практикуют QA-инженеры/агентства тестирования, и как это реально может помочь бизнесу (ок, обойдемся без нудных текстов, про то, что продукт без багов — это дорога в светлое будущее).

Но сначала:

Чтобы все прояснить: короткий ликбез № 1

Что такое QA, как это выглядит на проекте:

Вот, на что ориентируюсь я и именно в таком порядке:

а) пользователь/конечный покупатель — тот, кто приносит деньги бизнесу нашего клиента;

б) климат в команде — тут имеется ввиду все: тестеры, разработчики, дизайнеры, менеджеры, ТОПы бизнеса;

в) сроки.

Что важно в этой схеме, и на что влияет QA:

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

Часто встречаются и менее очевидные вещи, которые тоже влияют на лояльность пользователей, например, скорость загрузки

— Есть, конечно, и другие вещи, на которые мы не повлияем, например, бизнес никому не нужен. Здесь уже выбор за агентством — работать с таким бизнесом или нет. Мы, например, не работаем. Улучшай - не улучшай — больше денег в компанию клиента не придет, просто потому что этот продукт не нужен пользователям. И какой смысл обманывать клиента, да и себя. Привет, миллионстопервый стартап!

Погнали дальше, что еще важно:

— Чтобы в команде были четкие и выстроенные процессы (кто, к кому, куда идти с вопросами и задачами; как ставить задачи; как оценить релиз и т. п.);

— Чтобы каждому в команде было понятно, как работает весь этот «оркестр»: разработке было понятно, к чему и как мы стремимся, а ТОПам было понятно, в какой точке находится разработка;

— Ну и, конечно, сроки — чем быстрее мы будем доставлять фичу до пользователя, тем быстрее бизнес заработает в прямом и переносном смыслах.

Чтобы совсем не запутаться: короткий ликбез № 2

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

Это в теории. А на практике прокачанные тестировщики уже работают как QA. Т. е. они не просто тестируют какую-то фичу, они понимают логику всего продукта: что будет удобно или неудобно пользователю; как новая фича может повлиять на существующие; могут предложить изменения; видят изъяны в процессах работы. Чтобы дальше не возникло путаницы, давайте остановимся на «QA-инженер» — и приятно, и ближе к истине.

Ну, ок. Надеюсь, разобрались. А теперь к главному:

Постановка процессов работы

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

Процессы работы — это и взаимодействие между командой или командами/отделами, а также сами процессы разработки.

  • Что такое взаимодействие в команде: кто и кому должен задавать вопросы; в каком виде оформляются вопросы; как задачи передаются, кому передаются и в какой момент времени, кто и за что отвечает и т. д.
  • Что такое процессы разработки — это жизненный цикл разработки, который состоит из аналитики, разработки, тестирования и поддержки. И здесь важно понимать всю цепочку: как происходит аналитика; кто на этом этапе участвует; какие статусы у задач; когда они переходят и к кому переходят; что происходит в разработке; что этим временем делают тестировщики; как они взаимодействуют с аналитиком и разработкой на этой стадии — и еще сто тысяч вопросов.

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

Почему именно QA-инженер должен этим заниматься? Почему, например, не PM или еще какой-нибудь пятьсот первый менеджер? QA-инженер понимает логику пользователя, бизнес логику продукта, как процесс сказывается на качестве и что не менее важно — как между собой должны коннектиться функционал и цели бизнеса. Он смотрит на весь процесс работы как на часовой механизм, детально разбирает его и дорабатывает. Очень похоже на PМ, но QA еще и технически должен понимать продукт, а не только с верхнего уровня менеджера.

Если где-то в процессах есть проблемы, даже от банальных: дизайнеры не договорились с разработкой, маркетинг не договорился с дизайнерами, или просто кто-то похерил задачу, потому что не знал, что только он за нее отвечает (таких выкидонов в продуктовых командах бывает очень много) — вот здесь начинаются проблемы с качеством продукта. Какая-то задача может потеряться в недрах процессов. В итоге пользователи получат некачественный продукт, служба поддержки — люли (а потом и все остальные в продуктовой команде), бизнес — убытки и негатив со стороны пользователей.

Конкретный пример:

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

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

Конкурентный анализ

Еще одна крутая штука, с которой можно и нужно обратиться к QA-инженеру, — конкурентный анализ.

  1. Во-первых, это нужно при работе с уже существующим продуктом, чтобы понимать, почему продукты-конкуренты лучше или хуже; какие фичи у них появляются; нравятся ли эти фичи пользователям; что улучшить/изменить в своем продукте, чтобы получить больше пользователей. Без этой инфы сложно держать руку на пульсе и поддерживать конкурентоспособность продукта на рынке. Круто, если есть бизнес-аналитик — это его задача. Но если нет — QA поможет с его техническим взглядом на вещи.
  2. Во-вторых, это нужно, если вы только запускаетесь. Допустим, у вас новый продукт. На рынке уже есть что-то похожее. По-хорошему, вам нужно понять, какой путь проходят пользователи с продуктом конкурента; что нравится пользователям и удобно, а что нет; есть ли у конкурента крутые фичи/косяки. Для этого вы собираете список конкурентов и отдаете QA-инженерам. Они проходят по функционалу всех сайтов/приложений, составляя карту различий, находят функциональные ошибки у конкурентов или крутые фичи, которые вы не учли.

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

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

Разбор логики продукта

QA — это такие ребята, которые скорее достанут вас вопросами до адских судорог, и вы будете ненавидеть их всем отделом, чем позволят остаться сомнениям в логике продукта. QA-инженер знает, что и с чем может взаимодействовать; как это может взаимодействовать; понимает последствия функциональных и логических ошибок. Он начинает задавать вопросы с позиции обычного пользователя: а как система будет дальше себя вести? А что будет делать юзер? А если он сделает вот это, то куда он пойдет? В ходе сессии вопросов очень часто всплывают ошибки в логике продукта.

Конкретный пример:

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

Это и есть принцип Парето «20 на 80». 20 % ошибок, найденных на последних этапах разработки, занимают 80 % бюджета на исправления. И наоборот — 80 % найденных ошибок на начальных этапах — 20 % бюджета.

Масштабирование бизнеса

QA помогает масштабировать бизнес. А точнее — QA-инженер может провести диагностику продукта, проверить его готовность к масштабированию, чтобы избежать глобальных ошибок, которые могут возникнуть, например, при увеличении нагрузки на продукт.

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

Конкретный пример:

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

Пара ласковых в конце:

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

Как и маркетологи, бизнес-аналитики, стратеги и другие специалисты/отделы компании — QA-инженеры заинтересованы в том, чтобы продукт приносил бизнесу деньги. Поэтому выйдя за рамки только тестирования, QA-инженер монетизирует свои знания в прозрачные процессы, конкурентоспособный, качественный и удобный продукт, в крутой пользовательский опыт. А довольные пользователи — это деньги и растущий бизнес.

Вопросы, пожелания, предложения можно написать мне в личку Facebook.

P.S. Ну, а если захотите прислать дикпики (или еще, что похлеще), то можно искать это потом где-нибудь на xhamster :)

0
2 комментария

Комментарий удален модератором

Развернуть ветку
Zloy Sniper

Интересная статья, спасибо. Как формируется ценник на тестирование? От чего зависят сроки?

Ответить
Развернуть ветку
Евгений Пономаренко
Автор

Привет! ) Вот тут все подробно расписал https://vc.ru/life/251392-a-cho-tak-dorogo-skolko-stoit-kachestvo-it-produkta

Ответить
Развернуть ветку
-1 комментариев
Раскрывать всегда