На ком лежит ответственность за качество программного обеспечения?
Соучредитель Agile Testing Fellowship Джанет Грегори завершила свой основной доклад о процессе обеспечения качества программного обеспечения, попросив собравшихся поднять руки, если они чувствуют момент волшебства в своей agile-команде и чувствуют, что несут миру качество. Лишь несколько человек из аудитории, предположительно полностью состоящей из практикующих agile разработчиков, подняли руки.
Как так получилось, что с момента подписания Agile-манифеста прошло 17 лет (на момент доклада), а все еще так мало людей вышли за рамки созерцания теней на стене пещеры? Быть может, у нас все еще нет правильного диалога. Быть может, мы все еще не ведем его с правильными людьми. Или, может быть, диалог вообще не являются частью наших процессов.
Но что такое «качество»?
Грегори отмечала, что субъективное определение качества зачастую должно быть определено заранее. Чтобы с чего-то начать определение качества, она предложила «Пять подходов к определению качества» Дэвида А. Гарвина 1984 года:
Грегори визуализировала насущность каждой категории следующим образом, где самые насущные находятся ближе к центру, и применила это к современной agile-среде.
Подход на основе производства
Во-первых, все должно работать, поэтому производственное качество лежит в основе.
Грегори утверждает, что оно предполагает проектирование через тестирование, потому что «написание чистого кода значительно сокращает количество доработок. Давайте делать правильно с первого раза, чтобы не плодить баги. Тогда мы сможем релизить с уверенностью».
TDD, практика разработки автоматизированных тестов до самого тестируемого программного обеспечения, что, в свою очередь, приводит к уменьшению связанности этого программного обеспечения, является важной частью производственного качества. Грегори процитировала исследование, в котором говорится, что команды, которые внедрили TDD, получают в итоге на 60-90 процентов меньше дефектов, чем те, кто его не практикует, но TDD отнимает в среднем на 15–30 процентов больше времени на разработку.
Многие команды сталкиваются с этим компромиссом между качеством и скоростью.
Помимо TDD, Грегори рассказала, что производственные процессы включают в себя:
Написание кода для обеспечения поддерживаемости
Мониторинг логов ошибок
Исследовательское тестирование по историям (stories)
Тестирование продукта на соответствие спецификациям
Автоматическое создание тестов для быстрой обратной связи
Статический анализ платформы
Четкое определение состояния ”Готово”
Наконец, она сказала: «Практики, такие как DevOps, стараются снизить риск клиента во время релиза их клиентам».
Подход на основе продукта
Грегори отмечает, что то, что определяется как продуктовое качество, зависит от целевой аудитории. Кому-то из бухгалтеров может быть очень нужна панель для клавиатуры, которую больше не делают в большинстве портативных компьютеров в настоящее время.
Вся суть заключается в двух вопросах:
Создаем ли мы то, что нужно?
Добавляем ли мы функционал, который нужен?
Устранение ошибок, например, командный хакатон с целью найти как можно больше багов
Исследовательское тестирование фич
Подход с точки зрения пользователя
Именно здесь точки зрения разнятся. Как сказала Грегори: «Разные люди выбирают разные вещи. У них разные желания, разные потребности. Если мы пытаемся предоставить покупателю право выбора, нам все-равно нужно удовлетворить его».
Но не забывайте, продолжила она, «мы также делаем предположение, что у потребителей достаточно информации, чтобы они могли принять квалифицированное решение».
Она рассказала о приложении, которое она когда-то использовала, которое она сочла очень недружелюбным. Оказалось, что пользователям оно нравилось, потому что он точно соответствовало их принципам работы. А она не работала в этой сфере. Все дело в удовлетворении конкретных вариантов использования конкретных пользователей.
Подход на основе ценности
Это просто то, за что люди готовы платить. Трудно судить о ценности, практически невозможно, не узнав мнение потенциальных клиентов.
Качество с точки зрения ценности, оценивается с помощью некоторой комбинации следующих факторов:
Трансцендентное качество
Как мы измеряем качество программного обеспечения?
В целом, если вы согласны со шкалой качества Гарвина, значительную долю качества программного обеспечения измерить трудно. Она процитировала Изабель Эванс относительно оценки качества программного обеспечения. Существует множество примеров производственного качества:
Количество ошибок в продакшене
Серьезность ошибок в продакшене
Количество дней с момента последнего запуска в продакшн
Количество новых обращений в службу поддержки за X дней с момента последнего релиза
Индикатор сборки остается зеленым
Нет непройденных автоматизированных тестов (случайных сбоев)
Статический анализ кода кодовой базы не выявляет проблем
Количество исправлений на низком уровне
Одни и те же баги не всплывают повторно
Также можно существует мера качества с точки зрения пользователя в форме опросов удовлетворенности пользователей.
И конечно, командам необходимо соблюдать баланс между желанием избегать ошибок и скоростью разработки.
Вся команда несет ответственность за качество
Вся команда владеет качеством
Но она не раскрыла никакого секретного рецепта идеального стремления к качеству.
Она процитировала соавтора BDD Book 1: Discovery Себа Роуза: «Когда мера становится целью, она перестает быть хорошей мерой».
Она продолжила: «У команды есть качество, но нужно думать шире. Качество в процессах и качество в практике. Компетентность в вашей команде, компетентность в том, как вы доставляете программное обеспечение».
В конце она сказала, что любой диалог в этом направлении лучше всего начинать с людей, пытающихся решить проблему.
Стоимость качества в разработке программного обеспечения
Ниже результаты моих теоретических и практических исследований в поисках ответов. Постарался изложить их просто, без «мозговзрыва» присущего этой теме.
Что такое качество в разработке ПО?
На вопрос что такое качество в разработке ПО можно ответить с разных точек зрения. Свои ответы буду формулировать с точки зрения Пользователя-Заказчика и Руководителя компании. 
С позиции Пользователя высокое качество ПО — это полное отсутствие ошибок и решение им задачи ради которого оно создавалось.
Минимальный уровень качества — это решение бизнес-задачи и отсутствие в ПО ошибок, которые блокируют возможность его использования (Блокирующие ошибки).
Средний уровень качества — всё что выше + отсутствие ошибок, которые существенно влияют на опыт использования ПО (Обязательные к устранению), при этом присутствуют ошибки, которые никак не влияют на решение бизнес-задачи: орфография, разные шрифты там где должен быть один и т.д. (Желательные к устранению).
Ошибки, которые найдены пользователями в ходе эксплуатации буду называть Дефектами. Ошибками же будут считать то, что было найдено сотрудниками, вовлеченными в выпуск версии ПО, до передачи его в эксплуатацию Пользователям.
Во сколько обходится нам некачественное ПО?
Часть 1: Подтверждение Дефекта
Здесь инженеру СП потребуется документация, которая описывает каким должен быть эталонный ответ системы при выполнении ею конкретного запроса пользователя. Если этой документации нет, то требуются дополнительные затраты на выяснение дефект ли это или же новое требование.
Отсутствие документации особенно часто встречается когда практикуется быстрая разработка. Все помнят о «Работающий продукт важнее исчерпывающей документации», но забывают про то что ниже написано «То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева».
Инженер СП начинает прикладывать дополнительные усилия на то, чтобы выяснить правду. К расследованию подключаются Владелец Продукта (если он есть) или Инженер-Разработчик, который делал эту функцию или знает этот функциональный модуль. Один из них или оба пытаются вспомнить или определить Заказчика, для которого это сделано.
Пользователь системы не всегда является тем Заказчиком, который формулировал требование к работе системы. То что для Пользователя ненормально для Заказчика может быть нормой.
Вместе с Заказчиком они обсуждают ситуацию и пытаются определить штатно или нештатно отработала система. Если у Заказчика амнезия, а такое бывает, если работу заказал месяца 3 назад (длинный бэклог с работой на полгода вперед), а сделали эту фичу/функцию только сейчас, они пытаются найти какой-то документ или письмо, на основании которого делалась разработка.
Чтобы понять момент, когда Тех.Писатель-Аналитик нужен, нужно начать вести учёт ситуаций, когда для расследования привлекались дополнительные лица помимо Инженера СП и сколько времени они на это потратили, сколько таких спорных ситуаций превратилось в Дефекты и во сколько обошлось их устранение. Когда сумма этих затрат становится больше зарплаты Тех.Писателя самое время его вводить.
Часть №2: Устранение Дефектов
Часть №3: Недопущение Дефектов (Качество основанное на контроле)
Чтобы Пользователи не находили Дефекты для этого есть собственные Инженеры по тестированию. Для них критерий эффективности 100% ошибок — 0% дефектов.
Часть №4: Устранение Ошибок
Каждая найденная самостоятельно ошибка, не стоит компании ничего, так как затраты на устранение попадают в конечную стоимость для Клиента.
Но устранение ошибок увеличивает себестоимость продукта и сроки выполнения работ, если Разработка делает много и тяжелых ошибок, а также приходится выполнять более 2-х итераций тестирования и устранения ошибок. Всё это не нравится Клиенту и, особенно, если ему есть с чем сравнивать.
Если разработка ведётся для собственных нужд, то большое количество ошибок ухудшает экономику возврата вложений в Разработку и сужает возможность выпуска большего количества полезных функций (фич) в единицу времени, что сказывается уже негативным образом на экономике всего бизнеса компании.
Часть №5: Недопущение Ошибок (Качество основанное на развитии производственного процесса)
Качество продукта нужно не только и не столько контролировать, сколько предотвращать причины, которые на прямую влияют на появление ошибок.
Общий расчёт стоимости качества
Обычно ситуация выглядит так: Мы ведем разработку, допускаем ошибки, порой их устранение требует более двух итераций и несмотря на эту работу Пользователи всё равно находят дефекты в ПО, которые нам приходится исправлять путем выпуска дополнительных обновлений.
| Вид затрат | Часть 1 | Часть 2 | Часть 4 | Итого |
|---|---|---|---|---|
| Затраты времени Пользователя | 1 | — | — | 1 |
| Затраты времени Инженера СП | 2 | 1 | — | 3 |
| Затраты времени Владельца Продукта | 1 | — | — | 1 |
| Затраты времени Инженера-Разработчика | 1 | 1,5 | 1 | 3,5 |
| Затраты времени Заказчика | 1 | — | — | 1 |
| Затраты времени Инженера-Тестировщика | — | 1,5 | 1 | 2,5 |
| Ухудшение репутации | 1 | — | 1 | 2 |
| Потерянный доход | — | — | 2 | 2 |
| Итого | 7 | 4 | 5 | 16 |
Если будем готовить документацию по факту выполненной разработки, вложив 1 единицу ресурса Технического Писателя, то это сэкономит 3,5 единицы и стоимость качества снизится с 16 до 12,5. (Структура затрат: Документирование + Подтверждение Дефекта + Устранение Дефекта + Устранение Ошибок)
Обеспечив недопущение дефектов, вложив в это дополнительные затраты времени Инженера-Тестировщика в размере 1 единицы, стоимость качества снизится с 12,5 до 7 единиц. (Структура затрат: Документирование + Недопущение Дефектов + Устранение Ошибок)
Недопущение ошибок потребует вложения 2 единиц, по одной от Инженера-Разработчика и Руководителя-Разработки, и снизит стоимость качества с 7 до 4 единиц. (Структура затрат: Документирование + Недопущение Дефектов + Недопущение ошибок)
Кто отвечает за качество?
В западных компаниях есть такая позиция Quality Assurance Engineer, который отвечает за весь процесс выпуска программного обеспечения и фокусируется на аспекте обеспечения качества.
У нас Software Quality Assurance (Обеспечение качества ПО) утрировано до восприятия как Тестирование, а Quality Assurance Engineer до Инженер-Тестировщик. Но Инженер-Тестировщик максимум что может сделать это найти все ошибки и вернуть их Software Engineer (Инженеру-Разработчику), но он никак не влияет на их появление.
Ребята в разработке могут не допускать ошибок, но они не роботы, это творческий процесс когда нужно придумать то, чего не было раньше и негде подсмотреть как это можно сделать.
Это также порой осложняется тем, что в качестве входной информации к ним приходит невнятная постановка, причина которой лежит либо в том, что Заказчик не понимает чего хочет и кто-то пропустил это требование до Разработки, либо Заказчик знает чего хочет, но сработал «сломанный телефон» и до Разработки часть требований не дошла.
Team Lead (Руководитель Разработки) может помочь Инженеру-Разработчику научится делать свою работу хорошо и освоить недостающие компетенции и технологии, но он точно не должен быть Внутренним Тестировщиком команды разработки и проверять за каждым, чтобы не пропустить на следующий этап дефектный код. Его задача учить и строить процессы внутри команды, чтобы дефектного кода не было.
Есть ещё Product Owner (Владелец Продукта), который как владелец подходит на роль Отвечающего за Качество Продукта. По этой причине их порой делят на две позиции Marketing Product Manager (Менеджер по продукту) и Software Delivery Manager (Менеджер по выпуску ПО). Первый отвечает за развитие продукта с точки зрения рынка (работа с Заказчиками и требованиями), а второй за развитие производственного процесса выпуска продукта.
Если пристально присмотреться ко всем в списке, то видно что никто из них персонально не производит «Качество». Качество это не компонент программы, который к нему можно добавить. При этом все они участвуют в создании Продукта, который решает бизнес-задачу пользователя и не содержит ошибок. Качество — это командная работа.
Поделить ответственность по этапам Software Development Life Cycle (Жизненного цикла разработки ПО) не получается. Как только это деление начинается, неэффективная работа по середине сразу делает бессмысленной работу сделанную в начале и нагружает дополнительной работой как тех кто стоит в конце, так и всю производственную цепочку заводя на её вход ошибку для устранения.
Заключение
Он отлично подходит для разработки продуктов работу которых можно спроектировать от и до. И не подходит когда времени проектировать работу продукта нет и определение как он должен работать происходит через итеративный выпуск работающих версий (эмпирически).
В начале быстрой итеративной разработки есть единственный критерий качества — это выполнение продуктом бизнес-задачи ради которой он создается. С каждой итерацией Заказчик добавляет новые критерии качества (ожидания от продукта), которые улучшают его опыт использования продукта для решения бизнес-задачи.
С применением быстрых фреймворков Agile, количество ошибок и дефектов в единицу времени увеличивается пропорционально количеству релизов. Чем больше делаем и выпускаем, тем больше ошибок производим. Чем больше ошибок производим, тем больший процент загрузки команды связан с исправлением допущенных ошибок и переделке сделанного.
Это плата за то, что самолет достраиваем уже в полете, не имея представления о том, как он должен выглядеть в законченном виде и реагировать на условия внешней среды.
Что с этим делать? — мне нравятся ответы данные в статье «Будущее гибкой разработки».
Что ещё почитать по теме:
Уделите пару минут ответу на три вопроса, так вы поможете провести диагностику средней температуры отношения и внимания к качеству ПО в ИТ-отрасли нашей страны на 1 августа 2017 года. +1 вам в карму за это доброе дело.
Качество ПО и методы его контроля
Качество программного обеспечения
Как проверить, что требования определены достаточно полно и описывают все, что ожидается от будущей программной системы? Это можно сделать, проследив, все ли необходимые аспекты качества ПО отражены в них. Именно понятие качественного ПО соответствует представлению о том, что программа достаточно успешно справляется со всеми возложенными на нее задачами и не приносит проблем ни конечным пользователям, ни их начальству, ни службе поддержки, ни специалистам по продажам. Да и самим разработчикам создание качественной программы приносит гораздо больше удовольствия.
Качество программного обеспечения определяется в стандарте ISO 9126 [1] как вся совокупность его характеристик, относящихся к возможности удовлетворять высказанные или подразумеваемые потребности всех заинтересованных лиц.
Тот же стандарт ISO 9126 [1,2,3,4] дает следующее представление качества.
Системы управления качеством — Основы и словарь. (Аналог — ГОСТ Р-2001).
Системы управления качеством — Требования. Модели для обеспечения качества при проектировании, разработке, коммерциализации, установке и обслуживании.
Определяет общие правила обеспечения качества результатов во всех процессах жизненного цикла. (Аналог — ГОСТ Р-2001).
Системы управления качеством. Руководство по улучшению деятельности. (Аналог — ГОСТ Р-2001).
Руководящие положения по применению стандарта ISO 9001 при разработке, поставке и обслуживании программного обеспечения.
Обеспечение качества программного обеспечения
Программное обеспечение должно выполнять свои функции, соответствовать заданным критериям качества, безопасности, надежности. Оценка продукта, требований к нему, проектной документации – задача инженеров по обеспечению качества, или QA-инженеров.
Обеспечение качества ПО включает в себя мероприятия, которые проводят на каждой стадии его разработки. Цель – предоставить гарантию того, что продукт соответствует функциональным и нефункциональным требованиям.
Понятие качества программного обеспечения
На первый взгляд, «качество ПО» может показаться абстрактным понятием. Однако для менеджеров проекта, программистов, специалистов по тестированию, QA-инженеров и других участников процесса разработки продукта критерии качества прозрачны и измеримы. Сначала рассмотрим общее определение.
Качество ПО – комплекс характеристик программного продукта, определяющих способность выполнять возложенные на него функции.
В настоящий момент этот показатель регулируется международным стандартом ISO/IEC 25010:2011. Данный стандарт устанавливает многоуровневую систему оценки качества ПО, основанную на восьми базовых характеристиках.
Параметры качества ПО
Основные характеристики качества программного обеспечения согласно стандарту ISO/IEC 25010:2011:
Обеспечение качества и тестирование
Термины «тестирование» и «обеспечение качества», безусловно, связаны между собой, но не тождественны. В чем же различие?
Обеспечение качества отвечает за весь процесс разработки и интегрируется во все его этапы: от создания требований к будущему решению до тестирования, релиза продукта и его пострелизного обслуживания.
В задачи QA-специалистов входит:
Тестирование – проверка программного обеспечения на соответствие требованиям.
Таким образом, вы видите, что обеспечение качества – более широкое понятие, которое включает в себя работы по тестированию.
Тестирование может быть автоматизированным, а может проводиться вручную; может быть полного цикла или направленным на проверку отдельного аспекта качества (безопасность, производительность, удобства использования и т.д.).
Инженеры по тестированию подготавливают стратегии по тестированию и план, основанный на особенностях проекта и требованиям к решению, создают и в будущем оптимизируют набор тест-кейсов, осуществляют поиск дефектов, создают и направляют отчеты об обнаруженных дефектах разработчикам, проверяют устранение дефекта.
Функция обеспечения качества может выполняться внутренним отделом компании, а может делегироваться независимому подрядчику, который объективно оценит само решение, настроит процессы обеспечения качества и тем самым позволит выпустить на рынок продукт высокого качества, отвечающий бизнес-требованиям и ожиданиям пользователей.
Что такое качество программного обеспечения
Что пишут в блогах
Продолжу хвастаться статусом книги.
I’m sticking with “bug” rather than adopt another word such as “fault,” which is the current fad in publications because:
Онлайн-тренинги
Что пишут в блогах (EN)
Разделы портала
Про инструменты
Автор: Евгений Марченко
Основной проблемой в управлении качеством является тот факт, что определение качества слишком неясное и неоднозначное. Это вызвано тем, что обычно термин качество понимается неправильно. Такая путаница может объясняться несколькими причинами.
Попробуем ответить на вопросы:
Что такое качество программного обеспечения?
В нашем первом выпуске мы попытаемся дать определение терминами качество и качество программного обеспечения.
Основной проблемой в управлении качеством является тот факт, что определение качества слишком неясное и неоднозначное. Это вызвано тем, что обычно термин качество понимается неправильно. Такая путаница может объясняться несколькими причинами.
Первая, качество это не отдельно взятая идея или понятие, скорее многомерная и разноплановая концепция.
Вторая, для любого понятия и определения существует несколько уровней абстракции, например, когда люди говорят о качестве, одна часть понимает под этим слишком широкий и размытый смысл, в то время как другая может ссылаться на конкретное определение и значение.
Третья, термин качество является неотъемлемой частью нашего повседневного общения, однако общепринятое и профессиональное использование может быть весьма сильно отличаться.
Популярный взгляд на качество
Общепринятое мнение о качестве таково, что это нечто нематериальное и «неосязаемое» — о нем могут вестись споры и дискуссии, его можно критиковать и восхвалять, но взвесить и измерить качество невозможно. Такие выражения как «хорошее качество» и «плохое качество» служат наглядным примером, как люди говорят о чем-нибудь неопределенном для них, то, что они не могут четко характеризовать и определить. Такое мнение отражает тот факт, что люди воспринимают и интерпретируют качество по-разному. Подразумевается, что качество не может быть контролируемым и управляемым, и тем более оно не может быть количественно измеримым. Такой взгляд ярко контрастирует с профессиональным подходом к управлению качеством — качество это четко определенная величина, которую можно измерить и проконтролировать, она поддается управлению и улучшению.
Другое популярное мнение, что качество неразрывно связанно с роскошью, первым сортом и тонким вкусом. Дорогой, досконально продуманный и более технически сложный продукт рассматривается как гарантия высочайшего качества, нежели более дешевые аналоги. Следуя такой логике Кадиллак — это качественная машина, а Шевроле нет, невзирая на надежность и количество поломок; или же HI-FI система это качественная система, а обыкновенное радио — нет. Согласно такому подходу, качество ограниченно определенным классом дорогостоящих продуктов с замысловатой функциональностью и классовым продуктам. Проще говоря, едва ли недорогой продукт будет классифицирован как качественный продукт.
Профессиональный подход к качеству
К сожалению, такое неопределенное и расплывчатое представление не может быть использовано для улучшения процессов разработки программного обеспечения. Следовательно, необходимо дать четкое и удобное для работы определение. В 1979 году Crosby определил качество как «соответствие требованиям» («conformance to requirements»), а Juran и Gryna в 1970 определили качество как «пригодность к использованию» («fitness for use»). Эти два определения тесно связанны и прекрасно согласуются, как мы увидим позже.
«Соответствие требованиям» предполагает, что требования должны быть настолько четко определены, что они не могут быть поняты и интерпретированы некорректно. Позже, на этапе разработки, производятся регулярные измерения разработанного продукта, для определения соответствия требованиям. Любые несоответствия должны рассматриваются как дефекты – отсутствие качества. Например, спецификация на определенную модель радиостанции может требовать возможности принимать определенную частоту радиоволн на расстоянии более чем 30 километров от источника вещания. В случае, если радиостанция неспособна выполнить данное требование, она не удовлетворяет требования к качеству и должна быть признана негодной и некачественной. Исходя из тех же принципов, если Кадиллак соответствует всем требованиям к машинам Кадиллак, значит это качественная машина. Если Шевроле соответствует всем требованиям к машинам Шевроле, следовательно, это тоже качественная машина. Эти две машины могут быть совершенно разными по стилю, скорости и экономичности, но если обе измерять по стандартным для них наборам, тогда они обе будут являться качественными машинами.
Определение «Пригодность к использованию» принимает во внимание требования и ожидания конечных пользователей продукта, которые ожидают, что продукт или предоставляемый сервис будет удобным для их нужд. Однако разные пользователи могут использовать продукт по-разному, это означает, что продукт должен обладать максимально разнообразными вариантами использования. Согласно определению Juran каждый вариант использования это характеристика качества и все они могут быть классифицированы по категориям в качестве параметров пригодности к использованию.
Эти два определения качества («соответствие требованиям» и «пригодность к использованию») по существу одинаковы. Разница в том, что вариант «пригодность к использованию» указывает на важную роль требований и ожиданий заказчика. Роль заказчика, связанная с качеством, никогда не может быть переоценена. С точки зрения заказчика, качество продукта, который он приобрел, состоит из множества различных факторов, таких как: цена, производительность, надежность и т.д.
Только ваш заказчик может рассказать вам о качестве, потому что это единственное что он действительно покупает. Заказчик не покупает продукт. Он покупает ваши гарантии того, что все его ожидания к продукту будут реализованы.
Guaspari ”I Know It When I See It”
Выводы
Давайте еще раз попытаемся дать определение качеству с точки зрения заказчика или пользователя продукта.
Качество — это пригодность к использованию. Делает ли данный продукт то, в чем я нуждаюсь, облегчает ли он мою работу, могу ли я его использовать так, как мне удобно.
А теперь посмотрим на точку зрения разработчика.
Качество — это соответствие специфицированным и собранным требованиям делает ли данный продукт все то, что указано в требованиях.
Проблема в том, что специфицированные и собранные требования это обычно лишь часть всех реальных требований и ожиданий заказчика. Где же правильное определение качества?
Качество это соответствие реальным требованиям, явным и неявным. Очень часто неявные требования настолько очевидны для заказчика или пользователя, что он даже не предполагает, что они неизвестны разработчикам. Для примера вернемся к нашим автомобилям — заказчик может детально описать требования к дизайну, параметрам двигателя, оформлению салона, цвету кузова, но нигде не указать, что шины должны быть круглыми, а лобовое стекло — прозрачным.
Заказчик будет удовлетворен только тогда, когда купленный продукт будет полностью удовлетворять его реальным и жизненным требованиям, как специфицированным, так и нет.