Сообщений в теме: 67

[barancev]

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

Вопрос стоит следующим образом: что означают термины Verification & Validation, как оин соотносятся с тестированием, и как их адекватно переводить на русский язык.

Позиция Анатолия Милнера:

"верификация" – это упреждающая оценка, в отличие от validation суть "технический контроль"- подтверждающая оценка

Моё мнение (основанное на "Software Design, Automated Testing, and Maintenance: A Practical Approach" by Daniel Hoffman, Paul Strooper):

Verification determines whether a system meets its requirements specification. Validation determines whether the requirements specification adequately captures the user's needs.

Для ознакомления с началом обсуждения настоятельно рекомендуется прочитать дискуссию Русскоязычная терминология: калька или традиции?

[barancev]

Сначала я приведу свой вариант перевода, который я уже упоминал ранее:
Verification -- верификация, Validation -- валидация.

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

Поскольку (в предыдущей дискусии) я привёл несколько цитат из разных источников, дающих определение терминам Verification & Validation, а для продолжения дискуссии здесь я выбрал только одную из них, скажу, что именно это определение мне кажется наиболее удачным и отражающим мою точку зрения наиболее точно.

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

Задача ставится следущим образом: разработать Систему, удовлетворяющую ожиданиям Пользователя.

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

Пользователь --> Требования --> Система

Итак, задача сводится к двум подзадачам и одному предположению.
Подзадача 1: разработать Требования, отражающие ожидания Пользователя.
Подзадача 2: разработать Систему, реализующую Требования.
Предположение: композиция этих двух задач составляет исходную задачу:

Система реализует Требования /\ Требования отражают ожидания Пользователя => Система удовлетворяет ожиданиям Пользователя

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

Возвращаемся к нашим баранам-терминам. Как они соотносятся с данной схемой? Очень просто:
Верификация -- проверка правильности решения Подзадачи 1
Валидация -- проверка правильности решения Подзадачи 2.

То есть, простыми словами (что почти достовно совпадает с переводом приведённого выше определения на английском языке):
Верификация -- проверка того, что мы собираемся делать именно то, что ожидает получить пользователь.
Валидация -- проверка того, что мы сделали именно то, что собирались сделать.

[Spy]

А я пришёл весь такой безопасный и вставил свои пять копеек. :P

Источник: NATIONAL INFORMATION SYSTEMS SECURITY (INFOSEC) GLOSSARY, http://nist.gov

verification - Process of comparing two levels of an IS specification for proper correspondence (e.g., security policy model with top-level specification, top-level specification with source code, or source code with object code).

Перевод из словаря Лукацкого А.:
Верификация - Процесс сопоставления двух уровней спецификаций системы (модели политики безопасности и спецификаций системы , спецификаций системы и исходных кодов, исходных кодов и выполняемых кодов ) для установления необходимого соответствия между ними.
------------------------------------------------------

validation - Process of applying specialized security test and evaluation procedures, tools, and equipment needed to establish acceptance for joint usage of an IS by one or more departments or agencies and their contractors.

Мой перевод:
валидация - процесс одобрения специализированного теста безопасности, процедур оценки, иструментов и оборудования, необходимого для установления соответствия для совместного использования ИС одним или более учереждением или агенством и их клиентами.



По-моему очень похоже на версии, предложенные Алексем выше.

[barancev]

validation - Process of applying specialized security test and evaluation procedures, tools, and equipment needed to establish acceptance for joint usage of an IS by one or more departments or agencies and their contractors.

Мой перевод:
валидация - процесс  одобрения специализированного теста безопасности, процедур оценки, иструментов и оборудования, необходимого для установления соответствия для совместного использования ИС одним или более учереждением или агенством и их клиентами.

Сначала приведу мой вариант перевода, потому что предложенный меня не очень устраивает.

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

По-моему очень похоже на версии, предложенные Алексем выше.

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

Да, иногда термин верификация используется для обозначения способов формального, математически строгого доказательства правильности, в то время как валидация означает все остальные способы проверки. Такая трактовка, например, широко распространена среди тестировщиков аппаратного обеспечения, в частности интегральных схем (ASIC, SOC).

Однако, в литературе, посвящённой разработке ПО, я такого подхода ни разу не встречал. Возможно, тестировщики безопасности позаимствовали свою терминологию у аппаратчиков, а не у программистов?

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

[Viktor]

О валидации
В переводе уже упомянутой книги Rapid Testing термин Validation рассматривается как "аттестация", а аттестация это есть "определение качества продукции" (по www.km.ru) , о чем, кстати, далее в книге и говорится
И, на мой взгляд, это правильно, так как этот термин не подразумевает только техническую оценку, или технические действия по оценке.

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

Подытожу, если непонятно :), в двух этих терминах я согласен с переводом книги "Rapid Testing" (Зав. ред. С.Н. Тригуб)

[Viktor]

Я боюсь, что мы (я) не сможем (смогу) бороться с таким источником компетенции как ГОССТАНДАРТ России (правда, некоторые смогут :))
А он четко определил:
verification - верификация
validation - аттестация
хотя их определения вам (мне) не понравятся :)

[barancev]

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

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

Мне понравилось. Очень близко к той версии, которую я изложил. Отличия от предложенной Вами я покажу, как и обещал, чуть позже.

[Viktor]

Если я правильно понял уважаемого Victor, то единственное противоречие между моей позицией и позицией Госстандарта России, это перевод термина Validation.

Я их приведу, а то вдруг у меня устаревший вариант (ГОСТ Р ИСО/МЭК 12207-1999)

аттестация (validation) - Подтверждение экспертизой и представлением объективных доказательств того, что конкретные требования к конкретным объектам полностью реализованы

Что-то очень похожее на технический контроль

Косвенно с этим соглашается и Victor

Да

верификация (verification) - Подтверждение экспертизой и представлением объективных доказательств того, что конкретные требования полностью реализованы

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

А готовы ли Вы (Госстандарт) согласится с тем, что технический контроль- это частный случай аттестации/сертификации? Другими слова, аттестация - это технический контроль с последующим(в случае удачного его завершения) оформлением соответствующего документа- Сертификата?

ГОСТ на Вашей стороне, Анатолий, за исключением перевода :), и он не требует сертификата

PS. Международная организация по стандартизации (ИСО) запросто добавила в русский язык слово "валидация",например, ИСО 9001:2000. Узнать бы кто это так перевел, ... И как после этого верить людям?

[Green]

Хочу предложить графическое представление проблемы.

Если рассматривать кодирование программы как черный ящик, то
ВЕРИФИКАЦИЯ - это контроль (тестирование) данных на ВХОДЕ черного ящика.

Соответственно,
ВАЛИДАЦИЯ - контроль (тестирование) данных на ВЫХОДЕ.

[barancev]

Хочу предложить графическое представление проблемы.

Если рассматривать кодирование программы как черный ящик, то
ВЕРИФИКАЦИЯ - это контроль (тестирование) данных на ВХОДЕ черного ящика.

Соответственно,
ВАЛИДАЦИЯ - контроль (тестирование) данных на ВЫХОДЕ.

Отлично! Рассматриваются именно вход и выход, а не "промежуточные результаты". Собственно, про это я и собирался написать, но вряд ли мне удалось бы выразить это столь кратко и ясно. Спасибо!

[barancev]

Главное для меня, в данном случае, суть, а здесь пока вся ясно:
Verification- это проверка предварительных результатов,
Validation- это проверка окончательных результатов.

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

Речь идёт не о любых промежуточных результатах, а именно о требованиях (то есть входных данных для разработки) и о готовой системе (то есть выходных данных разработки). К первым применяется верификация, а ко вторым -- валидация. И в процессе Dotted-U model, на который Вы ссылаетесь, это тоже так (за исключением так называемого code verification, который я не понял, что означает).

Как я уже упоминал, понятия V&V не специфичны для IT-отрасли, они применяются и в других отраслях промышленности.

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

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

А для Алексея и его сторонников, если они есть, маленькая практическая задачка. Пожалуйста, найдите или составьте сами кратенькую методичку для рядового SQA инженера на тему «Верификация  Требований(т.е. Технического задания на разработку программы) на предмет их соответствия ожиданиям пользователя» и не забудьте при этом подсказать ему, где(в каком документе?) он должен найти эти самые «ожидания».Что то очень получается похоже на известную сказку, герой которой идёт «туда, не знаю куда» и ищет «то, не знаю что» :rolleyes: .

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

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

Однако, на деле всё оказывается не так просто, потому что ожидания -- они не в документе, а в живых людях, которые, по Вашему слову, хотят "то, не знаю что". И даже если знают, чего они хотят, иногда их показания противорчивы, или неполны, или не имеют связи с объективной реальностью :) Интересы различных заинтересованных сторон не всегда совпадают.

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

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

И, кстати, что такое при Вашем подходе верификационное тестирование, если Вы согласны с тем, что тестирование- это динамическая проверка/оценка исполняемой программы?

Честно говоря, я не знаю, что это такое -- "верификационное тестирование". :) А что это значит?

[Green]

неожиданно для меня Сергей(Green) предложил «чёрный ящик» в качестве модели процесса проектирования программ. Неожиданно, потому что эта модель явно не адекватно отражает практику программирования...

Попробую объяснить свою модель.
Я рассуждаю с позиции тестировщика и именно с точки зрения его обязанностей оцениваю V&V. По этому речь не идет о проектировании программ. (Это отдельный процесс, который, кстати, тоже укладывается в модель "черного ящика".)

То, что требования должны тестироваться на "входе" и результат на "выходе" - споров не вызывает. С этим согласны все.

Камень преткновения - промежуточные результаты.

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

По операциям видно что тестировщик не может получить доступ к продукту до того как он будет создан, а тестировать требования после их поступления разработчику смысла не имеет. Именно разработчика я и рассматриваю в качестве "черного ящика".
:P

Каких-то дополнительных ОБЪЕКТОВ проверки в "промежутке" я не вижу.
Сам список тестируемых задач можно расширить, но все эти задачи будут относиться к проверке или требований, или результатов (функциональное тестирование, нагрузочное тестирование, ревью кода и пр.). Тот же самый подход применяется и при итерационном выпуске ПО.

Если же говорить о контроле процессов компании, то это уже не тестирование, а обеспечение качества - QA (что далеко не тоже самое). QА стоит над всеми процессами и "мониторит" условия выпуска ПО. Вот QA может и должно влазить в любой черный ящик и делать свое белое дело. (Белое - потому что задача QA сделать все черные процессы прозрачными и управляемыми). Но это уже тема совсем другой дискуссии.

B)

[barancev]

- неожиданно для меня Сергей(Green) предложил «чёрный ящик» в качестве модели процесса проектирования программ. Неожиданно, потому что эта модель явно не адекватно отражает практику программирования, а Сергей, работая, насколько я понял, в американском офшоре, не может быть чистым теоретиком, по определению. Именно, с этой модели и начнём:

Хочу предложить графическое представление проблемы.

Если рассматривать кодирование программы как черный ящик, то
ВЕРИФИКАЦИЯ - это контроль (тестирование) данных на ВХОДЕ черного ящика.

Соответственно,
ВАЛИДАЦИЯ - контроль (тестирование) данных на ВЫХОДЕ.

Отлично! Рассматриваются именно вход и выход, а не "промежуточные результаты". Собственно, про это я и собирался написать, но вряд ли мне удалось бы выразить это столь кратко и ясно. Спасибо!

Отлично! И новый чёрный ящик появился. А почему, Сергей, не белый? А как насчёт проверок внутри этого самого ящика, т.е. проверок того, что испокон веков в инженерии любой отрасли назвалось внутренним/технологическим/пооперационным контролем?

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

А чем в методологическом плане процесс проектирования (опять таки, любого изделия) отличается от процесса его производства? Тем более, с точки зрения проверки/контроля/оценки(специально предлагаю варианты названия, чтобы опять не перевести дискуссия на чисто терминологические рельсы). Да, ничем не отличается! Те же проверка на входе(в нашем случае заимствованных решений), проверка на выходе(конечного результата проектирования), и, наконец, «пооперационная»/ технологическая проверка промежуточных результатов. Кстати, ещё раз просмотрите, например[1-3]. Везде, теми или иными словами говорится тоже самое. И быть по-другому не может. Или мы все считаем, что методология проектирования и изготовления программных изделий, чем- то отличается от методологий для других видов изделий? Ничем!

Вот разрабатывается некоторый программный продукт и есть тестировщик этого продукта. Давайте для начала взглянем на этот "ящик разработки" так, как видит его тестировщик. Он его видит ЧЁРНЫМ, как справедливо отметил Сергей. Потому что он не может получить доступ к промежуточным данным.

Заглянем внутрь. Там внутри -- ад и пламень. В начале декомпозиция, потом разработка частей, в конце интеграция. И разработка каждой части -- тоже чёрный ящик. У него есть вход, у него есть выход. И есть для каждой части специальный тестировщик, который тестирует эту часть. Перед разработкой части вход верифицируется, после разработки выход подвергается контролю. А внутри этих маленьких чёрных ящиков, оказывается тоже не всё просто устроено, там ещё меньшие чёрные ящички, и так далее, до бесконечности... Шутка. Кончатся же они когда-нибудь! :)

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

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

[Viktor]

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

А вот такой подход гораздно более интересный, целесообразный, правильный, качественный, оптимальный (не нужное зачеркнуть!):
Некий артефакт появляется на выходе ящичка хоть белого, хоть черного - делаем ему верификацию (потому как этого вполне достаточно!) и суем в следующий и т.д., пока не вываливается артефакт в виде готового продукта, тогда аттестируем (конкретно!), представляем объективные доказательства (не подкопаться!) - и кладем баксы в карманы - все счастливы, заказчик, разработчик, я, ГОСТ, Анатолий, Алексей и Сергей?

[barancev]

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

А вот такой подход гораздно более интересный, целесообразный, правильный, качественный, оптимальный (не нужное зачеркнуть!):
Некий артефакт появляется на выходе ящичка хоть белого, хоть черного - делаем ему верификацию (потому как этого вполне достаточно!) и суем в следующий и т.д., пока не вываливается артефакт в виде готового продукта, тогда аттестируем (конкретно!), представляем объективные доказательства (не подкопаться!) - и кладем баксы в карманы - все счастливы, заказчик, разработчик, я, ГОСТ, Анатолий, Алексей и Сергей?

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

[Viktor]

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

А вот расскажите мне (нам?), Алексей, какие Вы (в особенности, как менеджер проекта) видите возможные печальные последствия в соблюдении данной процедуры?
Заранее благодарю.