В этом деле майкрософту можно смело доверять :)

Хочется предупредить вас всех от попытки создания некоторого FAQ-списка. Это зло. Это преднамеренное зло, которое только вредит. Ответ "смотри FAQ" только оскорбит посетителей, он перестанет задавать вопросы. Дурацкий ответ в FAQ-е нанесет урон репутации портала. Но вы этого не увидите, вы будете находиться за FAQ-ом. Почему люди состовляют FAQ? Им трудно отвечать на одни и те же вопросы, разумно? Ерунда, им не хочется отвечать на одни и те же вопросы. Захочет ли кто-нибудь задать вопрос этим людям? Не знаю, сомневаюсь.
Вот прочитал дурацкий вопрос в одном FAQ: "Я сел составлять Test Cases, что мне для этого нужно?". И ни как уж мне не нужен дурацкий ответ "знание системы" или еще круче "Глубокое знание функциональности продукта". Это самый дурацкий ответ, который я могу себе представить. О каком продукте идет речь? О какой системе идет речь? Каким образом "чтение документации" приблизит меня к составленным Test Case-ам? Я миллион раз читал документацию, и не появилось ни одного Test Case. Хороший ответ для меня будет таким: карандаш и бумага, word и excel, Rational Test Manager, кофе и пицца, winamp и сборник любимых песен "Ласкового мая". Вот это нужные вещи, а чтение документации до Test Case не доведет. А для другого нужен другой ответ. Будет ли он спрашивать: "прочитал в FAQ-е дурацкий ответ про winamp, а мне чего-то еще не хватает, подскажите?", нет не будет. Т.е. если вы против дискуссии, создавайте FAQ. Он заменит вам дискуссию.

А в чем сложность? Используйте Ado, их Basic это позволяет, нет?
Или воспользуйтесь ODBC. Четыре функции: подключился, выбрал, взял, отключился.

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

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

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

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

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

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

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

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

О "мухах"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Да

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Статья хорошая.
Но вот ведь какая штука: ехал я как-то по российскому (без)дорожью, медленно, рассматривая окрестности и наблюдал следующую картину:
Дедок лет 80 при лаживает к одной гнилой досочке другую, что бы хоть как-то более пристойно выглядел его забор.
А теперь идея:
Как застраховаться от подобных случаев? Обучение - обучением, но цель XP - оптимизация использования ресурсов.
Есть ограничения по времени - добавляем людей. Но не приведет ли к этот путь к тому, что человек станет более безответственнен? Будет полагаться на товарища? Или потеряется перед ним? Или наоборот? Разумно ли это?
Самостоятельность, ответственность, стремление к поиску решений - все это может быть перечеркнуто добавлением дегтя.
Применение XP опасно, особенно если методологически и технологически необосновано.
Такие двойки требуют повышенного внимания менеджера, не случайно ХР ориентирован на небольшие команды.
А завтра? по три будут собираться? :)
Я не противник ХР, и даже наоборот, какая-то чувствуется выгода, но хочется ее выразить более конкретно и ускользает она от меня :)

Да перестаньте вы :),
Что у нас происходит :)?

Если один уч учит неуча, так это также далеко от ХР как и от нормальной работы.
По службе приходится этим заниматься, так хуже нет таких моментов.
Пусть лучше шеф за плечо встанет - тут такое ХР начнется, не остановишь :).

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

Case, расскажите лучше, как создать сбалансированную пару (как у Вас это получается).

Подход работает и там и там - и для новых игроков (кстати новичёк - он не "лопух", куда вы его, по-моему, записывате - он просто новичёк в нашей команде) и для тех, кто уже работал.

Новичков не интересно вводить в дело? Угу, мои соболезнования тем, кого вы берёте на работу.

Неправда, я ТАК даже не думал, вернее сначала не думал, а потом решил прояснить но слово лопух мне не нравится.
Не лопух - хорошо, я вот, например, сейчас крупный специалист (образно), а раньше 15 лет назад, кто?
Лопух? нет, неуч - да, непрофессионал - да. Лопух - сорная трава, сколько не возделывай - пользы никакой. Неуч - тот кто не учился (ну негде было).

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

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

Здесь все отталкиваются от установленных правил (опять же признаю, что эти правила проверены временем) - ведь мы с вами живём в прекрасной стране (и Россия и Беларусь) - и не в этой стране разработаны общепринятые правила ведения документации!! Почему бы нам не придумать и ввести новый тип описания!

Думаете, любовь к Родине - достаточный аргумент, чтобы набрать "format c:"?