Цена качества: 7 принципов оптимизации затрат на тестирование +20



image alt


Думаете, как сэкономить на тестировании вашего ПО? Вы не одиноки. Возникает лишь одно маленькое но: если софт не дотестировать, возможны самые негативные сценарии – от дорогостоящей и крайне невыгодной вам доработки приложения на поздних стадиях до потери репутации и ухода клиентов/заказчиков к конкурентам.

Готовы взять к себе в штат 50 самых опытных тестировщиков, чтобы обеспечить качество продукта? Вот же круто! А зачем? Нужно понимать: если выделите слишком большие ресурсы на тестирование в тех случаях, когда это неоправданно, вы раздуете бюджет и софт будет слишком дорогой. Обрадуются ли этому ваши пользователи и заказчики? Вы снова рискуете.

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

Принцип №1. Начинайте тестировать как можно раньше


image alt


Одна из самых распространенных ошибок – это начинать тестировать продукт на поздних стадиях, когда он практически готов к релизу. Чем раньше команда тестирования (QA) подключается к процессу разработки, тем ниже вероятность пропустить ошибку в продакшн. Кроме того, ошибка выявленная на ранней стадии разработки обойдется дешевле. В разы. Наш опыт показывает, что цена фикса на поздних этапах может оказаться в 30 раз дороже, чем фикс этой же ошибки, например, на стадии прототипа.

image alt

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

Когда мы начали тестировать приложение с реальным объемом пользовательских данных, оказалось, что выбранная архитектура базы данных не справляется с такой нагрузкой. Команде разработчиков из пяти человек пришлось заново всё планировать, переписывать дизайн и архитектуру приложения, а нам – тестировать его с нуля. Релиз состоялся на шесть недель позже планового.

Итог: желание сэкономить 150 человеко-часов на тестировании и отодвинуть его к релизу привело к потере 1100 человеко-часов своих сотрудников и двойным затратам на тестирование.

Принцип №2. Экономьте, но только не на аналитике


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

image alt

Без грамотно проведенной аналитики вы рискуете выпустить на рынок идеальный продукт, который никому не нужен. Такое бывает, когда вы не учитываете особенности своей целевой аудитории.

Мы помним страшилку о приложении для бега, которое было заточено под пользователей из Азии. Оно бы обязательно понравилось ЦА и принесло прибыль, если бы клиенты смогли установить приложение на свои смартфоны. Но они не смогли, а знаете почему? На этапе сбора требований была допущена ошибка, из-за которой приложение тестировалось на айфонах и смартфонах Samsung, которых в Азии – минимум. Ведь азиатские пользователи однозначно отдают предпочтение Huawei и OPPO.

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

Итог: вы можете пригласить специалистов со стороны или ограничиться своими силами, главное – помните, что потребительское тестирование на этапе поддержки обходится в десятки раз дороже. И под дороже мы подразумеваем не столько денежные убытки, сколько репутационные издержки. Не экономьте на аналитике. Только не на ней!

Принцип №3. Определите цели и ожидания


Конечно же, вы хотите, чтобы всё работало, и работало хорошо. Но этого мало. Вам нужно понимать, насколько хорошо и почему именно настолько.

image alt

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

Когда к нам приходит заказчик и говорит: «Я хочу, чтобы оно работало», мы начинаем его расспрашивать: какая основная цель создания продукта? какие функции наиболее востребованы пользователями? как они их используют?



После сбора ожиданий идет постановка SMART-целей, их декомпозиция, построение задач и таблиц KPI. В итоге мы четко определяем:

  • виды тестирования;
  • сроки их проведения;
  • состав команды;
  • и даже возможные риски.

Всё это необходимо для обеспечения нужного заказчику качества, без гадания на его нервах.

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

Затем проект свернули, два месяца анализировали и вернулись с предложением использовать план по автоматизации, который мы предложили пять месяцев назад.

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

Принцип №4. Автоматизируйте


image alt

…Но мудро. И предварительно посчитав ROI.

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

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

  1. TC's amount – количество кейсов в сценарии.
  2. Automation (man*days) – ресурсозатраты на автоматизацию сценария (без учета тестовых данных для каждого тест-кейса).
  3. 1 TC automation (man*hrs) – затраты на автоматизацию одного тест-кейса.
  4. Manual testing (man*days) – затраты на ручное тестирование сценария в целом.
  5. Results investigation (man*hrs) – затраты на исследование результатов прогона автотеста.
  6. Execution times – количество требуемых прогонов тестов за период работы над проектом. Данное число отражает ожидаемое количество прогонов с учетом стабильности функционала, требуемого графика прогонов тестов (регулярности получения информации) и т.д.
  7. Automation efficacy (%) – эффективность автоматизации тестирования в % от сэкономленного времени. Учитывая погрешности вычислений, эффективной можно признать автоматизацию с показателем более 150%.
  8. Saved time (man*days) – количество человеко-дней, сэкономленных за время всего проекта.

Вот как это выглядит на примере нашего проекта:



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

Итог: автоматизация может сократить трудозатраты на тестирование в десятки раз, а может слить бюджет впустую. Без умения анализировать и считать ROI вы всегда рискуете навсегда разочароваться в автоматизации.

Принцип №5. Научитесь использовать новичков


image alt

Не хотите автоматизировать? Тестеры с опытом бьют по бюджету? Подумываете нанять рукастых выпускников вузов за небольшую, но разумную зарплату? Неплохая идея, но есть несколько нюансов. Даже если у вас несложный продукт, одних новичков вам не хватит.

Ребенок может найти баг в игре и сломать приложение по методу манки-тестинг, но найдет ли он все баги? Конечно нет. Мы очень любим новичков, но они, как правило, не владеют методами исследовательского тестирования. Зато они могут «ходить» по тестам. Поэтому на компанию новичков с горящими глазами нужен «старичок», который пропишет проверки на том уровне, который будет понятен вашим новичкам.

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

Фрагмент набора кейсов для тестирования страхового продукта представлен ниже.

image alt

«Пакет новичка» может включать что-то совсем простое, но полезное, типа генератора данных.

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



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

Итог: выгодно использовать труд новичков без потери качества и скорости тестирования вполне возможно. Junior способен приносить реальную пользу на проекте уже со второй недели, сократив потери времени на адаптацию в 4 раза (со 160 до 40 часов).

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

Принцип №6. Вам не нужны сто тестировщиков, вам нужны те, кто работает головой


image alt

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

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

Распространенный случай из практики. Не так давно к нам обратился клиент, у которого в команде было 12 тестировщиков: ТМ, senior, middle и 9 junior. Мы провели аудит процессов тестирования и отказались от восьми тысяч ненужных задач (таких как регресс незатронутой обновлениями функциональности, заведение миноров и т.д.), плюс придумали, как оптимизировать тесты. Оказалось, что проект нуждается в трех автоматизаторах (предложили своих) и еще одном middlе, которого вырастили из числа junior. От остальных новичков пришлось отказаться.

image alt

Далее мы оставили тестирование критичного функционала в блоке «Идентификация и квитовка» на middle. Они проверяли его вручную, исследовательским тестированием. Все остальные блоки практически полностью ушли на автоматизаторов.

image alt

В итоге это позволило:

– Снизить стоимость предрелизного тестирования с 232 400 до 35 200 рублей.

– Повысить ROI тестирования за счет автоматизации в 5 раз.

– Снизить управленческую нагрузку на руководство.

– Сократить время предрелизного тестирования на 23 человеко-часа.

– Повысить качество тестирования, оставив на проекте только опытных тестировщиков.

Принцип №7. Посчитайте, что вам выгоднее: штат или аутсорс


image alt

Часто, но не всегда аутсорс обходится дешевле и позволяет нанять более опытных сотрудников со скидкой.

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

Чтобы не быть голословными, покажем таблицу, которая объяснит, откуда берется такая выгода.

image alt

В нашем примере штатный тестировщик с окладом 70 тысяч рублей в месяц обходится компании на 14 877 рублей дороже, чем более дорогостоящий специалист-аутсорсер, имеющий почти вдвое больший оклад. Если взять в расчет отдел из 9 человек, которые отработали год, то выгода составит 1 606 716 рублей. А это уже деньги.

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

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

Коротко о сказанном


1. По версии «Национального Института Стандартов и Технологии» стоимость тестирования в конце разработки может превышать её стоимость на начальных этапах в 15 раз, а после релиза в 30 раз.

Не хотите переплачивать? Начинайте тестировать как можно раньше!

2. Непонимание своей ЦА и её требований к продукту похоронило множество отличных проектов.

Экономите на аналитике? Готовьтесь платить за игру в угадайку!

3. Анализировать нужно не только ЦА, но и пожелания заказчиков. На их основе нужно уметь ставить и декомпозировать SMART-цели.

Не умеете ставить чёткие цели? Ваши цели непонятны заказчику? Закладывайте затраты на доработку и переделку!

4. Автоматизация помогает оптимизировать затраты на тестирование. Но не везде и не всегда.

Считаете, что руками тестировать выгоднее? Посчитайте ROI от автоматизации по нескольким сценариям и сравните цифры!

5. Новички в тестировании полны энтузиазма, но им не хватает опыта. Хороший наставник и «пакет новичка» повышает КПД джуна на проекте в 2-3 раза.

Набрали вчерашних выпускников за разумную плату? Готовьтесь доплатить за их превращение из «обезьянки» в человека!

6. Качество не равно количеству. Хороший специалист стоит дороже, потому что он даёт лучший результат.

Не хотите экономить, работая на результат? Тогда вам не стоит проводить аудит команды тестирования и оптимизировать её состав.

7. Аутсорс тестирования позволяет получить на проект опытную команду с гарантией результата. Но подходит аутсорс далеко не всем.

Хотите готовое решение с демократичным ценником? Рассчитайте преимущества от штата и от аутсорса, возможно второй вариант окажется в разы выгоднее.

Вместо эпилога


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

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

Нина Агеева,
Deputy Director at Лаборатория качества.

Вы можете помочь и перевести немного средств на развитие сайта



Комментарии (17):

  1. ukt
    /#19762872 / -1

    За последнюю таблицу из №7 отдельное спасибо.

    Возник вопрос про 1/20 на оргтехнику от ЗП сотрудника, откуда такой коэф взялся?

    • Quality_lab
      /#19764858

      Коэф. сложился путём аудита отделов тестирования наших клиентов. Стоит иметь ввиду, что там учтено не только помесячное распределение стоимости организации одного рабочего места (с учётом амортизации). Но и стоимость ежемесячного поддержания/обеспечения этого места в рабочем состоянии.

    • NeverIn
      /#19765004

      Ага, а типа аутсорсерам руководитель не нужен, их искать, нанимать и увольнять(прекращать договор) не нужно. Пусть оно само саморганизуется.

      • Quality_lab
        /#19765418

        А кто-то говорит, что не нужен? Таблица про расходы заказчика — сколько тот будет платить в итоге при прочих равных условиях. В случае с аутсорсом — управленческие и иные виды издержек никуда разумеется не исчезают, просто их на себя берёт аутсорсинговая компания. А как она оптимизирует свои затраты — это уже отдельная история и боль самих аутсорсеров.

  2. Habra_nik
    /#19762910

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

    • Quality_lab
      /#19764750

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

      • Habra_nik
        /#19767460

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

  3. marshinov
    /#19763940

    Классная статья, спасибо!

  4. dth_apostle
    /#19764090

    Статья замечательная, но в последней табл натяжки. Рук-тель аутсорсеру не нужен? Завязка на стоимость оборудования, мебели к з/п начинает иметь место только для топов. Для рядового сотрудника — сомнительно. Не учтены риски организации отказоустойчивого канала связи то локации аутсорсера. Постановка задача для аутсорсера должна быть более формальная, не учтены затраты на коммуникации, на организации встреч.
    Для сотрудника на аутсорсе считаем таки ЗП или оплату часов по договору? Если ЗП, то почему без НДФЛ в случае аутсорса и включаем НДФЛ для штатного? Или все же это оплата услуг, а не ЗП.

    • Quality_lab
      /#19764844

      В правом столбце, сумма, которую вы видите, это сколько конкретно платит заказчик. А уже из этой суммы мы платим и НДФЛ, и ЗП руководителям (аккаунт-менеджерам), и ставим нужным сотрудникам софт, и обеспечиваем бесперебойные каналы.

      • dth_apostle
        /#19764854

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

        А уж если из этой суммы выплатите ЗП всем своим, то альтернатива у клиента еще может быть лучше — нанять студента за 20-30 т.р. Просто исходный ваш посыл был, что дорогой специалист с вашей стороны за 130тр в итоге дешевле наемного за 70тр. Теперь получается, что ваш спец еще неизвестно сколько стоит == какая у него квалификация. Даже как-то хуже получилось.

        • Quality_lab
          /#19764900

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

  5. vasyan
    /#19764826

    Хотите экономить на тестах?
    1. Не пишите unit-тесты, пишите функциональные. Unit-тесты накаладывают кучу ограничений на архитектуру. Вы сможете выкинуть половину интерфейсов, фабрик и прочего архитектурного халама, который вам нужен только ради возможности что-то замокать.
    2. Если ваши требования меняются, то не пишите тесты на ранних этапах всё равно их надо будет переделывать. Помните, что тесты тормозят развитие. Ваши разработчики будут бояться что-то делать, чтобы не поломать тесты. Потому вводить тесты хорошо на поздних этапах.
    Помните, что тесты очень дорого сопровождать, особенно, если для написания тестов вы наняли аутсорсеров.
    3. Хорошая аналитика частично заменяет тесты. Можно вообще не писать тесты и обойтись A/B-Тестированием в продакшене, если у вас хорошая система аналитики. Для частых релизов тесты вообще вредны — вы просто не будете успевать сопровождать тесты.
    4. Не гонитесь за 100% покрытием. Это менеджерский булшит. Покрывайте основные сценарии и реально критичные сценарии. Часто цена отказа намного меньше, чем цена тестирования.

  6. reishi
    /#19764920

    senior, middle тестировщики? О чем вы? Десяток студентов дипломников, работающих за бесплатно, въезжают в любую тему в кратчайшие сроки и работают не хуже. Курсы повышения квалификации для тестировщиков? Серьёзно?

    • Quality_lab
      /#19764932

      Сами в шоке. Квалификации, грейды, на крупных проектах заказчики требуют от наших тестеров опыт работы не менее 2-ух лет, знание отрасли и предметной области. А ещё есть ISTQB (скоро выйдет статья по нему) и тендеры от Сбербанка на функциональное тестирование по 200-300 млн. руб. за штуку. Докатились )

    • vasyan
      /#19765244

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