Работают ли бета-версии?

Всем, кто когда-либо работал с программным обеспечением производства Microsoft, IBM, Novell или другой компании, приходилось решать проблемы различной степени сложности, вызванные сбоями в работе ПО. Вам приходилось слышать о том, что Windows 2000 поставляется пользователям с 63000 ошибок? Если это правда, то мы все должны склонить голову перед Microsoft. При известных размерах кода Windows 2000 и соблюдении стандартов обеспечения качества производства, Microsoft могла бы не краснея поставлять этот продукт с гораздо большим количеством ошибок. Стандарты индустрии программного обеспечения допускают наличие 15 ошибок на 1000 строк кода. Если верить слухам, размер кода Windows 2000 достигает 40 миллионов строк. Элементарные подсчеты показывают, что мы вправе ожидать 600000 ошибок, при условии, что специалисты Microsoft разрабатывали Windows 2000, ориентируясь на «обычные» стандарты.

Компании-производители пытаются повысить качество программных продуктов с помощью тестирования. Существуют тестовые методики, использующие специальные драйверы, автоматически проверяющие промежуточные версии разрабатываемого продукта на различном аппаратном обеспечении. Другой способ проверки - бета-тестирование. В этом случае разработчики программного обеспечения разрешают пользователям попробовать предварительные версии продуктов. Однако большинство разработчиков, с которыми мне довелось общаться, утверждают, что внешние бета-тестеры не выявляют такого большого количества ошибок. Я вспоминаю, что Фрэнк Эртел, руководивший в свое время проектом в Microsoft, в 1996 году отмечал, что внешние бета-тестеры выявили менее 1 ошибки из 10 в пересчете на все обнаруженные дефекты за время тестирования Windows NT 4.0.

Я подозреваю, что большинство бета версий ценно исключительно с точки зрения маркетинга: при бета-тестировании покупатели вовлекаются в процесс создания продукта, чувствуют себя как бы участниками самого процесса разработки. Во время бета-тестирования производитель очень внимателен к советам покупателя, поскольку большая их часть действительно того заслуживает, и продукт от этого только выигрывает. Возможно, стоит отказаться от термина «бета-тестирование» и ввести что-то вроде «предварительного показа» или «анонсирования» продукта.

Но есть ли смысл вдаваться в такие лингвистические тонкости? Большинство экспертов по качеству программного обеспечения считают, что остановить поставку продуктов с сотнями и тысячами ошибок можно, лишь прекратив использовать тестирование как основной механизм обеспечения качества. Один из экспертов по качеству программного обеспечения, Ватс Хэмфри из Института качества программного обеспечения Карнеги-Мэллона, сформулировал этот тезис следующим образом ( в статье «К вопросу о качестве программных продуктов», http://www.2bguide.com/docs/whsq.html): «Ни в одной из технологически развитых отраслей промышленности, кроме разработки программного обеспечения, тестирование продуктов не является основным средством исправления ошибок. Давно известно, что тестирование есть крайне дорогой и неэффективный способ устранения дефектов в любом продукте, в том числе и в программах.»

Если отказаться от тестирования, то что можно сделать для обеспечения качества программных разработок? За годы работы программисты изобрели множество подходов к решению этой проблемы, и я не смогу выбрать лучший. Однако стоит отметить, что большинство альтернатив тестированию заимствованы из 50-летней практики совершенствования технологических процессов. Попробуем взглянуть на эту проблему так: что было бы, если бы фирма Boeing приняла на вооружение программистский подход при создании реактивных самолетов? («Ну как, Смиттерс, готовы ли мы к поставкам нового 787?». «Да, похоже на то. Ни один из бета-тестеров не сообщал об авиакатастрофах за последний месяц.») Вместо этого процесс проектирования в компании Boeing организован так, что особое значение придается тестированию именно в процессе разработки. И Boeing не приходится строить много тестовых самолетов, которые не летают. Поставщики программных продуктов могли бы выиграть от применения такого подхода, если бы потратили больше времени на разработку кода и меньше на его «набивку», прогон и ожидание очередного падения.

Однако будет ли это работать? В компании Motorola использовали методику качественной разработки при создании программного обеспечения для сотового телефона StarTAC. И каков результат? В 2 Мбайт кода обнаружено всего 24 ошибки. Возможно, когда-нибудь, главный разработчик программных продуктов применит нестандартный способ поддержания качества при разработке. Когда-нибудь…