[Из песочницы] Цена качества: 7 принципов оптимизации затрат на тестирование
Думаете, как сэкономить на тестировании вашего ПО? Вы не одиноки. Возникает лишь одно маленькое но: если софт не дотестировать, возможны самые негативные сценарии — от дорогостоящей и крайне невыгодной вам доработки приложения на поздних стадиях до потери репутации и ухода клиентов/заказчиков к конкурентам.
Готовы взять к себе в штат 50 самых опытных тестировщиков, чтобы обеспечить качество продукта? Вот же круто! А зачем? Нужно понимать: если выделите слишком большие ресурсы на тестирование в тех случаях, когда это неоправданно, вы раздуете бюджет и софт будет слишком дорогой. Обрадуются ли этому ваши пользователи и заказчики? Вы снова рискуете.
Да, мы намекаем, что истина где-то посередине. В этой статье мы расскажем об основных принципах, следуя которым вы сможете найти баланс между стоимостью тестирования и качеством своего продукта.
Принцип №1. Начинайте тестировать как можно раньше
Одна из самых распространенных ошибок — это начинать тестировать продукт на поздних стадиях, когда он практически готов к релизу. Чем раньше команда тестирования (QA) подключается к процессу разработки, тем ниже вероятность пропустить ошибку в продакшн. Кроме того, ошибка выявленная на ранней стадии разработки обойдется дешевле. В разы. Наш опыт показывает, что цена фикса на поздних этапах может оказаться в 30 раз дороже, чем фикс этой же ошибки, например, на стадии прототипа.
Случай из практики: мы очень долго ждали в тестирование серверное приложение, которое собирало и обрабатывало большой массив данных пользователей. Разработчики просто отказывались отдавать его, мотивируя это тем, что у них много проблем, а тестирование можно провести и в конце. В итоге они работали над новой версией четыре месяца.
Когда мы начали тестировать приложение с реальным объемом пользовательских данных, оказалось, что выбранная архитектура базы данных не справляется с такой нагрузкой. Команде разработчиков из пяти человек пришлось заново всё планировать, переписывать дизайн и архитектуру приложения, а нам — тестировать его с нуля. Релиз состоялся на шесть недель позже планового.
Итог: желание сэкономить 150 человеко-часов на тестировании и отодвинуть его к релизу привело к потере 1100 человеко-часов своих сотрудников и двойным затратам на тестирование.
Принцип №2. Экономьте, но только не на аналитике
Допустим, вы прислушались к нашим аргументам и решили реализовать первый принцип. На каком этапе разработки продукта выгоднее всего раскошелиться и подключить команду тестирования? Ответ: на этапе планирования архитектуры приложения, ну или хотя бы на этапе анализа и подготовки требований.
Без грамотно проведенной аналитики вы рискуете выпустить на рынок идеальный продукт, который никому не нужен. Такое бывает, когда вы не учитываете особенности своей целевой аудитории.
Мы помним страшилку о приложении для бега, которое было заточено под пользователей из Азии. Оно бы обязательно понравилось ЦА и принесло прибыль, если бы клиенты смогли установить приложение на свои смартфоны. Но они не смогли, а знаете почему? На этапе сбора требований была допущена ошибка, из-за которой приложение тестировалось на айфонах и смартфонах Samsung, которых в Азии — минимум. Ведь азиатские пользователи однозначно отдают предпочтение Huawei и OPPO.
В нашем примере сэкономить у разработчика опять не получилось. Мало того, что пришлось потратить 300 человеко-часов на доработку и тестирование продукта, так еще и репутационные издержки практически поставили проект на колени.
Итог: вы можете пригласить специалистов со стороны или ограничиться своими силами, главное — помните, что потребительское тестирование на этапе поддержки обходится в десятки раз дороже. И под дороже мы подразумеваем не столько денежные убытки, сколько репутационные издержки. Не экономьте на аналитике. Только не на ней!
Принцип №3. Определите цели и ожидания
Конечно же, вы хотите, чтобы всё работало, и работало хорошо. Но этого мало. Вам нужно понимать, насколько хорошо и почему именно настолько.
Знаете, как распознать хорошего тест-менеджера? Он сразу начинает «пытать» вас, чтобы понять, какого именно качества продукт вам нужен. Мы называем это сбором ожиданий. Качество вашего ПО складывается из определенных кирпичиков. Опытный тест-менеджер захочет узнать, какие именно кирпичики нужно положить в фундамент качества.
Когда к нам приходит заказчик и говорит: «Я хочу, чтобы оно работало», мы начинаем его расспрашивать: какая основная цель создания продукта? какие функции наиболее востребованы пользователями? как они их используют?
После сбора ожиданий идет постановка SMART-целей, их декомпозиция, построение задач и таблиц KPI. В итоге мы четко определяем:
- виды тестирования;
- сроки их проведения;
- состав команды;
- и даже возможные риски.
Всё это необходимо для обеспечения нужного заказчику качества, без гадания на его нервах.
Иногда, правда, случаются казусы. На проекте интернет-магазина страховых услуг мы провели анализ и подготовили предложение. Ввиду сложности функционала и величины модулей, помимо полного функционального и регрессионного тестирования продукта, мы рекомендовали автоматизировать регресс. Несмотря на то что именно на регресс уходила большая часть времени, заказчик отказался от его автоматизации, мотивировав это тем, что имеется сильная команда «ручников», а автоматизация отнимет много времени и станет невыгодной. Все наши дальнейшие аргументы и расчеты игнорировались. Мы не смогли доказать свою позицию и три месяца тестировали регресс вручную, что, по сути, было убыточно для заказчика.
Затем проект свернули, два месяца анализировали и вернулись с предложением использовать план по автоматизации, который мы предложили пять месяцев назад.
Итог: нужно уметь не только понять цели проекта и желания клиента, но и доказать ему, что вы на его стороне и знаете, как получить выгоду. Иначе будет как у нас: слитый на ручное регрессионное тестирование бюджет, хотя автоматизация сэкономила бы и время, и деньги. Кстати, об автоматизации…
Принцип №4. Автоматизируйте
…Но мудро. И предварительно посчитав ROI.
Чтобы автоматизация экономила ваши деньги, продукт должен быть стабильным. Впрочем, если он очень динамично меняется, это не значит, что автоматизация вам не поможет. Использование тулов и специализированных программ — уже автоматизация. Например, вы поможете автоматить рутинные операции, съедающие время ваших тестировщиков. Скажем, написать утилиту, которая собирает нужные конфигурации.
Случай из практики: заказчик хотел релизиться каждый день вместо двух раз в неделю. При этом полное ручное регрессионное тестирование занимало два-три дня. А так как 80% функциональности продукта были устоявшимися и стабильными, было принято решение ее автоматизировать. Для этого мы разработали четыре сценария автоматизации и провели сравнительный анализ их эффективности. Обычно для этого мы используем восемь показателей:
- TC’s amount — количество кейсов в сценарии.
- Automation (man*days) — ресурсозатраты на автоматизацию сценария (без учета тестовых данных для каждого тест-кейса).
- 1 TC automation (man*hrs) — затраты на автоматизацию одного тест-кейса.
- Manual testing (man*days) — затраты на ручное тестирование сценария в целом.
- Results investigation (man*hrs) — затраты на исследование результатов прогона автотеста.
- Execution times — количество требуемых прогонов тестов за период работы над проектом. Данное число отражает ожидаемое количество прогонов с учетом стабильности функционала, требуемого графика прогонов тестов (регулярности получения информации) и т.д.
- Automation efficacy (%) — эффективность автоматизации тестирования в % от сэкономленного времени. Учитывая погрешности вычислений, эффективной можно признать автоматизацию с показателем более 150%.
- Saved time (man*days) — количество человеко-дней, сэкономленных за время всего проекта.
Вот как это выглядит на примере нашего проекта:
Окончательный отбор прошли два сценария автоматизации. Их использование позволило нам сократить регресс с двух дней до пары часов на прогон автотестов, плюс два часа на оставшиеся ручные проверки, которые автоматизировать оказалось нерентабельно.
Итог: автоматизация может сократить трудозатраты на тестирование в десятки раз, а может слить бюджет впустую. Без умения анализировать и считать ROI вы всегда рискуете навсегда разочароваться в автоматизации.
Принцип №5. Научитесь использовать новичков
Не хотите автоматизировать? Тестеры с опытом бьют по бюджету? Подумываете нанять рукастых выпускников вузов за небольшую, но разумную зарплату? Неплохая идея, но есть несколько нюансов. Даже если у вас несложный продукт, одних новичков вам не хватит.
Ребенок может найти баг в игре и сломать приложение по методу манки-тестинг, но найдет ли он все баги? Конечно нет. Мы очень любим новичков, но они, как правило, не владеют методами исследовательского тестирования. Зато они могут «ходить» по тестам. Поэтому на компанию новичков с горящими глазами нужен «старичок», который пропишет проверки на том уровне, который будет понятен вашим новичкам.
Например, мы привлекаем новичков под присмотром наставников даже к некоторым сложным проектам. Вначале процесс интеграции и адаптации новичка на проекте занимал месяц, что, разумеется, увеличивало сроки и стоимость тестирования. Для решения этой проблемы мы разработали «пакеты новичка» с тестовой документацией и всеми инструкциями по установке и настройке необходимых компонентов. Этот шаг позволил сократить срок полной адаптации сначала до двух недель, а после добавления в «пакет» набора наглядных кейсов и обучающих видео — до недели.
Фрагмент набора кейсов для тестирования страхового продукта представлен ниже.
«Пакет новичка» может включать что-то совсем простое, но полезное, типа генератора данных.
А может давать конкретные шаги по прохождению кейсов. Кстати, по нашему опыту, лучше всего давать новичкам именно тест-кейсы (с подробно расписанными шагами и предусловием), а не чек-листы.
Имея такой набор под рукой, новичок всегда будет знать, какой тест проходить, что делать и где искать недостающую информацию.
Итог: выгодно использовать труд новичков без потери качества и скорости тестирования вполне возможно. Junior способен приносить реальную пользу на проекте уже со второй недели, сократив потери времени на адаптацию в 4 раза (со 160 до 40 часов).
Опытный наставник и бизнес-процессы интеграции новичков помогут вырастить крутую команду в кратчайшие сроки. Мы вот регулярно так делаем, а количество классных тестировщиков, которых мы подготовили, уже превысило тысячу!
Принцип №6. Вам не нужны сто тестировщиков, вам нужны те, кто работает головой
Тестировщиков не должно быть много, их должно быть достаточно. Вы же не хотите потратиться на отличных опытных ребят, которые будут просто скучать на работе или заводить никому не нужные миноры? Точно так же вы не захотите, чтобы сорок разработчиков завалили одного несчастного специалиста по тестированию всеми своими фиксами и у него не хватало ни времени, ни энергии на качественную работу над задачами. Итак, шестое правило баланса цены и качества — искать этот баланс.
Интуиция — это важно, но всё же старайтесь прибегать к помощи стратегов и аналитиков, которые помогут вам оценить объем задач, необходимое вам количество людей и их квалификацию.
Распространенный случай из практики. Не так давно к нам обратился клиент, у которого в команде было 12 тестировщиков: ТМ, senior, middle и 9 junior. Мы провели аудит процессов тестирования и отказались от восьми тысяч ненужных задач (таких как регресс незатронутой обновлениями функциональности, заведение миноров и т.д.), плюс придумали, как оптимизировать тесты. Оказалось, что проект нуждается в трех автоматизаторах (предложили своих) и еще одном middlе, которого вырастили из числа junior. От остальных новичков пришлось отказаться.
Далее мы оставили тестирование критичного функционала в блоке «Идентификация и квитовка» на middle. Они проверяли его вручную, исследовательским тестированием. Все остальные блоки практически полностью ушли на автоматизаторов.
В итоге это позволило:
— Снизить стоимость предрелизного тестирования с 232 400 до 35 200 рублей.
— Повысить ROI тестирования за счет автоматизации в 5 раз.
— Снизить управленческую нагрузку на руководство.
— Сократить время предрелизного тестирования на 23 человеко-часа.
— Повысить качество тестирования, оставив на проекте только опытных тестировщиков.
Принцип №7. Посчитайте, что вам выгоднее: штат или аутсорс
Часто, но не всегда аутсорс обходится дешевле и позволяет нанять более опытных сотрудников со скидкой.
Еще один кейс из нашей практики: Как сэкономить более полутора миллионов рублей в год, наняв вместо девяти штатных тестировщиков с зарплатой 70 тысяч рублей девять аутсорсеров с зарплатой 130 тысяч.
Чтобы не быть голословными, покажем таблицу, которая объяснит, откуда берется такая выгода.
В нашем примере штатный тестировщик с окладом 70 тысяч рублей в месяц обходится компании на 14 877 рублей дороже, чем более дорогостоящий специалист-аутсорсер, имеющий почти вдвое больший оклад. Если взять в расчет отдел из 9 человек, которые отработали год, то выгода составит 1 606 716 рублей. А это уже деньги.
Впрочем, иногда бывает, что, даже понимая выгоду, компании не хотят отдавать тестирование на аутсорс. Например, мы часто сталкиваемся с желанием клиента перенести всё к себе в штат. Это связано со страхами и неготовностью делиться своими наработками и документацией с внешними заказчиками.
Такая позиция вполне оправдана: несмотря на все договоры о неразглашении, всегда остается риск случайной утечки информации, стоимость которой не покрывают потом никакие судебные иски. Чтобы не попасть в такую ситуацию, рекомендуем перестраховаться и обратиться к компании, в отношении которой за прошедшие десять лет не было возбуждено ни одного такого иска, предварительно пообщавшись с заявленными у нее на сайте клиентами.
Коротко о сказанном
1. По версии «Национального Института Стандартов и Технологии» стоимость тестирования в конце разработки может превышать её стоимость на начальных этапах в 15 раз, а после релиза в 30 раз.
Не хотите переплачивать? Начинайте тестировать как можно раньше!
2. Непонимание своей ЦА и её требований к продукту похоронило множество отличных проектов.
Экономите на аналитике? Готовьтесь платить за игру в угадайку!
3. Анализировать нужно не только ЦА, но и пожелания заказчиков. На их основе нужно уметь ставить и декомпозировать SMART-цели.
Не умеете ставить чёткие цели? Ваши цели непонятны заказчику? Закладывайте затраты на доработку и переделку!
4. Автоматизация помогает оптимизировать затраты на тестирование. Но не везде и не всегда.
Считаете, что руками тестировать выгоднее? Посчитайте ROI от автоматизации по нескольким сценариям и сравните цифры!
5. Новички в тестировании полны энтузиазма, но им не хватает опыта. Хороший наставник и «пакет новичка» повышает КПД джуна на проекте в 2–3 раза.
Набрали вчерашних выпускников за разумную плату? Готовьтесь доплатить за их превращение из «обезьянки» в человека!
6. Качество не равно количеству. Хороший специалист стоит дороже, потому что он даёт лучший результат.
Не хотите экономить, работая на результат? Тогда вам не стоит проводить аудит команды тестирования и оптимизировать её состав.
7. Аутсорс тестирования позволяет получить на проект опытную команду с гарантией результата. Но подходит аутсорс далеко не всем.
Хотите готовое решение с демократичным ценником? Рассчитайте преимущества от штата и от аутсорса, возможно второй вариант окажется в разы выгоднее.
Вместо эпилога
Качество — понятие многогранное, поэтому и его цена может варьироваться в зависимости от глубины понимания компанией этого термина. Есть много способов сэкономить в ущерб качеству, но не так много вариантов повысить качество без переплат. Соблюдение вышеперечисленных принципов помогло нам заработать надежную репутацию на рынке и лояльность наших клиентов, а самим клиентам — сэкономить силы, ресурсы и время.
Примерьте эти принципы на себя, они весьма просты, а потому эффективны. Надеемся, наша статья поможет вам сэкономить на тестировании без снижения качества. А еще мы ждем ваших вопросов, идей, предложений и замечаний в комментариях.
Нина Агеева,
Deputy Director at Лаборатория качества.
