Качество программного обеспечения? Что бы это значило? Коллективный разум предлагает немало формулировок, каждая из которых привносит свои штрихи: здесь и “степень соответствия требованиям”, и “способность программного продукта подтвердить свою спецификацию”, и “пригодность к использованию”, и даже “полнота свойств и характеристик продукта”. Все это правильно, все хорошо, но… пахнет нафталином. Формальные определения оказываются бесполезными в неформальных проектах. Есть продукт, как оценить его качество? Попробуем абстрагироваться от замшелых формулировок и взглянем на приложение глазами пользователя.
Что рядовой пользователь ждет от программного продукта? Скажем, от текстового редактора? Как минимум, возможность ввести, отредактировать и сохранить текст. А что не ждет? Ошибок вида “Программа выполнила недопустимую операцию”, “Ошибка обращения к странице памяти”, “Unspecified error”, “Segmentation Fault”. Не ждет падений, зависаний и т.п. Если ожидания нашего пользователя оправдались, текстовый редактор успешно прошел первый отборочный круг (или испытательный срок) в борьбе за право получить титул “качественный”. В следующем туре запросы пользователей будут потяжелее. За выход в полуфинал обязательно поборется Vim, славящийся мощной функциональностью и гибкостью в настройке. В списке претендентов окажется MS Word с богатыми возможностями форматирования текста. Остроту состязанию прибавят Emacs (мастер на все руки), Notepad2 (мал да удал) и множество других отличных текстовых редакторов. Какие из них взойдут на пьедестал качества? Что между ними общего?
Изо дня в день мы соприкасаемся с различными программными продуктами. Операционные системы, браузеры, системы бухучета и электронных платежей, базы данных, программы для мобильных устройств – список будет длинным. Какие из этих продуктов качественные? У каждого из нас свои критерии качества, но все многообразие наших вкусов, потребностей и предпочтений можно свести к одному знаменателю: программный продукт должен максимально соответствовать нашим ожиданиям и даже предвосхищать их. Итак,
Под качеством программного продукта будем понимать степень его соответствия потребностям пользователя. Чем выше степень соответствия, тем лучше качество продукта.
В наш бурный век технологии сменяют друг друга с космической скоростью. “Какое качество? Мы разрабатываем продукты быстро, качественно и недорого. Выберите два пункта”. Сторонники этого утверждения полагают, что любые две характеристики из множества “цена, скорость, качество” взаимоисключают третью. При таком подходе бедной Золушкой обычно оказывается качество продукта как наименее формализуемая его характеристика. Наш опыт показывает, что Золушка может стать принцессой, не затмив своим сиянием скорость разработки и стоимость продукта. “Think Win-Win, or No Deal”: программный продукт может и должен быть качественным. Почему? Потому что качество продукта существенно снижает общую стоимость его поддержки и позволяет оптимизировать продолжительность цикла разработки. И, самое главное, потому что “the best marketing in the world cannot force people to pay for a useless product” (Joel Spolsky).
Не существует единственно верных методик обеспечения качества, которые одинаково эффективны для любого программного продукта. В то же время при подготовке любого программного продукта можно найти и внедрить подходы и практики, которые будут эффективны в показателях качества, времени и стоимости разработки. Полезными могут оказаться наработки quality assurance, методы TDD, usability-исследования, идеи BDD. В целом, наиболее разумным нам представляется контекст-ориентированный подход, который предложил Cem Kaner: выбор оптимальных решений в зависимости от контекста, сотрудничество, внимание к качеству на каждом этапе разработки и внедрения программного продукта.
Бывает так, что потребности пользователя весьма туманны и даже противоречивы. Но, зачастую, именно в таких случаях и создаются великие программные продукты. Мы все в одной лодке: аналитики, разработчики, тестировщики, технические писатели. Мы знаем, что даже в условиях плохой видимости, когда трудно проложить курс, нужно обязательно думать не только о функциональности и usability продукта, но и о многих других его характеристиках. Производительность, надежность, безопасность, потребление системных ресурсов, резервное копирование, восстановление и обновление, масштабируемость, документация – вот далеко не все ориентиры качества, по которым мы прокладываем наш путь. Совместная слаженная работа позволит нам не только выплыть, но и потрясти мир.
Что такое качество программного обеспечения и как его улучшить: теория и практика, задачи и решения, подводные камни и обходные пути.
[…] и денежные ресурсы, риски. Выбор в соответствии с контекстом будет наиболее […]
Оповещение : Качество программного обеспечения » Автоматизация тестирования: выбор инструмента | Август 2, 2008
[…] мы не хотим жертвовать качеством, верно? Вот здесь на помощь и придут автотесты. […]
Оповещение : OpenQuality.ru | Автоматизация тестирования: зачем это нужно? | Сентябрь 22, 2008
[…] программах нужно находить как можно раньше. Нам важно качество, а не количество, […]
Оповещение : OpenQuality.ru | Три заблуждения начинающих тестировщиков | Сентябрь 29, 2008
[…] отношение это имеет к качеству программного обеспечения? Программный продукт создается для конечного […]
Оповещение : OpenQuality.ru | Последняя миля в разработке ПО | Октябрь 26, 2008
[…] Опытный тестировщик — хороший диагност. Этакий Доктор Хаус, который видит продукт насквозь. Изучить приложение вдоль и поперек, увидеть невидимое, предсказать поведение системы — непростые задачи, но, решив их, тестировщик чувствует свою сопричастность к высокому качеству программного продукта. […]
Оповещение : OpenQuality.ru | Счастье быть тестировщиком | Декабрь 15, 2008
[…] Качество программного обеспечения достигается не только и не столько поиском/исправлением багов, сколько принятием оптимальных решений на каждом этапе разработки приложения. Если у качества ПО высокий весовой коэффициент, то это уже полдела. Вторая половина – вдумчивый анализ, исследование альтернатив, явных и неявных. И тогда мы получим не только завершение проекта в срок, но и качественный, востребованный продукт. […]
Оповещение : OpenQuality.ru | Качество ПО и девушка мечты: дорогу осилит ищущий | Апрель 1, 2009
Соответствие требованиям пользователя - это внешнее качество продукта. А есть еще и внутренне качество проекта и продукта. Например, степень повторного использования компонент, простота переносимости, простота модифицируемости. Внутренне качество влияет на внешнее, но степенью этого влияния оценить сложно - только с помощью экспертов.
Автор : Валерий | Сентябрь 22, 2009
Ошибся в почтовом адресе - повторно отправляю.
Автор : Валерий | Сентябрь 22, 2009
Валерий, спасибо за комментарий! Да, безусловно. Я не стал говорить о “внутренних” характеристиках, потому что они достаточно неплохо освещены в материалах, которые можно найти по первым трем ссылкам в моем посте. Просто захотелось внести свою лепту и сделать акцент на конечном результате.
Интересный момент: “внутренние” характеристики могут быть ужасны, а пользователь – счастлив. И наоборот. Кстати, вот интересная статья, которую сегодня опубликовал Joel: http://www.joelonsoftware.com/items/2009/09/23.html . Здесь речь не идет о качестве ПО, но выводы можно сделать очень близкие.
Автор : Капитан Аляска | Сентябрь 24, 2009