OpenQuality.ru
Качество программного обеспечения
Качество программного обеспечения? Что бы это значило? Коллективный разум предлагает немало формулировок: здесь и “степень соответствия требованиям”, и “способность программного продукта подтвердить свою спецификацию”, и “пригодность к использованию”, и даже “полнота свойств и характеристик продукта”. Все это правильно, хорошо, но … пахнет нафталином. Формальные определения оказываются бесполезными в неформальных проектах. Есть продукт, как оценить его качество? Попробуем абстрагироваться от замшелых трактовок и взглянуть на приложение глазами пользователя.
Что рядовой пользователь ждет от программного продукта? Скажем, от текстового редактора? Как минимум, возможность ввести, отредактировать и сохранить текст. А что не ждет? Падений и зависаний, ошибок вида “Программа выполнила недопустимую операцию”, “Ошибка обращения к странице памяти”, “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 продукта, но и о многих других его характеристиках. Производительность, надежность, безопасность, потребление системных ресурсов, резервное копирование, восстановление и обновление, масштабируемость, документация – вот далеко не все ориентиры качества, по которым мы прокладываем наш путь. Совместная слаженная работа позволит нам не только выплыть, но и потрясти мир.
Что такое качество программного обеспечения и как его улучшить: теория и практика, задачи и решения, подводные камни и обходные пути.
[…] и денежные ресурсы, риски. Выбор в соответствии с контекстом будет наиболее […]
Pingback : Качество программного обеспечения » Автоматизация тестирования: выбор инструмента | August 2, 2008
[…] мы не хотим жертвовать качеством, верно? Вот здесь на помощь и придут автотесты. […]
Pingback : OpenQuality.ru | Автоматизация тестирования: зачем это нужно? | September 22, 2008
[…] программах нужно находить как можно раньше. Нам важно качество, а не количество, […]
Pingback : OpenQuality.ru | Три заблуждения начинающих тестировщиков | September 29, 2008
[…] отношение это имеет к качеству программного обеспечения? Программный продукт создается для конечного […]
Pingback : OpenQuality.ru | Последняя миля в разработке ПО | October 26, 2008
[…] Опытный тестировщик — хороший диагност. Этакий Доктор Хаус, который видит продукт насквозь. Изучить приложение вдоль и поперек, увидеть невидимое, предсказать поведение системы — непростые задачи, но, решив их, тестировщик чувствует свою сопричастность к высокому качеству программного продукта. […]
Pingback : OpenQuality.ru | Счастье быть тестировщиком | December 15, 2008
[…] Качество программного обеспечения достигается не только и не столько поиском/исправлением багов, сколько принятием оптимальных решений на каждом этапе разработки приложения. Если у качества ПО высокий весовой коэффициент, то это уже полдела. Вторая половина – вдумчивый анализ, исследование альтернатив, явных и неявных. И тогда мы получим не только завершение проекта в срок, но и качественный, востребованный продукт. […]
Pingback : OpenQuality.ru | Качество ПО и девушка мечты: дорогу осилит ищущий | April 1, 2009
Соответствие требованиям пользователя - это внешнее качество продукта. А есть еще и внутренне качество проекта и продукта. Например, степень повторного использования компонент, простота переносимости, простота модифицируемости. Внутренне качество влияет на внешнее, но степенью этого влияния оценить сложно - только с помощью экспертов.
Автор : Валерий | September 22, 2009
Ошибся в почтовом адресе - повторно отправляю.
Автор : Валерий | September 22, 2009
Валерий, спасибо за комментарий! Да, безусловно. Я не стал говорить о “внутренних” характеристиках, потому что они достаточно неплохо освещены в материалах, которые можно найти по первым трем ссылкам в моем посте. Просто захотелось внести свою лепту и сделать акцент на конечном результате.
Интересный момент: “внутренние” характеристики могут быть ужасны, а пользователь – счастлив. И наоборот. Кстати, вот интересная статья, которую сегодня опубликовал Joel: http://www.joelonsoftware.com/items/2009/09/23.html . Здесь речь не идет о качестве ПО, но выводы можно сделать очень близкие.
Автор : Капитан Аляска | September 24, 2009
[…] отлов логических ошибок. В деле обеспечения качества продукта они необходимы, но недостаточны. Над ними […]
Pingback : OpenQuality.ru | Качество программного обеспечения | August 16, 2010