Рынок клокотал. Малютки-диски расхватывались направо и налево. Яркие коробки с мудреными программами уходили на "Ура!". Тяжелые серверы увозили на тележках, любовно поглаживая по сверкающим бокам. Взлохмаченный старикашка заискивающе предлагал ПРМДО (программы домашние), завернутые в газету. В углу возле длинного прилавка зрел скандал. Серьезный мужчина, ухватив за руку толстого карапуза, возмущенно потрясал тоненьким серебристым блинчиком. "Это же не работает! Это же ....". Коробейник за прилавком привычно твердил о проверенном качестве и необыкновенной надежности своего товара: "А Вы пробовали так? А этак? А молотком били?" И тогда возмущенный покупатель двинул продавцу в ухо.

Из будущего "Готовься к всевозможным мукам, Когда берешь программу в руки"

На туманной заре информационно-компьютерной юности, в доДОСовскую эпоху, когда программы еще не стали товаром, а были скорее произведениями искусства, существовало нечто вроде натурального программного хозяйства.

"На своем дворе", в стабильном программном окружении, на той же машине, на которой проходила отладка, программы достойно отрабатывали возложенные на них обязанности. Эдакая буколическая идиллия истоков отрасли.

Став товаром, программное обеспечение отторглось от родного гнезда (аппаратура + системное ПО) и показало всю свою своеобразную, непредсказуемую натуру. Особенности производства такого товара состоят прежде всего в переносе центра тяжести с массового дублирования готового программного обеспечения на разработку, отладку и послепродажную корректировку и поддержку версий. С одной стороны, трудно ошибиться при дублировании запущенного в серию продукта, с другой - легко пропустить ошибку при проведении испытаний и внесении изменений. Поэтому в вопросах качества главную роль начинает играть первоначальный этап создания программного продукта с упором на его тестирование.

"Программа должна делать то, что должна делать, и не делать того, чего не должна"

Качество представляет собой понятие глубоко личностное и всегда относится к конкретному виду продукции. У каждого покупателя свое мнение о том, каким должен быть приобретаемый товар. Приведём два общих определения понятия качества: одно - прямое, а другое - от противного, с частицей "не". "Качество товара (продукта или услуг) - это удовлетворение его всем требованиям покупателя" (определение от IEEE). А с другой стороны: "Качественный товар - это товар без недостатков". Приложив эти определения к интересующей нас области, можно утверждать, что качество программного обеспечения - это выполнение заявленных функций по обработке информации. С другой стороны качественный программный продукт не должен выполнять никаких необъявленных действий с данными. Такие действия в рамках конкретной системы могут рассматриваться просто как порча информации.

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

"Сколько программу не тестируй, а она все волком смотрит"

Попробуем перечислить основные проблемы, связанные с процессом тестирования.

• Искать все ошибки, или грубейшие?
• Если не все, то как установить порог допустимости ошибки?
• Когда завершать тестирование?
• Что делать, если сроки поджимают и/или нет ресурсов на дальнейшее тестирование?
• Где остановиться в документировании тестов?
• Изменять тест или следовать первоначальной инструкции?

Процесс исправления ошибок имеет замкнутый, рефлекторный характер - уничтожение выявленной ошибки частенько приводит к появлению новых, даже более серьезных проблем. Если ошибка заложена в логической структуре программы, то, возможно, придётся менять логику и переписывать приличные куски кода. Как свидетельствует печальная статистика, каждое исправление ошибки имеет 15% вероятности породить новую ошибку.

• Чем раньше спроектирован тест, тем больше надежда на успех. Лучше всего проектировать тест еще на этапе логического построения системы.
• Недопустима хаотичность процесса тестирования. Он должен быть документирован и полностью управляем.
• Безусловно, необходимы повторяемость и завершенность тестов.
• Следует избегать добавления новых тестов в процессе тестирования.

"Мне плохого не надо"

Одна из попыток отделить приемлемое программное обеспечение от неподходящего для коммерческих целей - введение эмпирического термина "достаточно хорошее" ПО (good enough software), которое: приносит пользу; не имеет явно выраженных серьезных недостатков; коммерческая польза перевешивает недостатки, с точки зрения коммерческого использования дальнейшее совершенствование продукта принесёт больше вреда, чем пользы.

Термин "достаточно хороший" имеет смысл только по отношению к конкретному заказчику, в конкретное время и в контексте сравнения с другими подобными продуктами. Достоинство термина - естественность для массового покупателя: если мы покупаем товар, то он достаточно хорош. Недостаток - субъективность данной оценки и необходимость тщательного анализа продукта экспертами, выносящими заключение.

"Дайте мне хорошую тестовую программу, и я переверну мир"

Несмотря на все перечисленные трудности, рынок тестовых инструментов составляет примерно 1 млрд. долл. в год и ежегодно растет примерно на 20-30%. Все тестовые программы можно разделить на 3 группы по методам работы с программным обеспечением. Это "черный ящик", "белый ящик" и системные тесты. В то время как "черный ящик", не рассматривая структуру кода вообще, оперирует наборами входных данных и анализирует выходные, "белый ящик" пытается проверить как можно большее пространство кода, исходя из логической структуры программы. Эта структура может быть задана, например, древним методом блок-схем или описана в UML (Unified Modelling Language). Системные тесты анализируют критические моменты использования программой системных ресурсов компьютера. В первом случае загвоздка состоит в выборе исходных данных, понятно, что перебрать все возможные наборы за реальный срок невозможно. Проверка внутренней структуры программы чаще всего заключается в исследовании логической структуры и соответствия программного кода заложенному алгоритму.

Различные способы позволяют охватить наибольшее пространство кода или самые опасные его зоны, но не гарантируют полной алгоритмической корректности. "Белый ящик" наиболее тесно связан с "know how" разработчиков и поэтому является приватным инструментом. Системные тесты никоим образом не проверяют, насколько программа соответствует своим функциональным задачам. Поэтому идеальный вариант - использовать одновременно все три метода тестирования, если конечно достанет времени и денег. С чувством глубокого сожаления приходится отмечать, что современный тестовый инструментарий идеологически и концептуально повторяет методики 60-70 х гг.

"Беда, коли прогресса нет!"

Сегодняшний процесс тестирования напоминает игру в дартс с завязанными глазами. Денег, времени и сил тратится неимоверно много, а результаты получаются плачевные. Программы "перетестированы", а существенные ошибки не выявлены. Как драматический аккорд приведу вольный перевод взволнованного призыва Гейтса, отражающего прискорбное положение этой проблемы в MS: "Тестирование - это ещё одна область, разочаровавшая меня отсутствием прогресса. В Microsoft, как в типичной разрабатывающей группе, инженеры больше заняты тестированием, чем написанием кода. Хорошо, если инженер-разработчик проводит треть своего времени, тестируя готовую работу. И так продолжается на протяжении всей истории больших систем. Вы можете возразить, что существуют современные методы, позволяющие автоматизировать тестирование. Совсем чуть-чуть. Поэтому, если Вы знаете исследователя, который хочет работать над этой проблемой, мы были бы счастливы работать вместе с ним".

"Не плюй в колодец ISO9000..."

Попробуем рассмотреть проблему качества с позиций международной организации по стандартизации. Идея состоит в утверждении, что качество программного обеспечения напрямую зависит от качества процесса его создания и разработки. "По чистым трубам течёт чистая вода" - по меткому сравнению адептов такого подхода. Любимый термин этой организации - Software Quality Assurance (SQA). В применении к программному обеспечению SQA означает процесс демонстрации того, что качество программного продукта удовлетворяет некоторому заданному уровню. Очевидно, что тестирование является инструментом Software Quality Assurance. В 1991 г. SEI (Software Engineering Institute) разработал специальный стандарт CMM (Capability Maturity Model) где описаны 5 уровней, каждый из которых представляет собой следующую ступеньку на пути к дисциплинированному, измеряемому процессу создания ПО, который непрерывно совершенствуется.

"Ты от любимой ждёшь ответ? Тогда послушай мой совет: Оставь духи, оставь буклет, Не траться на большой букет. Дари набор из компонент - И милая не скажет: "Нет".

Привлекательность СММ стоит на трех китах процветания программистской компании: понимании процесса программирования, его оценке и планировании совершенствования этого процесса. Именно такая модель используется ISO для развития международных стандартов оценки процесса программирования.

Есть ли свет в конце тоннеля?

И оптимистичный финал в лучших традициях Голливуда - две широкие дороги, уходящие за горизонт. Это во-первых, возмужание фирм-разработчиков, их неуклонное восхождение по СММ к высотам идеальной организации процесса конструирования ПО. Во-вторых, как самая большая надежда, - компоненты.

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

Программные фирмы превращаются в фабрики по производству компонентов. Качество компонентов наряду с их функциональностью приобретает статус важнейшей характеристики. Появляются специальные программные "тренажеры", на которых тестируются компоненты. Возникает обратная связь "заказчик - разработчик", которая позволяет создавать востребованные программные продукты в разумные сроки с минимальными затратами.

В этих новых условиях возрастает роль системных интеграторов, которые кроме консервативной работы с заказчиками, исходя из готового набора ПО, обращаются к непосредственному контакту с фирмами-производителями. Вероятно, именно системным интеграторам достанется работа по проверке совместимости компонентов от различных производителей. Образуя некую "третью силу" в мире информационных технологий, именно такие компании могут помочь обрести устойчивость двум полюсам этого мира: покупателям и творцам. И программный мир избавится от ПО "второй свежести".

Парадоксы программной ошибки

• Ошибка - не всегда результат недостатков.
• Ошибка не всегда может быть выявлена.
• Выявленная ошибка не всегда может быть описана.
• Описанная ошибка не всегда может быть понята.
• Понятая ошибка не всегда может быть исправлена.
• Исправленная ошибка не всегда может улучшить качество программы.

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

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

Уровень управления. Если на 3-м уровне основная цель - качество продукта, то на 4-м уровне и выше основная задача - обеспечить качество процесса разработки. Организация должна установить набор измерений процесса и использовать эту систему оценок, чтобы инициировать правильные действия. После выработки оценок организация готова к непрерывному совершенствованию.

Уровень оптимизации. Измерения предыдущего уровня используются не только для оптимизации существующих, но и для оценки планируемых процессов. На этом уровне можно определять эффективность внедрения новых технологий.

Печальная статистика

Стоимость тестирования составляет 50% всей цены начальной разработки и 70% всей цены поддержки ПО. Сегодняшняя техника тестирования создавалась в 1960-1970 х гг. Но тогда речь шла о десятках Кбайт кода, сегодня - о сотнях Мбайт.

Только 50% разработчиков следуют международным стандартам.

Около 70% используют ОО дизайн.

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

Язык С++ дает на 25% больше ошибок, чем традиционные Си или Паскаль, а исправление ошибок в ОО программах на С++ требует в 2-3 раза больше времени. Наследование порождает в 6 раз больше ошибок.

33% всех ошибок случаются реже, чем 1 раз за 5 тыс. лет работы системы. Не более 2% - это общие ошибки, происходящие чаще, чем раз в 5 лет.

Свыше 70% всех компаний-разработчиков находятся на уровне 1 СММ.

Программное обеспечение, установленное на отдельном компьютере, в среднем удваивается каждые 18 месяцев, однако количество ошибок после отладки и тестирования сегодня такое же как и 30 лет назад – 0.5-2.0 ошибки на каждый Kбайт кода.