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

Обзор и мотивация

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

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

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

Ключевые принципы

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

Компромиссы: плюсы и минусы

Практика / выбор	Плюсы	Минусы
Формальная модель качества (ISO 25010)	Общий словарь; явные приоритеты	Накладные расходы при догматичном применении
Тяжёлое обеспечение качества (профилактика)	Меньше дефектов; ниже совокупная стоимость	Предварительные вложения; отдача проявляется медленнее
Тяжёлый контроль качества (проверка)	Ловит дефекты, всё же проскочившие	Дорого; находит дефекты поздно
Независимая V&V	Высокая гарантия; объективно	Дорого; медленнее; может ощущаться состязательной
Богатые метрики качества	Видимость; раннее предупреждение	Риск накруток; накладные расходы на измерение
Выделенная команда QA	Сосредоточенность и экспертиза	Может снимать ответственность с разработчиков
Качество во владении команд	Ответственность; быстрая обратная связь	Требует дисциплины и навыков повсеместно

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

Вопросы для обсуждения с командой

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

Взгляд по секторам

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

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

Крупная организация. Работа состоит в согласованности между многими командами: примите общую модель качества вроде ISO/IEC 25010, разделите обеспечение качества (процесс) и контроль качества (продукт) и проводите обзоры стоимости качества, сдвигающие затраты к профилактике. Держите качество во владении команд поставки, поддерживаемых небольшой центральной группой, сопровождающей стандарты и панели по доле ускользнувших дефектов, доле неудачных изменений и трендам здоровья кода. Стандартизируйте словарь и шлюзы, чтобы группы перестали изобретать практику качества заново, оставляя командам место достигать этих планок своим способом.

Государственный сектор. Закупки, прозрачность и публичная подотчётность задают рамку, поэтому вписывайте требования к качеству в контракты и требуйте документированных прослеживаемых свидетельств качества, а не утверждений. Ожидайте независимой верификации и валидации стороной, отдельной от разработчиков, обязательного соответствия доступности и записей о дефектах с серьёзностью и первопричиной в составе следа аудита. Сообщайте цифры стоимости плохого качества (переделки, обжалования, сбои сервисов) надзорным органам и давайте валидации реальную власть блокировать выпуск, который подведёт граждан, зависящих от него.

Примеры

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

Крупная организация. Крупная фирма финансовых услуг принимает ISO/IEC 25010 как словарь качества и для каждого продукта записывает целевые уровни надёжности, безопасности и сопровождаемости. Команды владеют качеством: ревью кода и автоматические тесты служат контролями в конвейере, а небольшая центральная группа ведёт QA, сопровождая стандарты и наставляя. Панель качества отслеживает долю ускользнувших дефектов, долю неудачных изменений и тренды здоровья кода. Дефекты классифицируются и разбираются по первопричинам, а повторяющиеся причины ведут к обновлению общих библиотек и контрольных списков. Руководство ежеквартально пересматривает данные о стоимости качества и сместило затраты к профилактике, сократив и инциденты в эксплуатации, и стоимость их исправления.

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

Бизнес-обоснование: мотивы, ROI и TCO

Отдача от качества это более низкая совокупная стоимость владения и устойчивая скорость поставки. У стоимости качества две стороны. Хорошие затраты, профилактика и оценка, видимы и управляемы: проектирование, стандарты, ревью, тестирование и инструменты. Стоимость плохого качества (COPQ) больше, но часто скрыта: внутренние переделки, инциденты в эксплуатации, аварийные исправления, поддержка клиентов, потерянные пользователи, регуляторные штрафы и репутационный ущерб. Исследования, восходящие к «Quality Is Free» Кросби, последовательно находили, что совокупная стоимость плохого качества затмевает стоимость его предотвращения и что дефекты дорожают тем сильнее, чем позже их ловят: проблема, найденная в проектировании, стоит долю той же проблемы, найденной в эксплуатации.

Для руководства аргумент не «тратьте больше на качество», а «тратьте раньше, чтобы тратить меньше в целом». Количественно оцените COPQ по собственным данным (число и стоимость инцидентов, часы переделок, доля ускользнувших дефектов) и покажите, как профилактика и ранняя оценка её снижают. Свяжите качество с бизнес-результатами: надёжность удерживает клиентов, сопровождаемость делает будущие изменения дешёвыми, а безопасность и доступность удерживают вас от юридических проблем. В долгоживущих корпоративных и государственных системах, где большая часть стоимости приходится на период после первого выпуска, измерения качества «сопровождаемость» и «надёжность» доминируют в стоимости жизненного цикла. Это делает ранние вложения в качество одним из самых рычажных решений, которые вы можете принять.

Антипаттерны и ловушки

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

Модель зрелости

Уровень 1 (Начальный). Качество не определено и стихийно. Оно держится на личном усердии, проверяется в основном ручным тестированием в конце, а дефекты обрабатываются реактивно по мере проявления. Нет ни общей модели, ни метрик, ни границы между обеспечением и контролем.

Уровень 2 (Развитие). Появляются базовые практики: ревью кода, автоматизированные тесты и трекер дефектов. Некоторые данные о качестве собираются, но неравномерно, и каждая команда делает это по-своему. Качество по-прежнему в основном воспринимается как тестирование, профилактики минимум, верификация происходит, а валидация неформальна.

Уровень 3 (Стандартизация). Организация принимает общую модель качества (например, ISO/IEC 25010), разделяет QA и QC и ведёт процессы управления качеством с планами качества и критериями приёмки, задокументированные и последовательно применяемые по командам. Верификация и валидация различны и намеренны, а дефекты классифицируются и разбираются по первопричинам по согласованной схеме.

Уровень 4 (Управление). Качество измеряется и контролируется относительно базовых значений. Небольшой набор содержательных метрик отслеживается во времени (плотность дефектов, доля ускользнувших дефектов, среднее время обнаружения и устранения, доля неудачных изменений и сигналы здоровья кода вроде сложности и дублирования), а стоимость качества количественно оценивается по профилактике, оценке и отказам. Шлюзы приёмки и качества обеспечиваются по свидетельствам, а не мнению, тренды пересматриваются с фиксированной периодичностью, а валидация может по-настоящему блокировать выпуск.

Уровень 5 (Оркестрация). Качество непрерывно улучшаемая, культурно принадлежащая дисциплина, интегрированная с бизнес-планированием и планированием рисков. Упор на профилактике, данные о стоимости качества направляют, куда идут вложения, а выводы по первопричинам системно предотвращают повторение. Команды владеют качеством от начала до конца, метрики питают непрерывное улучшение, а организация адаптирует практику качества по мере смещения продуктов, рисков и регулирования. Это соответствует высшим уровням моделей зрелости из главы 10.8.

Идеи для обсуждения

Какие характеристики качества ISO/IEC 25010 важнее всего для ваших систем и что значит «достаточно хорошо» для каждой?
Где ваша организация находится в смеси затрат на профилактику, оценку и отказы и должна ли она сместиться?
Различаете ли вы верификацию и валидацию на практике или сворачиваете оба в «тестирование»?
Принадлежит ли качество командам, создающим программы, или делегировано отдельной группе и что изменилось бы при переносе?
Какова ваша истинная стоимость плохого качества и можно ли измерить её достаточно хорошо для бизнес-обоснования?
Какие из ваших метрик качества подлинные сигналы, а какие стали накручиваемыми целями?

Главные выводы

Качество шире тестирования: это пригодность для цели плюс соответствие, по характеристикам вроде надёжности, безопасности и сопровождаемости.
Используйте общую модель качества (ISO/IEC 25010), чтобы атрибуты качества были явными и согласованными с архитектурой (глава 3.1).
Разделяйте обеспечение качества (предотвращать, процесс) и контроль качества (обнаруживать, продукт) и склоняйтесь к профилактике.
Практикуйте верификацию (построено правильно) и валидацию (построено то, что нужно) как различные дисциплины.
Измеряйте качество несколькими содержательными метриками и характеризуйте дефекты по серьёзности и первопричине, чтобы предотвращать повторение.
Управляйте стоимостью качества: профилактика и ранняя оценка гораздо дешевле отказов, особенно в долгоживущих системах.
Стройте культуру качества без поиска виноватых, где командами владеют качеством, поддерживаемым ревью кода (глава 2.5) и стратегией тестирования (глава 2.4).

Источники и дополнительное чтение

IEEE Computer Society, SWEBOK Guide (Guide to the Software Engineering Body of Knowledge), Software Quality knowledge area.
ISO/IEC 25010, Systems and software engineering: Systems and software Quality Requirements and Evaluation (SQuaRE): System and software quality models.
ISO/IEC 25000 series (SQuaRE), Software product quality requirements and evaluation.
Philip B. Crosby, Quality Is Free: The Art of Making Quality Certain.
W. Edwards Deming, Out of the Crisis.
Capers Jones and Olivier Bonsignour, The Economics of Software Quality.
Gerald Weinberg, Quality Software Management.
ISO/IEC/IEEE 12207, Systems and software engineering: Software life cycle processes (quality assurance and V&V process context).

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

Обзор и мотивация

Ключевые принципы

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

Примите общую модель качества вроде ISO/IEC 25010

Разделяйте обеспечение качества и контроль качества

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

Практикуйте верификацию и валидацию как различные дисциплины

Измеряйте качество содержательными метриками

Характеризуйте дефекты и управляйте ими систематически

Управляйте стоимостью качества намеренно

Стройте культуру качества