Управление качеством программного обеспечения — software quality management

Введение

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

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

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

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

Введение

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

Условия тестирования и обеспечения качества ПО (QA) часто используются в IT-индустрии профессионалами тестирования (часто классифицируемыми как профессионалы по обеспечению качества).

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

Чтобы оценить различия между тестированием и QA, важно сначала понять тесно связанные с ними понятия — контроль качества (QС) и обеспечение качества (QA)

Избегайте преждевременной оптимизации

Дональд Кнут утверждал, что корень всего зла в программировании — преждевременная оптимизация.

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

Причина в том, что приоритизация кода занимает много времени и значительно усложняется, если делать её не вовремя. Кроме того, в процессе реализации наиболее оптимального решения требования могут измениться. Если это произойдет, ваша программа окажется в мусорной корзине или ее будет сложно изменить.

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

Управление качеством программного обеспечения

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

1. Набор функциональных возможностей, то есть, программное обеспечение обязано удовлетворять заданные потребности пользователя, что означает выполнение требуемых функций.
2. Требование эффективности, то есть, должно выполняться соотношение между качеством функционирования программного обеспечения и требованиями, предъявляемыми им к ресурсам.
3. Требование мобильности, то есть, наличие переносимости программного обеспечения под разные архитектуры и платформы.
4. Наличие удобного использования.
5. Требование надежности, то есть, программное обеспечение должно обладать устойчивостью к сбоям.
6. Наличие удобного сопровождения, то есть, возможности вносить
7. Изменения и дополнения в программное обеспечение.

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

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

В соответствии с ANSI/IEEE Std 610.12-1990, жизненным циклом программного обеспечения считается период времени, от момента принятия решения о необходимости реализации программного продукта до момента его полной утилизации. Жизненный цикл может делиться на ряд этапов, куда входит разработка и использование программного обеспечения. Следует выделить несколько моделей жизненного цикла, в зависимости от методов деления его на этапы. На рисунке ниже в виде схемы показаны каскадная и итерационная модели жизненного цикла.

Рисунок 1. Каскадная и итерационная модели жизненного цикла. Автор24 — интернет-биржа студенческих работ

В этих моделях разработка программного обеспечения подразделяется на следующие этапы:

1. Этап формулирования требований к продукту.
2. Этап проектирования.
3. Этап формирования кодов.
4. Этап отладки.
5. Этап внедрения.
6. Этап поддержки.

Переход к началу следующего этапа следует производить только по завершении работ на предыдущем этапе.

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

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

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

Что же такое качество?

Для начала давайте определимся что же такое качество? Как гарантировать качество? Как его контролировать и управлять? 

Существует множество международных стандартов, таких как ISO9000, ISO9126 (был заменен ISO/IEC 25010:2011) и т.д., которые дают некоторые определения качеству и процессам.

Так, к примеру согласно ISO9000. Качество — это степень соответствия совокупности присущих характеристик объекта требованиям.

Хмм…Окей. Выглядит заумно. Как насчет программного обеспечения? На это отвечает стандарт ISO 9126.

Качество программного обеспечения — это

• Способность программного продукта при заданных условиях удовлетворять установленным или предполагаемым требованиям.

• Весь объём признаков и характеристик программ, который относится к их способности удовлетворять установленным или предполагаемым требованиям.

• Степень, в которой система, компонент или процесс удовлетворяют требованиям или ожиданиям заказчика или пользователя.

Как видно из определений, качество и требования тесно связаны и любой объект (будь то ювелирное украшение или программное обеспечение), который считается качественным, должен удовлетворять установленным требованиям.

Согласно тому же стандарту ISO9126 качество программного обеспечения имеет внутренние и внешние характеристики. Каждая характеристика детализируется субхарактеристиками.

К внешним характеристика качества относятся:

• Функциональность (Functionality) — Набор атрибутов, которые влияют на существование набора функций и их заданных свойств. Функции — это характеристики ПО, которые удовлетворяют заявленные или подразумеваемые потребности.

• Надежность (Reliability) — Набор атрибутов, которые влияют на способность программного обеспечения поддерживать свой уровень производительности при указанных условиях в течение указанного периода времени.

• Юзабилити (Usability) — Набор атрибутов, которые влияют на усилия, необходимые для использования, и на индивидуальную оценку такого использования заявленным или подразумеваемым набором пользователей.

• Эффективность (Efficiency) — Набор атрибутов, которые влияют на взаимосвязь между уровнем производительности программного обеспечения и количеством используемых ресурсов при указанных условиях

• Портируемость (Portability) — Набор атрибутов, влияющих на возможность передачи программного обеспечения из одной среды в другую.

К внутренним качествам относятся:

• Сопровождаемость (Maintainability) — Набор атрибутов, влияющих на усилия, необходимые для внесения определённых изменений.

• Тестируемость (Testability) — Набор атрибутов, влияющих на усилия, необходимые для проверки программного обеспечения после проведения какого-либо видоизменения.

Данные семь характеристик достаточны для того, чтобы программное обеспечение считалось качественным.

Но как гарантировать качество? Как контролировать и управлять? Какие процессы отвечают за это?

Дважды отмерь и один раз отрежь (Measure Twice and Cut Once)

Некачественно выполненный этап написания требований обычно приводит к более чем 50% проблем в разработке. Поэтому подготовьтесь, разработав системный подход к процессу программирования.

Дважды проверьте все требования проекта, чтобы убедиться, что вы ничего не упускаете и не добавляете лишнего в свой код. После этого сделайте наброски, которые будут направлять весь процесс для получения высококачественного кода. Всегда тестируйте свой проект с самых основ, чтобы убедиться, что все в порядке.

Этот принцип дает гораздо более предсказуемые результаты, особенно если стоимость проекта уже высока. Вы избавите себя от головной боли, связанной с удалением или добавлением строк кода в соответствии с требованиями.

Преимущества

Успешная QA-команда может добавить значительную ценность для организации. Некоторые из этих преимуществ включают в себя:

Бесплатные вебинары по схожей тематике:

GitLab CI для тестировщика.

Антон Якутович

Как стать Automation QA специалистом? Часть 1.

Александр Бреславец

Successful testing on mobile devices

Виталий Татаринов

• Повышение качества производимой продукции
• Последовательность в процесах, используемых для доставки
• Продолжение совершенствования организации процессов
• Снижение общих расходов на доставку
• Увеличение приложений для документаци по поддержке продукта

Рекомендации

Статья основана на материалах, взятых из Бесплатный онлайн-словарь по вычислительной технике до 1 ноября 2008 г. и зарегистрированы в соответствии с условиями «перелицензирования» GFDL, версия 1.3 или новее.

1. ^
2. ^
3. ^ Соммервиль, И. (2011). «Глава 24: Управление качеством». Программная инженерия (9-е изд.). Эддисон-Уэсли. С. 651–680. ISBN  .
4. Келемен, З. Д. (2013). Эйндховен: Технический университет Эйндховена. ISBN  978-90-386-3313-8
5. OGC (Управление государственной торговли) (2009 г.). Управление успешными проектами с помощью PRINCE2 (изд. 2009 г.). TSO (Канцелярия). ISBN  978-0-11-331059-3
6. Руководство к Своду знаний по управлению проектами, четвертое издание, PMI, США, 2008 г.

Но как гарантировать качество?

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

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

4-уровневая система обеспечения качества

Quality Management (QM) или управление качеством — это процесс наблюдения за всеми действиями и задачами, необходимыми для поддержания желаемого уровня качества. Управление качеством включает определение политики качества, создание и реализацию планирования и обеспечения качества (QA), а также контроль качества (QC) и улучшения качества. Управление качеством требует, чтобы все заинтересованные стороны бизнеса работали вместе надо улучшением процессов, продуктов, услуг и культуры самой компании.

Обеспечение качества (QA) — это часть управления качеством, направленная на обеспечении уверенности (гарантированности) в том, что требования к качеству будут выполнены.

Управление качеством (QC) — это рабочие методы и активности, нацеленные на выполнение требований к качеству.

Тестирование (Testing) включает в себя различные задачи и подходы к выявлению и обнаружению ошибок, дефектов в продукте.

Как видно между QA, QC и тестированием есть разница. Да, они об одном и том же — о качестве, но работают с ним с разных уровней.

QA

Так, QA задействован в процессе верификации и позволяет получить ответ на вопрос — Создаю ли я продукт правильно? У QA ориентация на процессы и их постоянное улучшение. Поэтому QA это проактивный процесс, направленный на предотвращение дефектов путем постепенного совершенствования производственных процессов, политик и процедур. QA отвечает за разработку стандартов и методологий, аудит, обучение и т.д.

QC

А вот QC задействован в процессе валидации и позволяет получить ответ на вопрос — Создаю ли я правильный продукт? В отличии от QA, QC ориентирован на продукт и является реактивным процессом, который направлен на эффективное выявление дефектов в программном обеспечении до релиза и отправки клиентам. QC следует стандартам и регламентам, методологиям, за которые отвечает QA.

Резюмируя, хочется отметить, чтобы обеспечить качество в ПО, надо начать с аудита производственных процессов, пересмотреть все регламенты и стандарты, которые используются и, если хочется повысить качество, начать их менять, внедрять новые методологии и подходы. Иначе, мы получим тот же самый результат. Как говорил Эйнштейн: Самая большая глупость — это делать тоже самое и надеяться на другой результат.

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

Наблюдения и рекомендации для успешных QA-команд

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

Независимость

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

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

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

Отношения внутри команды

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

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

Завлечение нужных людей

Еще один ингредиент для успешной деятельности QA-команд – качественная кадровая политика. Люди с опытом в области разработки жизненного цикла системы или программного обеспечения, будут хорошими кандидатами для роли в QA. Некоторые знания в рамках ISO и принципов CMMI дополнили бы знания того, кто уже имеет опыт в развитии процесса и неподдельный интерес к качеству.

Контрольные списки

Стандартные контрольные списки являются полезным механизмом для проведения аудита проектов, особенно если они разработаны в соответствии с фазами жизненного цикла разработки. Например, на этапе проектирования в перечень вопросов может быть снесено: «Есть ли прослеживаемость между дизайном и требованиями элементов?»

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

Связь и отчетность

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

Командам QA необходимо постоянно получать одобрение внесения изменений в процессы контроля качества и стандартов и обеспечивать эффективное взаимодействие с заинтересованными сторонами.

Постоянное совершенствование

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

Так, непрерывные усовершенствования могут также потребовать внесения изменений в методологии разработки системы, потому QA-командам рекомендуется сохранять методологию разработки ИТ-отдела.

Во сколько обходится нам некачественное ПО?

Часть 1: Подтверждение Дефекта

• Затраты времени Пользователя — 1 ед.
• Затраты времени Инженера СП — 1 ед.

«Работающий продукт важнее исчерпывающей документации»«То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева»

• Владельца Продукта — 1 ед.
• Инженер-Разработчик — 1 ед.
• Заказчик — 1 ед.
• Затраты времени Инженера СП — 1 ед.

• Ухудшение репутации — 1 ед. (за счёт того, что Дефект и что пришлось привлечь Заказчика к расследованию)
• Пока затраты на устранение дефекта здесь не учитываю, так как они добавятся чуть позже.

1. Затраты времени Пользователя — 1 ед.
2. Затраты времени Инженера СП — 2 ед.
3. Затраты времени Владельца Продукта — 1 ед.
4. Затраты времени Инженера-Разработчика — 1 ед.
5. Затраты времени Заказчика — 1 ед.
6. Ухудшение репутации — 1 ед.

Стоимость качества — 7 единиц

1. Затраты времени Пользователя — 1 ед.
2. Затраты времени Инженера СП — 1 ед.
3. Затраты времени Тех.Писателя-Аналитика — 1 ед.
4. Ухудшение репутации — 0,5 ед. (Потому что Дефект)

Стоимость качества — 3,5 единицы

Часть №2: Устранение Дефектов

• Инженер-Разработчик — 1 ед.
• Инженер-Тестировщик — 1 ед.
• Инженер СП — 1 ед.

• Инженер-Разработчик — 0,5 ед.
• Инженер-Тестировщик — 0,5 ед.

Стоимость качества — 4 единицы.

Часть №3: Недопущение Дефектов (Качество основанное на контроле)

1. Пользователя — 1 ед.
2. Инженера СП — 1 ед.
3. Ухудшение репутации — 0,5 ед.

1. Инженер-Разработчика — 1,5 ед.
2. Инженер-Тестировщика — 1,5 ед.
3. Инженер СП — 1 ед.

Стоимость — 6,5 ед. Вложения — 1 ед. Экономия — 5,5 единиц.

Часть №4: Устранение Ошибок

1. Ухудшение репутации — 1 ед.
2. Инженер-Разработчик — 1 ед.
3. Инженер-Тестировщик — 1 ед.
4. Потерянный доход — 2 ед. (п.2 + п.3)

Стоимость качества — 5 единиц.  

Часть №5: Недопущение Ошибок (Качество основанное на развитии производственного процесса)

• Затраты Руководителя-Разработки — 1 ед.
• Затраты Инженера-Разработчика — 1 ед.

1. Инженер-Разработчик — 1 ед.
2. Инженер-Тестировщик — 1 ед.
3. Потерянный доход — 2 ед.
4. Ухудшение репутации — 1 ед.

Стоимость — 5 ед. Вложения — 2 ед. Экономия — 3 единицы.

Вам это не понадобится (You Aren’t Gonna Need It, YAGNI)

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

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

Этот принцип экономит время, усилия и расходы, которые тратятся впустую на попытки понять или отладить код.

Ассоциации и организации

В Американское общество качества (ASQ) — это профессиональная организация, которая предоставляет своим членам сертификацию, обучение, публикации, конференции и другие услуги, связанные с управлением качеством, постоянным улучшением и безопасностью продукции.

В Международная квалификационная комиссия по тестированию программного обеспечения (ISTQBP — это некоммерческая международная ассоциация, зарегистрированная в Бельгии. Она управляет процессом сертификации тестировщиков программного обеспечения и имеет более 535 000 выпущенных сертификатов в более чем 120 странах.

Отличия между планированием испытаний и документацией в тестировании и QA:

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

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

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

Мониторинг плана обеспечения качества проекта в ходе создания проекта осуществляется беспрерывно и обновляет результаты планируемого качества деятельности в журнале.

Существуют различные точки пересечения между управлением рисками и качеством, и поэтому реестр рисков может сделать весомый взнос в подготовку планов по качеству.

Заключение

Определения не отлиты в граните, они меняются. То, что было справедливо в 1999 году, в 2022 может оказаться совершенно устаревшим. Одни стандарты сменяются другими, значения терминов изменяются со временем. Нам остаётся это только принять.

Пока готовил эту статью я понял один важный момент. Вести разговор о качестве в отрыве от требований неправильно. Только когда выдвинуты все требования следует запускать все механизмы по обеспечению качества. Выдвинутые требования – это гарантия осознания того, что необходимо сделать, и какие ресурсы нужно выделить. Иначе получить качественный продукт на выходе просто невозможно.