Перейти к содержимому

Фотография

Verification & Validation - что это такое?


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 67

#21 barancev

barancev

    Администратор

  • Admin
  • PipPipPipPipPipPip
  • 6 871 сообщений
  • ФИО:Алексей Баранцев
  • Город:Россия, Москва


Отправлено 15 сентября 2004 - 09:58

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

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

С удовольствием расскажу.

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

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

Что проверит архитектор? Он проверит, что требования полны, замкнуты и непротиворечивы. Это критерий "правильных входных данных" для его работы. Что он не проверит? То, что модель адекватно отражает реалии предметной области. Это -- критерий "правильных выходных данных" анализа и моделирования.

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

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

Почему так произошло? Потому что не выполнялся контроль результата каждой деятельности -- проверка того, что выходные данные соответствуют входным, а проверялось только то, что этот результат годится для того, чтобы отдать его на следующий этап.
  • 0
Алексей Баранцев
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium

#22 Viktor

Viktor

    Активный участник

  • Members
  • PipPip
  • 142 сообщений

Отправлено 15 сентября 2004 - 10:29

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

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

С удовольствием расскажу.

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

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

Что проверит архитектор? Он проверит, что требования полны, замкнуты и непротиворечивы. Это критерий "правильных входных данных" для его работы. Что он не проверит? То, что модель адекватно отражает реалии предметной области. Это -- критерий "правильных выходных данных" анализа и моделирования.

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

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

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

Алексей, я Вас (себя?) здесь и подловил, за что Вам спасибо :)
В этой ситуации вообще выпал процесс верификации :) (по ГОСТ 12207)

Вот именно то, что не проверяется в Вашем примере, я и называю - верификация :) - соответствие результатов фазы результатам предыдущей (под словом предыдущая не понимается какой-то определенный порядок, просто более раняя).
  • 0
Виктор, Еретик РУПа

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

#23 Гость_amilner_*

Гость_amilner_*
  • Guests

Отправлено 15 сентября 2004 - 14:14

Именно разработчика я и рассматриваю в качестве "черного ящика"...

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

Окончательно запутался в чёрных ящиках - (1)программная система, (2)процесс её создания, а теперь уже (3)сам разработчик превратился в ящик :) ...Предлагаю, временно отбросить эту модель.
Вторую часть приведённой цитаты, как и некоторые другие реплики Сергея,несколько выходящие за пределы рассматриваемой темы, постараюсь позднее прокомментировать в базовой теме «Русскоязычная терминология». Главное, что мои оппоненты признали, что промежуточные результаты всё-таки существуют и должны быть предметом проверки/оценки/тестирования/контроля/обеспечения качества(выберите любое название на свой вкус).

А теперь несколько цитат из [1, p.30-31](кстати, на мой взгляд, лучшей в методологическом и в прикладном плане книге по тестированию):

Definition: Testing = verification plus validation

Verification, as defined by IEEE/ANSI, is process of evaluating a system or component to determine whether the products of a given development phase (выделено мной- А.М.) satisfy the conditions imposed at that phase.

Validation, as defined by IEEE/ANSI, is process of evaluating a system or component during or at the end of the development process to determine whether it satisfies specified requirements.

Сразу скажу, что я противник левой части первого определения, которая, кстати, не вытекает их стандартов IEEE/ANSI, и, как и в [4], например, считаю, что тестирование суть динамическая часть объединенного (по IEEE/ANSI) понятия Verification & Validation. Об этом я много пишу в своём курсе и, может быть, ещё вернусь к этому вопросу в базовой теме. Однако, ни в этом сейчас дело. Главное, что при проверке программ нет третьего понятия, не попадающего бы в категорию либо Verification, либо Validation. Как я уже говорил, в традиционной русскоязычной инженерии есть(или было?) -там рассматривалась триада : входной, промежуточный и выходной контроль, а в рассматриваемой системе понятий нет- здесь только пара! Именно, поэтому в Verification они и говорят о «данной фазе проектирования», частным случаем которой и является некоторая первая фаза, на вход которой и поступает техническое задание(реплика Алексея о том, что ТЗ и ТТ являются разными понятиями я также, по возможности, прокомментирую в базовой теме).

<продолжение следует>

#24 barancev

barancev

    Администратор

  • Admin
  • PipPipPipPipPipPip
  • 6 871 сообщений
  • ФИО:Алексей Баранцев
  • Город:Россия, Москва


Отправлено 15 сентября 2004 - 14:42

Анатолий, никаких возражений. Полностью Вас поддерживаю и полностью соглашаюсь с IEEE/ANSI.

Если мы рассматриваем в качестве "данной фазы разработки" весь процесс (большая такая фаза :)), то верифицировать будем требования, а контроль осуществлять за конечным продуктом -- что он соответствует этим требованиям.

Для целей методологических такое определение меня более чем устраивает.

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

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

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

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

Ну и, наконец, стало ясно, где граница между верификацией и валидацией -- она проходит прямо посредине "чёрного ящика данной фазы разработки" :)

И ещё -- полностью Вас поддерживаю в том, что Testing != verification plus validation. Впрочем, своё согласие с тем, что это динамическая составляющая V&V (насколько из первого V вообще можно выделить динамическую часть, вся динамика попадает во второе V), я уже подтвердил в анкете.

А по-поводу термина "упреждающая оценка" я тоже уже высказался, что он мне нравится, но не в паре с техническим контролем (по моему мнению, они не составляют пару), а в такой тройке:
упреждающая оценка -> обеспечение качества -> контроль качества
как модели управления качеством.
  • 0
Алексей Баранцев
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium

#25 Гость_amilner_*

Гость_amilner_*
  • Guests

Отправлено 15 сентября 2004 - 16:09

И заключительная часть моего сериала под названием «Последнее слово»

Анатолий, никаких возражений. Полностью Вас поддерживаю и полностью соглашаюсь с IEEE/ANSI.

Если мы рассматриваем в качестве "данной фазы разработки" весь процесс (большая такая фаза :)), то верифицировать будем требования, а контроль осуществлять за конечным продуктом -- что он соответствует этим требованиям.

Для целей методологических такое определение меня более чем устраивает.

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


Да и не должен стандарт давать практические рекомендации. Но, если Вас интересует методика, загляните в [3,p.405, How to Test Requirements ]. Там подробно рассматривается задача проверки технических требований(технического задания, что в данном случае одно и тоже, уверяю вас) на выходе первой(из нескольких!!!) внутренних стадий проектирования программ. И ни о какой «большой такой фазе» речи там нет, как и нет её в SDT Dotted-U model [1], с которой Вы согласны (цитирую Вас):

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

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

1. Requirement specification-> Requirement verification
2. Functional design specification -> Functional design verification
3. Product simulation -> Usability test(Validation)
4. Internal design specification-> Internal design verification
5. Code -> Code verification
6. Product simulation -> Usability test(Validation)
7. Code and spec. modification -> Unit validation
8. Code and spec. modification -> Integration validation
9. Product simulation ->Usability test(Validation)
10. Code and spec. modification -> Function validation
11. Code and spec. modification -> System acceptance validation

Слева от стрелки указывается работа жизненного цикла программного обеспечения, справа соответствующая ей работа жизненного цикла тестового обеспечения. Противоречит это моему подходу только в одном - я отношу работы по п.п. 3,6,9 к верификации. Но в любом случае, как минимум, п.п. 1,2,4,5- это верификация промежуточных результатов(упреждающая оценка) на разных внутренних этапах проектирования программ.
Кстати, Алексей, Code verification- это в данной модели ни что иное, как тестирование макета/прототипа разрабатываемой программы.

#26 barancev

barancev

    Администратор

  • Admin
  • PipPipPipPipPipPip
  • 6 871 сообщений
  • ФИО:Алексей Баранцев
  • Город:Россия, Москва


Отправлено 15 сентября 2004 - 19:49

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


Да и не должен стандарт давать практические рекомендации. Но, если Вас интересует методика, загляните в [3,p.405, How to Test Requirements ].

Я, вообще говоря, не то чтобы задавал этот вопрос, а просто отметил, что он есть. Но тем не менее, спасибо за ответ :)

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

Во истину, каждый видит то, что хочет видеть :) .

Воистину так! Я тоже начинаю уже подозревать, что моя интерпретация Dotted-U model отлична от интерпретации Анатолия. Интересно, а как это интерпретировал сам автор?.. :)

Хотя, как Алексей может видеть в этой модели подтверждение своей суженной трактовки понятия верификации?

Суженная, значит? Хе-хе :)

Но в любом случае, как минимум, п.п. 1,2,4,5- это верификация промежуточных результатов(упреждающая оценка) на разных внутренних этапах проектирования программ.

А это уже более серьёзно.

Давайте предположим, что Вы правы, и пункты 1,2,4,5, а также, поскольку Вам так кажется, пункты 3,6,9 -- это верификация. Надо понимать, что остальные -- это контроль. Вопрос: а в чём отличие? Ведь и те, и другие относятся к оценке или проверке некоторых промежуточных результатов.

Опять же, если буквально следовать определению IEEE, validation -- это оценка или проверка системы или компонента "during or at the end of the development process" (выделено мной). То есть опять-таки -- промежуточных результатов.

Так как же отличить, где верификация, а где контроль?

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

Надо ли это понимать так, что "упреждается" следущая фаза (она есть, поскольку оценивается или проверяется промежуточный результат)?

Тогда получается примерно такое определение: все деятельности по оценке, проверке и контролю, кроме самой последней (условно говоря -- тестирования конечного продукта), представляют собой верификацию, поскольку относятся к промежуточным результатам, и только последняя -- это контроль.
  • 0
Алексей Баранцев
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium

#27 Гость_amilner_*

Гость_amilner_*
  • Guests

Отправлено 16 сентября 2004 - 14:02

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

Да, Алексей, абсолютно верно!!!!!

Остались, некоторую нюансы, и о них я говорю в теме 1.1 своего курса. Но это уже для гурманов :rolleyes: .

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

#28 barancev

barancev

    Администратор

  • Admin
  • PipPipPipPipPipPip
  • 6 871 сообщений
  • ФИО:Алексей Баранцев
  • Город:Россия, Москва


Отправлено 16 сентября 2004 - 19:23



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

Да, Алексей, абсолютно верно!!!!!

Сказать, что я недоволен таким определением -- ничего не сказать.

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

Ну и, кроме того, такой трактовки обсуждаемых понятий я нигде не встречал. В том числе и в Вашем курсе. Я бы даже сказал, что упомянутые Вами "нюансы" не уточняют эту формулировку, а слегка противоречат ей. Ибо как, при таком подходе, может получиться такая вещь, как input validation или technological validation?
  • 0
Алексей Баранцев
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium

#29 barancev

barancev

    Администратор

  • Admin
  • PipPipPipPipPipPip
  • 6 871 сообщений
  • ФИО:Алексей Баранцев
  • Город:Россия, Москва


Отправлено 10 декабря 2004 - 08:58

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

Вот это послужило последней каплей: http://geekswithblog...1/30/16490.aspx (особенно последняя строчка таблицы) :)
  • 0
Алексей Баранцев
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium

#30 Гость_amilner_*

Гость_amilner_*
  • Guests

Отправлено 10 декабря 2004 - 18:34

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

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

#31 demon777

demon777

    Новый участник

  • Members
  • Pip
  • 17 сообщений

Отправлено 06 июня 2008 - 09:00

Как отметилось выше валидация может осуществляться для любых систем. Об этом описывается в ГОСТе 15288 и в техническом отчёте по этому стандарту.
А вот в чём специфика валидации именно в ИТ области?
  • 0

#32 noonelf

noonelf

    Новый участник

  • Members
  • Pip
  • 7 сообщений

Отправлено 11 февраля 2009 - 09:49

Случайно прочитал такую статью.

Не знаю что автор (Борис Бейзер - автор цитат приведенных в статье) имел ввиду когда писал это, но, все смешалось, кони, люди. Пост именно в этой ветке немного не в тему, однако: может ли кто-нибудь однозначно, точно, а главное структурно определить взаимосвязь между Testing, Quality control, Quality assurance, Verification and Validation?

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

Буду благодарен за конструктивные ответы.
  • 0

#33 SALar

SALar

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 2 298 сообщений
  • Город:Москва


Отправлено 11 февраля 2009 - 14:51

Случайно прочитал такую статью.

Не знаю что автор (Борис Бейзер - автор цитат приведенных в статье) имел ввиду когда писал это, но, все смешалось, кони, люди. Пост именно в этой ветке немного не в тему, однако: может ли кто-нибудь однозначно, точно, а главное структурно определить взаимосвязь между Testing, Quality control, Quality assurance, Verification and Validation?

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

Буду благодарен за конструктивные ответы.

Бейзер очень сильно прав. Но чтобы понять его нужно довольно много знать. По поводу взаимосвязи подумаем.
  • 0

-- 

Сергей Мартыненко

Блог 255 ступеней (байки для оруженосца)

facebook (Дети диаграммы Ганта)

ВебПосиделки клуба имени Френсиса Бэкона 

 


#34 novak

novak

    Новый участник

  • Members
  • Pip
  • 67 сообщений
  • Город:MO

Отправлено 11 мая 2009 - 18:55

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

Давайте попробуем, исходя из результатов дискуссии выше. Для начала стоит сказать, что при разработке ПО мы имеем дело с двумя ипостасями той самой программы - теоретической, т.е. те самые требования, модели и т.д. и практической - собственно, реализацией. Есть ещё третья, так называемые "потребности пользователя", но они достоверно на 100% обычно не известны, потому и возникает потребность в анализе этих самых потребностей для выработки теоретической модели. Тогда:
Validation - проверка того, насколько требования (теоретическая модель разрабатываемого ПО, представления аналитика - или разработчика - о продукте) соответствует тем самым ожиданиям. Отсюда валидация (или в терминах ГОСТ Р ИСО/МЭК 12207-99, аттестация) и определяет "делаем ли мы правильный продукт", "удовлетворяет ли он цели организации-разработчика и нужды пользователей" и другие пункты из ссылки Алексея. По поводу перевода, имхо, ГОСТ тут приводит отвратительное определение, только в примечании раскрывая смысл, однако факт остаётся фактом - validation == аттестация, но и термин валидация уже прижился и он вносит меньше путаницы. Лично я использую именно слово "валидация".
В этом случае тем самым объектом выступает теоретическое представление о программе.

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

В случае с тестированием всё не так просто. Дело в том, что этот термин 1) не определён чётко в ГОСТе, 2) определён во многих местах по-разному, в зависимости от понимания автора. Можно сказать, что одно из пониманий тестирования - тот самый контроль качества, QC - во многих англоязычных источниках я встречал смешение этих терминов. Также можно рассматривать тестирование чисто с прикладного уровня, тогда можно выделить его отдельно от контроля качества. В таком случае тестирования будет исследованием программного продукта, в результате которого имеем информацию о том, как продукт работает (это что касается реализации, тестирования, собственно, программы), или информацию о требованиях (т.е. тестирование требований, той самой теоретической части). На основании полученной информации можно уже проводить верификацию и валидацию, соответственно, которые и будут составлять контроль качества. Потому как раз определение тестирования - дело вкуса. Главное, определить для себя цель этой деятельности, отсюда можно выводить и удобное для себя определение.
  • 0

#35 Natalya Rukol

Natalya Rukol

    Профессионал

  • Admin
  • PipPipPipPipPipPip
  • 2 001 сообщений
  • Город:Moscow


Отправлено 21 июля 2009 - 15:07

Случайно прочитал такую статью.

Не знаю что автор (Борис Бейзер - автор цитат приведенных в статье) имел ввиду когда писал это, но, все смешалось, кони, люди. Пост именно в этой ветке немного не в тему, однако: может ли кто-нибудь однозначно, точно, а главное структурно определить взаимосвязь между Testing, Quality control, Quality assurance, Verification and Validation?

Testing - процесс, направленный на выявление текущего состояния ПО (что работает а что не работает)

Quality Control
- процесс, направленный на выявление готовности продукта к выпуску (с учётом рынка и внешних требований)

Quality Assurance - действия, направленные на обеспечение качества, такие как внедрение методологий, технологий, средств и т.д. (как в тестировании так и в разработке, аналитике)

Verification - проверка продукта на соответствие требованиям. Выполняется в рамках Testing и Quality Control.

Validation - проверка продукта на соответствие ожиданиям пользователей, оценка их потенциальной удовлетворённости. Выполняется в рамках Quality Control.

Объяснение терминова Validation и Verification даны в соответствие с ISO 9001 и смысла спорить о корректности терминов не вижу :)

P.s. Для схематичности добавляю картинку, строго не судите :)

Прикрепленные файлы

  • Прикрепленный файл  qc_test.gif   50,89К   46 Количество загрузок:

  • 0

#36 Alfa

Alfa

    Специалист

  • Members
  • PipPipPipPipPip
  • 553 сообщений
  • Город:Moscow

Отправлено 21 июля 2009 - 16:44

Объяснение терминова Validation и Verification даны в соответствие с ISO 9001 и смысла спорить о корректности терминов не вижу :)

Вы наверно сами переводили эти определения с буржуйского языка, потому что в ГОСТ Р ИСО 9000-2008 они другие.

верификация (en vérification; fr vérification): Подтверждение на основе представления
объективных свидетельств (3.8.1) того, что установленные требования (3.1.2) были
выполнены.

валидация (en validation; fr validation): Подтверждение на основе представления
объективных свидетельств (3.8.1) того, что требования (3.1.2), предназначенные для
конкретного использования или применения, выполнены.

По поводу остальных трех терминов мне всегда нравилась статья Alan S. Koch «Testing vs. Quality Assurance».
  • 0

Чубака — это вуки с планеты Киши, но живет Чубака на планете Эндо, а теперь вдумайтесь:
в этом же нет смысла. С какой стати Чубаке, вуки высотой два с половиной метра,
жить среди эвоков, которые чуть выше полуметра. В этом нет абсолютно никакого смысла.


#37 Natalya Rukol

Natalya Rukol

    Профессионал

  • Admin
  • PipPipPipPipPipPip
  • 2 001 сообщений
  • Город:Moscow


Отправлено 21 июля 2009 - 16:51

Вы наверно сами переводили эти определения с буржуйского языка, потому что в ГОСТ Р ИСО 9000-2008 они другие.

А в чём смысловое несоответствие между моей свободной трактовкой и Вашей цитатой ГОСТа? :good:

ИМХО у определения превалирует смысловая нагрузка, а не стилистическаяю Тем более что в ГОСТе эти определения встречаются в разных местах с разными формулировками - первые, попавшиеся мне (пп 7.3.5 и 7.3.6) Вашим не соответствуют...
  • 0

#38 novak

novak

    Новый участник

  • Members
  • Pip
  • 67 сообщений
  • Город:MO

Отправлено 21 июля 2009 - 19:28

Testing - процесс, направленный на выявление текущего состояния ПО (что работает а что не работает)

Добавление в скобках скорее всего является лишним, ибо понятия "работает-не работает", "правильно-неправильно" уже относятся к верфикации и Quality Control`у
  • 0

#39 Natalya Rukol

Natalya Rukol

    Профессионал

  • Admin
  • PipPipPipPipPipPip
  • 2 001 сообщений
  • Город:Moscow


Отправлено 21 июля 2009 - 20:46

Testing - процесс, направленный на выявление текущего состояния ПО (что работает а что не работает)

Добавление в скобках скорее всего является лишним, ибо понятия "работает-не работает", "правильно-неправильно" уже относятся к верфикации и Quality Control`у

Не так.
1) В требовании написано "должно запускаться", но не запускается => не работает => валидация
2) Quality Control сам по себе не бывает, он основывается на данных тестирования
  • 0

#40 novak

novak

    Новый участник

  • Members
  • Pip
  • 67 сообщений
  • Город:MO

Отправлено 22 июля 2009 - 02:16

Не так.
1) В требовании написано "должно запускаться", но не запускается => не работает => валидация
2) Quality Control сам по себе не бывает, он основывается на данных тестирования

Как бы, в соответствии с описанными выше определениями
тестирование -> не запускается -> верификация, что в требованиях (явных или нет) "должно запускаться" -> не работает
Жирным я выделил тот самый Quality Control, основанный на предшествующем тестировании
Естественно, что с точки зрения практики выгоднее совмещать процесс тестирования и верификации
Место же валидации в определении, что требование "должно запускаться" соответствует желаниям пользователей\заказчика. Как вариант, ещё проверка, что именно так должно запускаться и т.д. То есть, оценивается правильность самого требования.
  • 0


Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных