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

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

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

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

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

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

Да

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я вообще серьезно отношусь только к вождению автомобиля и утренней сигарете. От этого жизнь зависит.

А я не курю и не вожу автомобиль. Поэтому у меня нет вообще никаких угроз для жизни :)

Я не себя имел в виду :)

Более того, аргументы 2,3 Олега применимы и к этому определению, но только в отношении системы.
Откуда взялась система? Почему система в единственном лице?

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

Зачем уж так-то? Я вообще серьезно отношусь только к вождению автомобиля и утренней сигарете. От этого жизнь зависит.

Я более удачлив, мне встречалось вполне приличное определение понятия use case.

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

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

Не частью системы, а частью функциональности системы.
Или Вы считаете, что функциональность является частью системы? :)

Прошу меня извинить, Алексей, но я пока не отвечу на этот вопрос :)
А поясню подробнее, почему мне не нравится то определение.
Вот в рупе определение: Use Case - A description of system behavior, in terms of sequences of actions.
И мы понимаем что, если есть любое (А) description of system behavior, in terms of sequences of actions, то, возможно, это Use Case. Конечно, можно различать плохой или хороший use case, но смысл понятен.
То определение, которые Вы привели и за которое я пока зацепился, не удовлетворяет критерию "обратности", а следовательно - полноты.
Т.е. даже если мы вычленили некоторую часть функциональности отсюда не следует, что это use case, отсюда можно точно сказать, что это некоторая функция системы
Рассматривать use case как описание, как модель, как спецификацию - я готов. Как часть системы или ее функциональности - нет.
Более того, аргументы 2,3 Олега применимы и к этому определению, но только в отношении системы.
Откуда взялась система? Почему система в единственном лице?

Я более удачлив, мне встречалось вполне приличное определение понятия use case.

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

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

Вот чёрт! :)
Кажется, Вы не в Москве? Это хорошо-о-о...

Да нет, я имел в виду, что если едешь в автомобиле, неважно сам за рулем или нет, к этому надо относиться серьезно.
Если проснулся, а кто-то курит рядом - это тоже опасно. :)

«мухи»- варианты наименования.
Действительно, в конце концов, не всё ли равно, как мы переведём use case. Главное, что это такое и с чем его едят. И вот тут-то, на мой взгляд, начинается самое интересное. Лично мне не встречались чёткие определения или хотя бы пояснения по понятию use case. В тоже время, из контекста [3], например, следует, что use case- это что-то похожее на типовую процедуру(последовательность действий) взаимодействия пользователя с системой. Прав ли я?
Если да, то тогда отдельно можно поговорить, а как это лучше назвать. Может быть прямой перевод тут то как раз и не годится. Иногда даже калька :) имеет больше смысла, чем прямой перевод. Ведь ни кому же в голову даже не придёт перевести test case как «вариант тестирования» или, тем более, «случай тестирования».

«мухи»- варианты наименования

О "мухах"

Лично мне не встречались чёткие определения или хотя бы пояснения по понятию use case

Мне пока тоже, надеюсь :)

Ведь ни кому же в голову даже не придёт перевести test case как «вариант тестирования» или, тем более, «случай тестирования».

Сплошь и рядом :)

Еще не все "мухи" перевелись, давайте продолжим?

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

Это будет Вам уроком.

Русский язык гораздно богаче английского.

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

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

А если я скажу что robot круче, чем winrunner, вы в меня бомбой бросите? Не терпите инакомыслия? Это ваши американские хозяева научили вас этому?

Вам нужны какие-то доказательства, авторитеты? Ищите сами. Живите с найденым вечно.
Я буду всегда считать, что русский язык богаче английского. Здесь не будет дискуссии.

Предлагаю здесь остановиться по следующей причине:
Русский язык гораздно богаче английского. Что там можно назвать одним термином use case, у нас не получится, потому что мы всегда говорим с разных позиций.
Действительно: если мы смотрим на систему - вариант (ее) использования, на пользователя - типовой пользовательский сценарий (процедура), на поведение actors - случай (прецедент) использования. Получается, что у нас каждый термин имеет право существовать. Каждый частный случай имеет свое название, общий - нет (в русском языке). Называя вещи, мы теряем их суть. Слишком много для одного термина - суть уже практически не видна. Пора прекращать.

Здравствуйте, уважаемые коллеги!
Всегда интересовался осмысленным переводом на русский язык термина "use case". На моей памяти встречал около шести переводов, но все они имеют свои недостатки и, дабы не уводить дискуссию, не буду их упоминать.
Предлагаю участникам выдвинуть свой (приемлемый для него :)) перевод и кратко обосновать, например:
use case - прецедент
слово "прецедент" имеет значение "случай, имевший место ранее", но очень важно, что в русском языке оно обладает свойством абстрактности, предопределенности и апостериорности.

За "пользовательский сценарий" слово никто не замолвит?

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

Очень хотелось бы понять, чем руководствуется начальство, когда поручает решение стратегических вопросов не совсем компетентным людям?

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

:ph34r:

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

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

О какой именно работе администратора, "направленной на создание продукта", идет речь?

Закрываю здесь и дальше,
сгоряча попались мне под руку администраторы :)
Приношу свои извинения, посыпаю голову пеплом
Но ...
Я имел ввиду как раз тех "админов" (не компьютерных клубов) от чьей работы зависят десятки тысяч!!! людей.
Но не пояснил: есть конечно администраторы, которые непосредственно заняты в процессе создания продукта, кто это такие и в чем точно заключается их работа изложено в различных методологиях. Я таких целых людей :) не встречал (0,1 - 0,5 коэффициент полезности).
И есть все другие, которые имеют сношения и с высшим руководством и прочими, от чьей работы это руководство зависит, как тут говорят (хотя даже меня коробит от этих слов, не говоря уже про руководство).
И потому как сношения с высшим руководством приятнее, чем со мной, потому что я даю им Работу, а Высшее руководство наличность, первые постепенно портятся во вторые.
И простите меня, если я задел кого-то лично, но это тенденция очевидна.
Я не имел ввиду Васю или Ивана Петровича. Я вообще лично никого не имел ввиду, я говорил о тенденциях, о том что не только тестировщик профессия не признанная многими, но и многие не понимают (не полностью) смысла и целей системного администрирования при разработке программных продуктов (особенно, когда это не приоритетный бизнес).
Если Вы понимаете и цель Вашей работы как Администратора, направлена на создание Продукта, это значит Вы как раз тот 1,5 человека, а если у Вас все так работают, значит и наши полтора там :)

Предлагаю Уважаемым господам и дамам идею голосования - Кем я был до того как стал тестировать ПО

:) круто

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

Как первое контрастирует со вторым!
Ленивый творческий программер
А я всегда считал тестирование творческим процессом
а программирование, администрирование и проектирование - занудством :)

Создатель продукта (любой, разработчик, аналитик) должен быть уверен в себе и в своей работе
Тестеровщик - во всем сомневаться (особенно в создателе!)

А админы - вообще порченные, ни к какой полезной работе не годные

Например, чем меньше тестер знает программирование (и др. технические области), тем больше он найдёт проблем, которые не надут специалисты(разработчики, администраторы или аналитики ).

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

Хороший тестер сродни хакеру, а не ламеру
Кстати можно такую цепочку нарисовать:
Вначале человек подает ключи - администратор
Потом ему хочется что-то свое наваять - программист
Затем наглея он навязывает свои идеи - аналитик
А в конце (есть еще несколько ступеней, но о них потом) он понимает, что в мире полно придурков и надо спасать животных (юЗверей) - тестировщик
Но! Что бы перейти на новый уровень надо полностью отказаться от своих убеждений
Поэтому не может программист быть тестеровщиком, но хороший тестер когда-то был хорошим программистом (возможно не долго :))

Или вот тоже ;)
Скажите уважаемые Viktor и Adnrei, как давно вы занимаетесь тестированием? И какого уровня проекты вам приходилось полноценно тестировать?

Пятого, а в прошлый четверг шестого :)
А если серьезно, почему вы уважаемый Case, недовольны что я сравнил тестеров с хакерами
вот как описывается слово hack
An incredibly good, and perhaps very time-consuming, piece of work that produces exactly what is needed
А вот и hacker
A person who enjoys exploring the details of programmable systems and how to stretch their capabilities, as opposed to most users, who prefer to learn only the minimum necessary.

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

Вы не пробовали перечитывать то, что написали перед тем, как нажать на кнопку "Отправить"? :D

Пробовал :),
Но мы в России люди простые :)
И, вообще, я имел ввиду общение, причем деловое (не случайно употребил слово во множественном числе).
Вот такой он, русский язык, великий и могучий.
И уж про работу уточню - давать работу, значит занять трудом, деятельностью.
Грызите гранит :)