Ну что мы все о качестве да о качестве? Прокисшее молоко? Хранили в ненадлежащих условиях. Равнодушный терапевт? Маленькая зарплата врача в государственной клинике. Отслаивающийся потолок? Халтура и экономия бригады на стройматериалах. Могут быть и другие обстоятельства, но в целом есть причины и есть следствия, все очевидно, не о чем говорить. Тогда в чем особенность программных продуктов? Почему качество программного обеспечения вызывает столько обсуждений, споров и дискуссий? Наверное, потому что программное обеспечение обладает уникальными характеристиками, которых нет у других творений человеческих рук:
1. Круг влияния. Программные продукты проникают во все сферы нашей деятельности. Чем больше мы от них зависим, тем большего от них ждем. И тем больше теряем, если наши ожидания не оправдываются.
2. Динамика изменений. Технологии, применяемые в разработке ПО, сменяют друг друга с космической скоростью. В каждом новом языке программирования, среде разработки, операционной системе их создатели стремятся учесть опыт предшественников, но тем не менее привносят новые задачи и новые рубежи.
3. Многообразие программных систем. Значительная часть проектов – инновационные. Автоматизировать работу предприятия «А» не удастся точно так же как работу предприятия «Б». На предприятии «Б» своя специфика, свои скелеты в шкафу. Более того, видение продукта в финальной стадии цикла разработки может кардинально отличаться от первоначальных требований. Строили шалаш, но потом решили, что это будет аэропорт.
Как оценить качество ПО? Коллективный разум предлагает немало формулировок: здесь и “степень соответствия требованиям”, и “способность программного продукта подтвердить свою спецификацию”, и “пригодность к использованию”, и даже “полнота свойств и характеристик продукта”. Все это правильно, хорошо, но … пахнет нафталином. Формальные определения оказываются бесполезными в неформальных проектах. Есть продукт, как оценить его качество? Попробуем абстрагироваться от замшелых постулатов и взглянуть на приложение глазами … чьими глазами?
Что рядовой пользователь ждет от текстового редактора? Как минимум, возможность ввести, отредактировать и сохранить текст. А что не ждет? Падений и зависаний, ошибок вида “Программа выполнила недопустимую операцию”, “Ошибка обращения к странице памяти”, “Unspecified error”, “Segmentation Fault”. Если ожидания нашего пользователя оправдались, текстовый редактор успешно прошел первый отборочный круг (или испытательный срок) в борьбе за право получить титул “качественный”. В следующем туре запросы пользователей будут посерьезнее. Насколько эффективна работа в данном текстовом редакторе? Vim славится мощной функциональностью и гибкостью в настройке. MS Word обладает богатыми возможностями форматирования текста. Emacs мастер на все руки, а Notepad2 мал да удал. Есть множество других отличных текстовых редакторов. Какие из них взойдут на пьедестал качества?
Изо дня в день пользователь соприкасается с различными программными продуктами. Операционные системы, браузеры, системы бухучета и электронных платежей, базы данных, программы для мобильных устройств – список будет длинным. Какие из этих продуктов качественные? У каждого пользователя свои критерии качества, но все многообразие вкусов, потребностей и предпочтений можно свести к одному знаменателю: программный продукт должен максимально соответствовать нашим ожиданиям и даже предвосхищать их. Итак,
Под качеством программного продукта будем понимать степень его соответствия потребностям пользователя. Чем выше степень соответствия, тем лучше качество продукта.
Что можно сказать о читаемости кода? Понятна ли его логическая структура? Есть ли к нему документация, комментарии? Насколько удобно проводить рефакторинг? Портируемый ли код? Насколько бережно и эффективно используются ресурсы системы (время CPU, оперативная память, жесткий диск)?
Под качеством программного продукта будем понимать качество его исходного кода.
Какова тестируемость приложения? Позволяет ли оно проверить себя через пользовательский интерфейс и “изнутри” (обращением к методам класса и свойством объектов). Насколько сложно оценить производительность системы, ее надежность и безопасность?
Под качеством программного продукта будем понимать возможность проверить это качество.
Пришла беда, отворяй ворота? Пользователь рвет и мечет? Есть ли возможность по его воплям понять, в какую лужу он залез и как его оттуда вытащить? Можно ли включить трейсы? Можно ли снять снапшот продукта в среде пользователя с тем чтобы понять, что там происходит? Можно ли помочь пользователю без переустановки всей системы?
Под качеством программного продукта будем понимать возможность быстро и эффективно помочь пользователю в форс-мажорных обстоятельствах.
Насколько продукт привлекателен для пользователя? Какой стратегии он следует? К десяти популярным текстовым редакторам добавляется одиннадцатый, но со своей изюминкой? Или можно следовать стратегии “голубого океана”, когда создается новый продукт, который формирует потребности пользователя.
Под качеством программного продукта будем понимать его способность найти свою рыночную нишу.
Какие сторонние библиотеки применяются в продукте? Насколько легально их использование? Как на жизненном цикле продукта скажется изменение лицензии на тот или иной сторонний компонент? И взгляд с другой стороны: насколько защищены наш собственный продукт? Есть ли юридический барьер на пути плагиаторов и патентных троллей?
Под качеством программного продукта будем понимать его юридическую выживаемость в современном мире.
Система требует допиливания? Так ведь это то что надо! Врубиться в ее потроха, разобрать по косточкам и настроить конфигурацию своей мечты! А еще лучше сделать патч и представить его на рассмотрение создателям продукта.
Под качеством программного продукта будем понимать возможность отправиться в увлекательное путешествие по его настройке.
Как много их, этих глаз, пристально оценивающих наши продукты. К примеру, не учтены интересы менеджера проекта и супруги пользователя продукта. Обязательно нужно учесть. С точки зрения менеджера, качественный продукт позволит ему оставить след в истории, строчку в резюме и накопления на банковском счету. А для супруги пользователя критерием качества “игрушки” будет возможность оторвать от нее своего мужа :).
Заметим, что наличие/отсутствие багов является лишь косвенным показателем качества продукта.
“Какое качество? Мы разрабатываем продукты быстро, качественно и недорого. Выберите два пункта”. Сторонники этого утверждения полагают, что любые две характеристики из множества “цена, скорость, качество” взаимоисключают третью. При таком подходе бедной Золушкой обычно оказывается качество продукта как наименее формализуемая его характеристика. Но Золушка может стать принцессой, не затмив своей привлекательностью скорость разработки и стоимость продукта. “Think Win-Win, or No Deal”: программный продукт может и должен быть качественным. Почему? Потому что качество продукта существенно снижает общую стоимость его поддержки и позволяет оптимизировать продолжительность цикла разработки. И, самое главное, потому что “the best marketing in the world cannot force people to pay for a useless product” (Joel Spolsky).
При создании любой системы можно найти и внедрить подходы и практики, которые будут эффективны в показателях качества, времени и стоимости разработки. Наиболее разумным нам представляется контекст-ориентированный подход, который предложил 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
Ошибся в почтовом адресе - повторно отправляю.
[Ответить]
Автор комментария : Капитан Аляска | September 24, 2009
Валерий, спасибо за комментарий! Да, безусловно. Я не стал говорить о “внутренних” характеристиках, потому что они достаточно неплохо освещены в материалах, которые можно найти по первым трем ссылкам в моем посте. Просто захотелось внести свою лепту и сделать акцент на конечном результате.
Интересный момент: “внутренние” характеристики могут быть ужасны, а пользователь – счастлив. И наоборот. Кстати, вот интересная статья, которую сегодня опубликовал Joel: http://www.joelonsoftware.com/items/2009/09/23.html . Здесь речь не идет о качестве ПО, но выводы можно сделать очень близкие.
[Ответить]
Pingback : OpenQuality.ru | Качество программного обеспечения | August 16, 2010
[…] отлов логических ошибок. В деле обеспечения качества продукта они необходимы, но недостаточны. Над ними […]
Pingback : OpenQuality.ru | Качество программного обеспечения | April 1, 2012
[…] более эффективно решать часть задач по обеспечению качества, которые обычно возложены на тестировщиков. Мартина […]
Pingback : OpenQuality.ru | Качество программного обеспечения | June 22, 2012
[…] но и на благо проекта. Если во главу угла ставится качественный, надежный продукт, то искажениям информации просто не […]