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

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

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

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

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

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

Но сначала:

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

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

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

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

в) сроки.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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