Как сэкономить 3000% расходов на тестировании, или для чего нужен комплексный подход при внедрении безопасности

Как сэкономить 3000% расходов на тестировании, или для чего нужен комплексный подход при внедрении безопасности

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


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


Раньше вложишь больше сэкономишь


Ни для кого не секрет, что чем раньше найден дефект, тем дешевле его исправление. Независимо от текущего этапа проекта в случае обнаружения дефекта безопасности необходимо возвращаться на этап разработки требований и архитектуры и вносить исправления во все последующие этапы. По данным исследований Института Понемона и корпорации PGP (http://www.anti-malware.ru/files/Ponemon_Annual_Study_Cost_of_a_Data_Breach_US_2008.pdf), стоимость исправления дефекта безопасности на этапе производства и выпуска может стоить до 30 раз (это 3000%!) больше, чем, если бы дефект был найден на этапе разработки требований и архитектуры.


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


Вот такие незапланированные траты и отсрочки от одного лишь дефекта! А что если этих дефектов несколько, или исправление одного вызвало новую ошибку?


Читать далее



r

© A1QA for A1QA Blog , 2014. |r
Permalink |r
No comment |r
Add tor
del.icio.us r

r
Post tags:
r


Feed enhanced by Better Feed from Ozh


U
Alt text

Тени в интернете всегда следят за вами

Станьте невидимкой – подключайтесь к нашему каналу.

a1qa

Все о тестировании и качестве ПО