С ростом сложности ИТ- инфраструктуры из-за количества интегрируемых ИТ-систем происходит естественное увеличение потребности в тестировании ПО. Увеличивается количество и сложность тестов, а это, в свою очередь, существенно замедляет выпуск продуктов в эксплуатацию. С другой стороны, почти все организации стремятся сократить время выпуска программных продуктов, поэтому удлинение жизненного цикла ПО за счет возрастающих объемов тестирования воспринимается негативно. Иногда это превращается в частичный или даже полный отказ от тестирования и приводит к заметному снижению качества ИТ-услуг.
Пренебрежение тестированием приводит к следующим последствиям:
- снижение качества разрабатываемого продукта (первопричина всех остальных вытекающих последствий);
- постоянный рост косвенных затрат на обеспечение качества из-за возникновения дефектов ПО в промышленной эксплуатации;
- потеря клиентов, которые не желают пользоваться некачественным продуктом.
Желательно тестирование вводить как можно раньше, на этапе анализа требований, но давайте определим оптимальный момент, когда можно начинать тестировать.
Согласно исследованиям компании IBM стоимость дефекта увеличивается со временем (подробный отчет здесь).
Предположим, что один час работы разработчика стоит 25$ и на устранение дефекта на стадии архитектурного планирования потребовалось бы 2 часа, т.е. стоимость устранения дефекта была бы равна 50$.
Если бы дефект был найден во время второй фазы разработки, то стоимость увеличилась бы в 5 раз и стала бы 250 $. Стоимость устранения дефекта в фазе тестирования уже вырастает в 10 раз (500 $), в фазе бета-тестирования в 15 раз (750$). После релиза стоимость вырастет в 30 раз от первоначальной и будет равна 1500 $. Как видно, стоимость устранения одного и того же дефекта изменяется от 50$ до 1500$, в зависимости от времени его обнаружения.
График, представленный ниже, иллюстрирует зависимость стоимости устранения дефекта во времени жизни продукта:
Прямая времени (time) содержит несколько точек на своей оси:
A: дефект появился в системе вместе с коммитом кода.
B: Прошло менее одного дня, дефект не проявлялся раньше, но воспроизвелся при выполнении некоторой последовательности шагов. Такой дефект очень легко исправить.
C: Через несколько дней: мы помним какие изменения были произведены в системе, которые могли стать причиной дефекта, что может вызвать необходимость перепроверить дополнительные изменения, которые были введены в систему после тех, что стали причиной дефекта. Но, тем не менее, его все еще можно исправить без существенных затрат.
D: Выпуск/релиз: дефект начинает влиять на потребителя, а также на целостность вашей системы. Пофиксить дефект станет сложнее, это потребует дополнительных усилий.
E: Дефект пробыл в продукте на протяжении какого-то времени после релиза и уже повлиял на те части кода, которые не подвергались изменениям. Пользователи знают о том, что он есть, и вынуждены смириться с его существованием. Тем не менее, починить его становится сложнее, поскольку он уже глубоко в системе, и разработчик практически забыл, какие изменения стали причиной его возникновения.
F: Дефект существует в системе уже длительное время, и человек, который вводил изменения, вызвавшие данный дефект, больше не работает в компании. Починить такой дефект крайне сложно.
Зеленая линия отображает сумму всех затрат на исправление дефекта с течением времени и включает в себя:
- Исправление дефекта, найденного на стадии разработки. Здесь стоимость дефекта равна нулю, поскольку во время программирования разработчик замечает дефект и сразу же его исправляет.
- Переключение процессов – исключение прочих задач и концентрация внимания на понимании функциональной и технической стороны дефекта. Если дефект обнаружен разработчиком сразу окончания разработки, до фазы тестирования, в таком случае, стоимость исправления также близка к нулю, поскольку девелопер легко к нему возвращается и исправляет. В случае, если фикс выполняется иным сотрудником или, когда знаний о том, что вызвало дефект, нет (как в пункте F), стоимость фикса вырастает многократно.
- Определение причины дефекта. В данном случае стоимость увеличивается постепенно с ростом сложности разработанного приложения и с учетом того факта, что с течением времени люди, которые имели представление о причинах его возникновения, забывают об изменениях, которые его вызвали.
- Исправление дефекта после релиза. Чем больше функционала добавлено поверх неисправленного дефекта, тем сложнее и дороже его исправить. Также это существенно увеличивает риск ввода дополнительных дефектов.
- Влияние на потребителя, репутацию вашей компании. Здесь дополнительная потеря средств вызвана c поддержкой потребителя и потерей имиджа продукта. Чем дольше дефект находится в продукте, тем больший ущерб он приносит.
Наиболее известны потери компании Toyota, обнаруженные в продукте после релиза.
В 2009 году Toyota отзывала проданные автомобили в связи с заклиниванием педали акселератора. Один из пассажиров Lexus ES350 позвонил в службу спасения: автомобиль начал неконтролируемо ускоряться на скорости 100 км/час и перестал реагировать на педаль тормоза. Погибли четверо пассажиров. В ноябре 2009 дилерам было предписано укоротить педаль газа, обновить программное обеспечение автомобилей и протестировать приложение содержащее ошибку, вызвавшую задержку в работе тормозной системы. Таким образом, к 2010 году было отозвано около 8,2 млн автомобилей. Не трудно представить масштаб затрат на исправление этой ошибки.
Стоит также отметить, что есть 2 вида затрат: косвенные и прямые.
Прямые затраты – средства, которые компания тратит на поддержку продукта в хорошем состоянии, т.е., по сути, на оплату труда всем задействованным в работе над проектом, включая QA.
Косвенные — это затраты, связанные с качеством продукта, привыканием пользователей к новому продукту. В случае если тестирование продукта происходило с момента начала разработки проекта, прямые затраты на поддержку качества продукта всегда остаются примерно на одном уровне и растут только вместе с ростом проекта, а косвенные затраты минимизированы. В случае же когда тестирование не проводится вовсе, стоимость прямых затрат на тестирование отсутствует, а косвенные затраты от некачественного ПО растут безгранично. Для того, чтобы уменьшить рост косвенных затрат, необходимо вводить тестирование как можно раньше, как минимум до релиза, лучше всего в начале анализа требований к продукту и подготовке проектной документации.
Исходя из вышеперечисленного можно сделать вывод, что наиболее безболезненно и наименее затратно выпустить продукт в релиз можно в случае, если тестирование на предмет существования дефектов вводить как можно раньше, а именно на этапе формирования требований или во время разработки проекта. Не стоит экономить на тестировании, отсутствие которого приводит к недовольству пользователей продуктом, неконтролируемым расходам и может вылиться в потерю значительных средств.
