{"id":4100,"title":"\u041a\u0430\u043a \u0443\u0441\u0442\u0440\u043e\u0435\u043d\u044b \u0441\u0442\u0430\u0440\u0442\u0430\u043f-\u043a\u043e\u043c\u0430\u043d\u0434\u044b \u00ab\u0420\u0430\u0439\u0444\u0444\u0430\u0439\u0437\u0435\u043d\u0431\u0430\u043d\u043a\u0430\u00bb","url":"\/redirect?component=advertising&id=4100&url=https:\/\/vc.ru\/promo\/248133&hash=a7b0a088930ad5bdf26d69e10462a67c204c2ce1406f5fed55f5834263220fe6","isPaidAndBannersEnabled":false}

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

«Вы и такое можете?», «О, а что, так можно было?» — эти вопросы мы частенько слышим от новых клиентов у себя в «Кавычках». Нет, мы не показываем им фокусы, не заказываем такси и не занимаемся ничем другим, кроме тестирования и 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 :)

{ "author_name": "Евгений Пономаренко", "author_type": "self", "tags": [], "comments": 2, "likes": 8, "favorites": 27, "is_advertisement": false, "subsite_label": "opinions", "id": 250175, "is_wide": false, "is_ugc": true, "date": "Tue, 25 May 2021 15:45:54 +0300", "is_special": false }
0
2 комментария
Популярные
По порядку

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

0

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

Ответить
Читать все 2 комментария
Как быстро интегрировать CloudPayments в сервис на PHP

Привет! На связи Иван Могилат, Backend-разработчик Flowwow. Делюсь библиотекой для работы с CloudPayments и рассказываю, кому она пригодится.

 
Пацаны, у меня насущный вопрос: вы читаете или нет?

Короче, где-то увидела инфу, что из всего взрослого населения читает книжки более-менее регулярно только 10-15 процентов.

Что такое пассивное инвестирование. Рассказывает персональный брокер

Как правильно вкладывать деньги на годы или даже десятилетия, и как Уоррен Баффет выиграл пари

О русском HR

Кто эти люди? Как они туда попали? Какое у них "образование"? Зачем они вообще нужны?
Уже достаточно долгое время приходится сталкиваться с русскими ИТ-рекрутерами/HR и вот какие впечатления о них набрались:

«В кармане у меня было $2, я надеялся заработать $1 млн»: история одержимого финансовыми схемами мошенника Чарльза Понци Статьи редакции

Предприимчивый итальянец, который прибыл в США в надежде разбогатеть, стал миллионером, а потом оказался в тюрьме и умер в нищете на другом конце мира.

Чарльз Понци на пике своей славы
Робототехника и облачные мощности: почему роботам нужны облака

Настроить автопилот квадрокоптера и запрограммировать коллаборативного робота проще с виртуальными серверами.

«СДЭК»: статус заказа «вручен» — по факту посылка не доставлена

17.06.21 из Петербурга в Москву были отправлены документы со статусом: супер-экспресс доставка. Заявление время прибытия в Москву - 18.06 в 12:00. В назначенное время документы доставлены не были. В 17:00 я начала звонить в сдэк, так как посылка с документами, и они нужны были именно в пятницу. К 21 часу выяснили, что посылка в Домодедово, какие…

Облачные игры стали доступны клиентам Yota
Как я сервис по поиску дроп доменов разрабатывал

Всем привет, меня зовут Руслан, это мой первый пост на VC. Не закидывайте камнями за сумбурную историю и ошибки. Конструктивная критика приветствуется.

«Яндекс.Маркет» не доставил товар вовремя

Добрый день, всем!

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

Москва вошла в тройку рейтинга экосистем для стартапов среди европейских городов
Занять столь высокое место в рейтинге столице позволили городские программы развития технологического сервиса.

Таким образом, столица улучшила свою позицию на один пункт по сравнению с предыдущим годом. Обогнать Москву удалось лишь Лондону. Замыкает тройку лидеров – Париж.

Комментарии
null