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

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

Да у Вас в Москве хватает и приличных работодателей. Нужен только ОДИН

Почему один? А другие тестировщики что, хотят работать у неприличных работодателей?

Для одного работника нужен один работодатель, на двух работодателей трудно работать :)

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

Да у Вас в Москве хватает и приличных работодателей. Нужен только ОДИН :)

Для одного работника нужен один работодатель, на двух работодателей трудно работать :)

У меня такое било :D. Когда я искал новую работу, то так получилось, что я во время отпусков на старой фирме, проходил испытательный период на новой фирме. Я ни в коем случае не мог остаться без работы, даже на несколько недель (пока искал новую работу). :unsure:

С отпуска сплошь и рядом народ течет. Иногда по этой причине даже отпуска не дают :)

Может потому что у нас отпуск 2 недели, а испытательный период 1-2 месяца.

Не догадываетесь почему (сейчас стало модно) отпуск 2 недели, а испытательный срок 1-3 месяца?

Не догадываетесь почему (сейчас стало модно) отпуск 2 недели

Это просто у американцев сдули.

Такие решения не принимаются с кондачка. Даже если у американцев
Почему зарплату не сдули? :)

Хорошая дискуссия. Поучаствую.
Ответ: нисколько, 0, ни минуты не должны "сидеть на одном месте". Это преступление, халатность и т.д. Представьте себе, человек работает за рабочим местом, руководитель спрашивает (возможно, провокационно, а может и просто не в курсе) "чем занимаешься?". Ответ "сижу" повергнет его в шок! (Если юмора нет, юмор не у всех есть). Новый работодатель не в курсе Вашей бывшей работы, но если, например, мне сказать, что "я просидел 1-25 лет", мой ответ будет простым - "замечательно, пришло время размяться, желаю удачи". "Массажером" уже никак я не буду.
Поэтому встаньте на позиции Вашего работодателя, а у него, на мой взгляд на Ваше сообщение, будут следующие:
Во-первых, подозрения вызывают сроки работы - т.е. на предпоследнем 2 года, на последнем 1, на новом 0,5? :) Это действительно Ваше слабое место. Говорите, что ушли, потому что работа была не в сфере ваших интересов профессионального роста. Что это значит? Предположим Вы хотите работать тестеровщиком это сфера Ваших интересов, а на Вас вдруг навесили обязанности по установке и поддержке эксплуатации продукта. Но Вы должны честно признавать причины, по которым ушли с предыдущих мест. В любом случае хороший работодатель проверит, и, если причина "надоело работать", она поставит на Вас крест.
Во-вторых, возможно, начальнику досмерти самому надоело, ему хочется перспектив, денег и т.д и вдруг Вы!!! Покажите, что Ваша перспектива отличается от его перспективы. Имеется в виду - руководитель ищет управленческого роста, специалист - профессионального.
В-третьих, очередная пафосная тирада в адрес фирмы, действительно бальзам на самолюбие руководства, ну даже если не бальзам, то Вас уже не сбросить со счетов. Узнайте до собеседования о фирме как можно больше.
А вообще на самом деле, главное - это желание работать в этом коллективе над решением данной конкретной проблемы в данной конкретной фирме на определенный (вполне возможно, до пенсии) конкретный срок, при этом обладая требуемыми навыками, вот это хочет услышать работодатель.
И мой Вам (в смысле любому) совет - не работайте там, где ответ - хочу больше денег - воспринимается в штыки. Бывают разные времена у фирм, но если материальный интерес работников идет в разрез с интересами руководства - фирма обречена и работники вместе с ней, в конце концов, в ней соберутся одни неудачники. А от кого в первую очередь избавляются неудачники? Кого они обвинят в своих неудачах (а их будет достаточное количество)? Оно Вам надо?

Что-то я не пойму, а Ваша знакомая что в резюме написала что она 3 раза сменила работу ? Если так то ей надо било написать последнее название фирмы. А если бы возникли какие то вопроси то разъяснить что и как.

Да писала, все названия фирм со временем работы на них.
Спасибо за совет, я ей передам, чтобы писала только последнее место работы.

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

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

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

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

Более того, аргументы 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, у нас не получится, потому что мы всегда говорим с разных позиций.
Действительно: если мы смотрим на систему - вариант (ее) использования, на пользователя - типовой пользовательский сценарий (процедура), на поведение actors - случай (прецедент) использования. Получается, что у нас каждый термин имеет право существовать. Каждый частный случай имеет свое название, общий - нет (в русском языке). Называя вещи, мы теряем их суть. Слишком много для одного термина - суть уже практически не видна. Пора прекращать.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

О "мухах"

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

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

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

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

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

Предположим, Вы тестируете  :)
По rup Вы никаких преобразований с программой не делаете :), просто итеративно программа с малой функциональностью становится программой с большей функциональностью :)

Т.е. в процессе тестирования программа обретает новую функциональность? :)

На какие ши-ши?

На какие ши-ши?

К сожалению, я не всегда понимаю Ваши высказывания.

:(
The truth is ... (skipped) I'm tryin' real hard to be ...(skipped)
(С) Pulp Fiction

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

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

Ну, господа, даже и не знаю что сказать... Компания в которой я работаю сертифицирована по CMM Level 5, и при этом использует RUP. По-крайней мере, все артифакты у нас пишутся именно по RUPовским шаблонам. Да и роли, по-большей части соответствуют.  Сертифицированы ли мы по 9000 не помню, но, кажется, да...

Слава Богу!!! А то я уж испугался :)

Слушайте, ну я так не играю, шаблоны ... роли ..., я, например, реквизит использую

Где практики? Дайте нам объективные доказательства :)

PS. Сейчас почитаю
12207 и RUP

Ну, господа, даже и не знаю что сказать... Компания в которой я работаю сертифицирована по CMM Level 5, и при этом использует RUP. По-крайней мере, все артифакты у нас пишутся именно по RUPовским шаблонам. Да и роли, по-большей части соответствуют.  Сертифицированы ли мы по 9000 не помню, но, кажется, да...

А у Вас процессы имеются?
ИСО 12207 соблюдаете?

И не увидите, Вы же внедрили и RUP и ИСО :)

Виктор, расскажите нам, что Вы такое видите, чего мы не видим? Интересно же :)

RUP -- это процесс, а ISO -- набор требований к процессу. Ничто не мешает сделать процесс, построенный на RUP так, чтобы он удовлетворял этим требованиям. Что Вас смущает в этом сочетании?

По rup Вы никаких преобразований с программой не делаете :), просто итеративно программа с малой функциональностью становится программой с большей функциональностью :)

Это не RUP, это ересь какая-то! Магия и ересь :)

Видит бог - я держался,
но Алексей, как можете Вы передергивать? Вырывать из контекста? как нам продолжать беседу?

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

Давайте теперь и я Ваши, Алексей, слова надергаю.
RUP- процесс (в ед.числе), никто не спорит, а то что ISO - требования к процессам (многим), так там это написано, перечитайте
Вот тут намешали все понятия в кучу, хотя Вы же их разделяете
Вы говорите что discipline - это не процесс, хотя RUP говорит наоборот, правда добавляет слово "грубо", мне же это упрощение (для Вас усложнение, см. цитата про синхронизацию ниже) непонятно, зачем вообще нужно слово discipline? Вы его переводите как подпроцесс - Вам не нравится, мне нравится, никому не нравится, что это за зверь такой? Слон? За какую часть мы все держимся? Ну пусть я за хвост, так покажите мне его целиком. Вот, я немножко пощупал с Вашей стороны - действительно "грубо" похож на хвост.
И соглашаюсь с Вами хвост действительно похож на хобот, Ваша точка зрения в чем-то верна, и я понимаю что процессно-ориентированный подход, слишком дорого обходится в однодневных (имеется ввиду не один день, а просто их небольшое количество вплоть до 5 лет) проектах, в которых Вам доводилось участвововать.
А беспорядочно (прошу заметить, сначало хотел применить другое синонимичное слово)-ориентированный подход - очень даже поможет сэкономить. Удастся - хорошо, не удастся - господь с ним.

То что в RUPe идет первой строкой для Вас (вдруг) магия и ересь. Я приведу ее, а то опять передернут: Iterative Development. Для вас ересь, что тестирование - часть итеративного процесса разработки?
Магия, что в результате процесса разработки появляются программные продукты?
Может аист их приностит менеджеру проекта?

Вот Вы пишите

И я Вам говорю, что модель, построенная на разделении процессов и синхронизации их в контрольных точках не работает

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

Они намеренно и сознательно сужают тему и выделяют деятельности по тестированию из всех остальных, пытаясь рассматривать их хотя бы в частично изоляции

А я говорю, что при создании внутреннего ПО нет никакого сужения в этом вопросе - так оно и есть, а для процессов создания ПО широкого потребления возможно нужны другие методологии и стандарты(Многим достаточно только шаблонов и названия должностей)

Остальные упомянутые Вами термины (process, thread, task, work) в RUP не используются

(выделено мной) процесс в RUP не используется, почему? Почему они придумали кучу своих терминов, далеких от реалий жизни, что это за модель, из которой все берут только шаблоны и названия должностей?

Поэтому я бы сказал, что RUP эксплуатирует деятельностно-ориентированный подход

А ИСО - процессно-ориентированный и это термин определен в ИСО, а деятельностно-ориентированный подход это Ваш термин и это Ваша задача придумать 10 различий и мне показать

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

А заглянуть и убедиться трудно в ИСО9000? Я заглянул, убедился, что Вы абсолютно не правы, во теперь и Вам это будет известно
Да! Есть еще системный подход к управлению

Процессы трудно синхронизировать в milestones, если что-то пошло не очень гладко и один из процессов, например, отстаёт от плана, а остальные нет

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

Качество обеспечивается, когда его обеспечивают

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

Если кому-то мои слова покажутся резкими, прошу меня извинить.

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