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

[Alfa]

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

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

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

Приведенные тексты определений отличаются не только стилистически. Посмотрите на свое определение валидации и на правильное, во втором не упоминается пользователь, его ожидания и удовлетворенность.
В ГОСТе серии Р ИСО 900Х эти определения встречаются один раз в одном месте — в ГОСТ Р ИСО 9000-2008, он так и называется «Основные положения и словарь». Названные Вами пункты присутствуют в ГОСТ Р ИСО 9001-2008, но это не определения, а описания процессов.
Весь пункт 7 называется «Процессы жизненного цикла продукции», пункт 7.3 «Проектирование и разработка», т.е. в 7.3.5 и 7.3.6 описаны процессы валидации и верификации (как делать, а не что это).

[Natalya Rukol]

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

Где Вы увидели слово "цитата"? :) Проверила - нету. :)

Предлагаю закрыть тему, я полностью согласна с Вами, просто привела "самодельные" определения, которые попроще для понимания.

[Natalya Rukol]

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

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

Я не понимаю, с чем Вы спорите :)
Вот представьте, что у Вас нет QC. Что, баги заводиться не будут, и результаты работоспособности билда в виде чек-листов, пройденных тест-кейзов и т.д. сохраняться нигде не будут?

[Alfa]

Где Вы увидели слово "цитата"? :) Проверила - нету. :)

Где-то между строк в фразе «даны в соответствие с ISO 9001».

[novak]

Я не понимаю, с чем Вы спорите :)

Топик же про понятия, потому я просто заметил, что с понятийной точки зрения есть маленькая неувязочка.

Вот представьте, что у Вас нет QC. Что, баги заводиться не будут, и результаты работоспособности билда в виде чек-листов, пройденных тест-кейзов и т.д. сохраняться нигде не будут?

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

[Natalya Rukol]

Я не понимаю, с чем Вы спорите :)

Топик же про понятия, потому я просто заметил, что с понятийной точки зрения есть маленькая неувязочка.

Понимания у меня не прибавилось :( Неувязка-то в чём? Интересно же :)

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

Частично согласна. Но что может говорить о наличии тестирования? Интересно Ваше мнение.

[LeshaL]

Наталья, у вас потерялось одно слово и опять может возникнуть неувязка:

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

Частично согласна. Но что может говорить о наличии процесса тестирования? Интересно Ваше мнение.

Кстати, на эту тему была интересная тема: http://software-test...showtopic=10838

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

[novak]

Я не понимаю, с чем Вы спорите :)

Топик же про понятия, потому я просто заметил, что с понятийной точки зрения есть маленькая неувязочка.

Понимания у меня не прибавилось :( Неувязка-то в чём? Интересно же :)

Неувязка в том, что вы в понятие тестирования подмешиваете процесс оценки, который относится уже к другому.
Ну, и чуть позже немного неясно для меня отводите валидации место, как мне показалось, как раз верификации.
2 LeshaL
В целом да, это всё нудные вопросы терминологии и теории.

[Natalya Rukol]

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

Кажется, это не то про что писал novak, НО тема интересная и впрямь :) Задуматься заставило, когда будет больше времени заведу эту тему :)

[Natalya Rukol]

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

Я так понимаю, что Вы считаете, что тестировщик не может говорить "это работает, а это не работает" и что это компетенция QC. Вы это пытаетесь сказать?

[novak]

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

Я так понимаю, что Вы считаете, что тестировщик не может говорить "это работает, а это не работает" и что это компетенция QC. Вы это пытаетесь сказать?

Почему же, совсем нет. В плане практики тестировщик должен решать поставленные задачи. Если в контексте задачи стоит вопрос "работает или нет", то он может говорить об этом, запросив необходимые ему данные для такой оценки. Получит он эти данные или нет - другой вопрос. Понятно, что в реальной жизни всё бывает иначе, нежели в теории. И в этом случае тестировщик будет заниматься верификацией, основанной на результатах тестирования. Или тестировщик не может заниматься вопросами QC?
Кстати, я понял, что меня смутило в приведённой выше схеме - там под значками лиц есть подписи: разработчик, пользователь, аналитик, тестировщик и некий QC.
Этот QC - это кто по-вашему?

[Natalya Rukol]

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

У меня эти две фразы не вяжутся, я что-то не понимаю :)

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

Кстати, я понял, что меня смутило в приведённой выше схеме - там под значками лиц есть подписи: разработчик, пользователь, аналитик, тестировщик и некий QC.
Этот QC - это кто по-вашему?

Это РОЛИ, а не люди. QC и Tester может быть один человек или разные люди, так же как аналитик, разработчик и тестер могут быть одним и тем же человеком :)

[novak]

2 Natalya Rukol
Я говорил как раз не о роли, а скорее о должности. Но можно рассматривать только роли.
В таком случае всё можно просто увязать. Согласно определениям, у роли "тестировщик" нет задачи оценки, есть задача исследования продукта, получения о нём определённой информации. Что это за информация, определяет "QC", она же (в смысле, роль) оценивает результаты - определяет работает-не работает. После чего может сказать о том, насколько качественным является продукт.

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

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

[Natalya Rukol]

novak, моя карта мира, соответствующая RUP, ISO и IEEE с Вашей ну никак не совпадает :) , потому что
1) Верификация - исконно тестерская активность
2) QC существует в теории в 1 из 100 фирм, а на практике ещё реже, поэтому стоит учитывать что обычно обходятся без них
3) Прерогатива QC - определение качества продукта, решения о готовности к выпуску и "право вето" на выпуск
4) Тестировщики тоже могут на основании метрик определять качество продукта и определять его работоспособность
5) QC - это конкретная роль (главный атрибут роли - ответственность, и этот атрибут у QC индивидуален донельзя и ни с кем не пересекается)
6) ... продолжать нет времени.

Поэтому предлагаю закончить этот диалог, т.к. конструктива я в нём не вижу. Если Вы хотите доказать, что планета не круглая - приведите ссылки на авторитетные источники :)

[novak]

Я не пытаюсь доказать ничего революционного или из ряда вон выходящего. И карта мира у всех одна, восприятие может быть разное.
И потому нужно быть просто осторожными в вопросах разграничения разных понятий. И основываться на них, а не говорить "А - это ..." "Б - это ...", а в следующем посте путать их местами. Я как раз и призываю к этой осторожности, чтобы не терять предпосылки, которые привели к эффективности тех практик, которые отражены в RUP, ISO и IEEE и так далее.
Тестировщики могут заниматься тестированием, верификацией, валидацией, программированием и всем, чем угодно. Но при этом тестирование никогда не станет верификацией. Отсюда верификация - деятельность тестера на практике. Но это не всегда эффективно. И если воспринимать верификацию зацело с тестированием, можно не заметить те ситуации, когда это происходит.
А понимание контроля качества как роли - это странно всё же. Контроль качества - это процесс, управление деятельность. Почему вы всё сводите к непонятной роли, главный атрибут которой - ответственность, совсем неясно. Тем более лишаете ответственности другие роли.

Но в целом, да, конструктива в диалоге мало, потому как постоянно мешаются вместе люди, кони роли, теории и практики.

[Clauster]

3) Прерогатива QC - определение качества продукта, решения о готовности к выпуску и "право вето" на выпуск

Круто, а ответственность (в т.ч. материальная) за результат тоже получается QC несёт?

[Natalya Rukol]

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

Может я что-то спутала и не заметила? Объясните конкретнее, со ссылками?

[Natalya Rukol]

3) Прерогатива QC - определение качества продукта, решения о готовности к выпуску и "право вето" на выпуск

Круто, а ответственность (в т.ч. материальная) за результат тоже получается QC несёт?

Ответственность (responsibility) - широкое понятие, и границы ответственности определяются индивидуально в каждом конкретном случае.

А если серьёзно подойти к вопросу - то врядли QC хотя бы в одной компании несёт материальную ответственность, максимум - отсутствие премии :)

[novak]

Может я что-то спутала и не заметила? Объясните конкретнее, со ссылками?

Здесь даны определения валидации и верификации

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

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

1) В требовании написано "должно запускаться", но не запускается => не работает => валидация

QC также выступает в качестве то роли, то процесса (в посте с определениями).
Именно с этим я и призываю обращаться осторожно.

[Vasiliy]

2) QC существует в теории в 1 из 100 фирм, а на практике ещё реже, поэтому стоит учитывать что обычно обходятся без них
3) Прерогатива QC - определение качества продукта, решения о готовности к выпуску и "право вето" на выпуск
4) Тестировщики тоже могут на основании метрик определять качество продукта и определять его работоспособность
5) QC - это конкретная роль (главный атрибут роли - ответственность, и этот атрибут у QC индивидуален донельзя и ни с кем не пересекается)

Наташ, а можно тогда соотношение QC и QA в твоей карте мира, пожалуйста? Я что-то совсем потерялся в этой ветке.