А чо так дорого: сколько стоит качество IT-продукта

И как выбрать норм тестировщиков, чтобы не получилось как с клофелинщицами

«Дорого». «Не, ну цены у вас, конечно». «Вы вообще некрещеные?» «А мы вот дешевле видели».

Знакомая история?

Привет! Я — Женя, СЕО и фаундер агентства аутсорс тестирования «Кавычки». И мы в тестировании нередко сталкиваемся с подобным: «Это же тестирование, а не разработка — чо так дорого?»; «Делов то там — по кнопкам пожмакать». Ну да, если просто пожмакать, то это можно и «бесплатно» сделать — за счет пользователей. Короче, если не знать всю подноготную, то, конечно, появляется много вопросов по поводу циферок в счете.

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

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

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

1. Контекст проекта:

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

2. Цифры и вводные проекта:

• Сколько людей пользуются сервисом;
• Сколько людей жалуются на сервис;
• Сколько проблем у нас появляется после релиза;
• Происходит ли рост/падение бизнеса/денег после релиза;
• Какие сроки и успеваем ли мы со сроками релиза;
• Насколько довольны ТОПы бизнеса в работе IT-отдела (правда, это не измерить цифрой, но показатель тоже важный).

3. Динамика

• Насколько динамичен продукт — частота обновлений и релизов.

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

Есть ли прямая зависимость цены от уровня навыков тестировщиков?

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

Потому что:

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

Но не факт, что вам продают то, что обещают. Бывает и так, что хорошие специалисты работают с невысокой з/п. И с высокой з/п бывают плохие специалисты (вот это новости!). И специалисты могут получать не так много, просто у компании большая наценка. Поэтому здесь нет четкой закономерности.

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

• количество браузеров/устройств для проверки;
• сложность фич/верстки;
• документация;
• сроки;
• количество человек, которые будут участвовать в проекте и т.д.

Как правило, мы просим выслать нам какие-то доки по приложению, ТЗ/макеты, список задач или даже ссылку на приложение, чтобы понять, насколько сложная предстоит работа. Далее, опираясь на опыт в тестировании предыдущих проектов (зачастую похожих), прикидываем примерную вилку того, сколько времени нам потребуется на тестирование в одной среде. Потом используем вышеперечисленные критерии, чтобы оценить, сколько всего времени нам потребуется.

Лайфхак для экономии времени: если вы читаете эту статью и хотите спросить у нас, сколько будет стоить тестирование продукта, — присылайте сразу данные по списку:)

Вот несколько простых примеров, как это может выглядеть (здесь опираемся на средний ценник):

Небольшой проект:

Вводные:

• Допустим, у вас интернет-магазин с товарами для кис;

• У вас внутри есть каталог товаров, личный кабинет покупателя и страница акций. Все это управляется из CRM-системы (пофиг какой).

Задача:

• Ваш разработчик прикрутил акцию, которая делает скидку в 15% по промокоду «МокраяКиска», она распространяется только на влажный корм.

Сроки:

• Акция запускается завтра.

Итого:

• Средний ценник на такие услуги за час тестера — 1500 рублей;
• Вам нужно 4 часа на проверку, но при этом у вас только 2 часа до конца дня;
• Поэтому вам нужно 2 человека (разделим между ними браузеры/устройства).

Примерная стоимость: 6000 рублей.

Большой проект:

Вводные:

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

Задача:

• Все-все это надо проверить, и чтобы когда что-то изменили, то автоматически проверялось, что старое не сломалось.

Сроки:

• Запускать не торопимся, к лету успеем (какого года неизвестно).

Итого:

• Средний ценник на такие услуги за час тестера — 1500 рублей, а автотестера — 2000 рублей. А за лида — 5000 рублей, он должен организовать работу QA-команды, чтобы никто не простаивал и не тратил деньги просто так. Но у нас он бесплатный, мы его не будем учитывать в дальнейших расчетах;
• Вам нужно 100 часов только на документацию, еще 500 на ручное тестирование и 500 на автоматизацию. И лида не забудем, прикинем, что его внимание оценено в 100 часов на проект;
• Поэтому вам нужно аж 3 человека как минимум на полгода. Это уже полный рабочий день на длительный срок — а значит, можно и скидку попросить;).

Примерная стоимость: 1 900 000 рублей (про скидку не забудьте спросить!).

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

• Новый проект с нуля — 30%;
• Проект с четко определенными тестами и стабильной системой с небольшими изменениями — 15–20%;
• Критически важная система с низкой устойчивостью к сбоям — 40–50%;
• Внутренняя система с высокой отказоустойчивостью — 5–10%.

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

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

Давайте попробуем посмотреть поближе:

Например, наш средний чек за год на одного клиента — 116 000 рублей/месяц. Отдадим тестировщику, допустим, среднюю по палате — 60 000 рублей на руки. Отдадим на все налоги — это еще примерно 30 000 рублей. Окей, 90 000 уже отдали, осталось 26 000 рублей. Часть отдадим в ЗП менеджеру и другим отделам, которые не участвуют в формировании прибыли — 10 000 рублей + 5000 рублей на налоги. Остальное на поддержку работы компании: серверы, обслуживание ферм, бухгалтерия, плюшки для сотрудников. И обязательно нужно отложить на черный день! Дебиторку никто не отменял:(

И как понять, что вы не переплачиваете:

• Стоимость

Достаточно открыть список вакансий QA, например, на «хабр карьера» и посмотреть на з/п. Скорее всего, агентство будет дешевле. У них уже есть материально техническая база, которая размазывается на года, поэтому вам не надо будет:

• тратить деньги (и что не менее важно — время) на поиск сотрудника;
• тратить деньги на косвенные расходы на сотрудника (рабочее место, развитие, отпуска и тп);
• тратить деньги на налоги, работу бухгалтерии или менеджера.

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

• Качество

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

• Заинтересованность в проекте

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

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

Если ваши тестировщики (или компания по тестированию) не задают вопросов, ни разу не доставали разработчиков, ничего не предлагали улучшить и даже не спорили — стоит подумать по поводу их реальной вовлеченности в проект. Мы, например, 100% аутсорс и у нас много проектов, но при этом, мы культивируем отношение к проекту внутри компании как к своему. И это must have для наших коллег, чтобы работать в компании.

• Дополнительный бонусы и клиентоориентированность

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

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

• Интеграция в команду

И конечно, важно, чтобы тестировщики/QA-команда смогли быстро влиться в процесс работы и наладить прозрачное и понятное взаимодействие с командой. Можно нагуглить кучу мемчиков про то, как разрабы не ладят с тестерами. Здесь довольно тонкая грань. Спорить в контексте «предлагать улучшения на основе объективных данных» — это нормально, если в итоге это положительно влияет на продукт. Спорить в контексте «сраться» без конкретных оснований, переступая грани, — это хреново и непрофессионально. Тут, кстати, и помогает опытный QA-лид.

Старайтесь работать с проверенными, а к новеньким относитесь с осторожностью. Используйте для поиска QA-команды сарафан, попросите контакты у знакомых, или посмотри клиентов / сами найдите контакты клиентов, чтобы уточнить, как прошло взаимодействие.

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

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