Функциональное тестирование ПО. Часть 3

Что может повлиять на увеличение стоимости и сроков функционального тестирования на проекте?

На старте может быть много багов, ретестов — это деньги. Плохой код увеличивает стоимость тестирования. Сроки и стоимость равны количественному составу команды и затраченному времени. Важно при этом правильно спланировать трудоёмкость, сбалансировать объем работы и качество. Если текущее количество инженеров не успевает тестировать необходимый объем задач, то количество пропущенных багов может возрасти и пострадает качество работ. К такому результату обычно приводят плохое планирование работ и попытки сократить количество тестировщиков с целью снижения затрат. Обратный эффект: большая команда по тестированию с неполной загрузкой, затраты на простой команды и ожидание получения задач от разработки увеличивают затраты в пустую.

Например, заданный объем задач можно протестировать тщательнее, но с целью экономии времени и денег проверяют один смоук тест-план, не гоняют весь регресс, сокращают количество тестов, например с 800 до 400, работая с самыми критичными. Это может приводить к тому, что потом сыпятся некритичные баги при неверном выборе добавленных тестов в прогон. Понижение уровня качества влечет за собой ошибки на продуктиве, а они — более дорогие в исправлении. Но при верном планировании и оценке доработанного функционала можно сократить затраты, не проверяя ненужные тесты, по которым изменения в новом функционале не могли затронуть их работоспособность.

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


Как заказчику контролировать исполнителя?

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

Также необходимо рассчитывать уровень полезного КПД на команду: сколько багов и за какое количество времени поставщик нашел. Например, есть 500 кейсов, которые обычно проходим за N-количество времени, но мы их гоняем и никакие баги не находим. Может быть, и не надо эти 500 кейсов гонять, а сократить их количество, тем самым сэкономить время и деньги, или данное время потратить на другие задачи. Все зависит от проекта, SLA. Можно включить множество измеряемых параметров — не только отталкиваться, например, от багов. Есть, к примеру такой параметр — приоритет бага: насколько его надо быстро исправить либо протестировать. Предположим, критичный баг тестировщик должен за 15 минут взять в работу и провести ретест, как и разработчик начать исправление данного бага. Может, тестировать получится дольше, но взять в работу необходимо в конкретный временной промежуток. А если это нарушается, то поставщика можно штрафовать в каком-то процентном соотношении от контракта. Штрафы рассчитываются обычно по формуле и включают сумму нарушенных показателей, которые отражены в SLA. Если поставщик работает адекватно и выполняет свою работу, то его не надо ускорять и контролировать, и тогда SLA как таковой и не вступает в силу, хотя на практике бывают разные случаи.


Как получить возврат на инвестиции от внедрения функционального тестирования?

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


Когда стоит отдать тестирование ПО на аутсорс?

Когда у заказчика нет необходимых компетенций либо требуется усиление собственной команды в момент пиковой нагрузки.


Как выбрать поставщика функционального тестирования?

Я никогда не выбирал, я обычно с другой стороны: улыбаемся :)

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