Хабрахабр

[Из песочницы] Цена качества: 7 принципов оптимизации затрат на тестирование

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 Лаборатория качества.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть