Use cases: КАК и ЗАЧЕМ

Посетив sqa days 8, одной из центральных мыслей которых (на мой взгляд) был переход от написания тест планов и прохождения тестовых случаев к выполнению пользовательских сценариев, решили внедрить в рамках нашей компании user scenarios.

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

Итак, круг интересующих вопросов:

1. На какой стадии разработки ПО пишутся пользовательские сценарии
Во-время, уточнения требований и создания основной тестовой документации ?

2. Какова их эффективность в сравнении с тестовыми случаями?
Судя по всему, мелкие дефекты так и останутся на ПМЖ в конечном продукте, однако предполагается выиграш во времени, потраченном на тестирование. Оправдано ли это?

3. Предполагает ли использование юзер кейсов полного отказа от привычной тестовой документации (тест плана, чек листа, тестовых примеров)?

4. Оптимальная структура и где/как хранить? (uml диаграммы, MS Excel, mind maps)?

5. Кто должен проходить пользовательские сценарии?
Непосредственно ответственный qa специалист или возможно приглашать другого qa, который с "незамыленным взглядом" сможет увидеть то, что человеку знающему ПО в деталях уже неподвластно?

6.На каком этапе должны выполняться? (регрессионное тестирование или тестирование новой функциональности)

7. Каково пересечение exploratory testing(о котором говорил Майкл Болтон) и use cases?

Тема, надеюсь не одной мне интересна, потому жду советов и рекомендации :) Всем заранее огромное спасибо ))

Посетив sqa days 8, одной из центральных мыслей которых (на мой взгляд) был переход от написания тест планов и прохождения тестовых случаев к выполнению пользовательских сценариев...

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

1. На какой стадии разработки ПО пишутся пользовательские сценарии
Во-время, уточнения требований и создания основной тестовой документации ?

Думаю, сразу после создания требований и до создания тестовой документации.

2. Какова их эффективность в сравнении с тестовыми случаями?

Судя по всему, мелкие дефекты так и останутся на ПМЖ в конечном продукте, однако предполагается выиграш во времени, потраченном на тестирование. Оправдано ли это?

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

3. Предполагает ли использование юзер кейсов полного отказа от привычной тестовой документации (тест плана, чек листа, тестовых примеров)?

Тест-план никак не связан с заменой тест-кейсов пользовательскими сценариями, чек-листы и тест-кейсы пропадают, мы ведь их заменяем.

4. Оптимальная структура и где/как хранить? (uml диаграммы, MS Excel, mind maps)?

Видимо где удобнее. *мысленно представляет как тестировщики будут тестировать апликуху по UML-диаграмме*

5. Кто должен проходить пользовательские сценарии?

Кто угодно, особых навыков это не требует, точнее всё зависит от специфики приложения.

6.На каком этапе должны выполняться? (регрессионное тестирование или тестирование новой функциональности)

Дык на любом этапе, на котором ранее прогонялись тест-кейсы и чек-листы.

7. Каково пересечение exploratory testing(о котором говорил Майкл Болтон) и use cases?

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

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

P.S. На SQA 8 не был, а в тестировании использую гремучую смесь чек-листов, тест-кейсов, таблиц переходов, диаграмм и карт. Стараюсь руководствоваться здравым смыслом и выбирать для конкретной ситуации оптимальный вариант.

P.P.S. Честно говоря раньше считал, что при разработки ПО происходят такие переходы: идея > use cases > user scenarios > test cases. Причем между user scenarios и test cases и происходит тест-дизайн, который есть фундамент всего тестирования, в котором суть тестирования.

1. Желательно в самом начале. Можно даже до создания требований (а некоторые предлагают вообще вместо)
2. Это разные вещи. Есть ряд вещей которые в терминах юз кейсов описать никак не получится.
3. ?
4. Нету никакой. Хотя я бы предложил Wiki. И да, записывание в mind maps того чего там по хорошему быть не должно это с моей точки зрения больше похоже на насилие и подмену понятий.
5. Зависит от. Я рискну предположить что Product Owner на приемке. Но это вырожденных случай)
6. Приемка?
7. ?

В вырожденном случае юз кейсов вам хватит, но как правило нет. Есть вещи типа поддержки разных платформ, производительности, алгоритмов опять же. Их как правило юз кейсами покрыть не получится.

В вырожденном случае юз кейсов вам хватит, но как правило нет. Есть вещи типа поддержки разных платформ, производительности, алгоритмов опять же. Их как правило юз кейсами покрыть не получится.

Вроде речь про user scenarios а не про use case. Или я что-то недопрочитал?

Вроде речь про user scenarios а не про use case. Или я что-то недопрочитал?

В начале текста да, но там ближе к концу да и в вопросах уже кейсы). К тому же разница там не сильно большая. Сценарии по сути упрощенная нарративная форма кейсов.

В начале текста да, но там ближе к концу да и в вопросах уже кейсы). К тому же разница там не сильно большая. Сценарии по сути упрощенная нарративная форма кейсов.

Аха теперь вижу, мой мозг видимо по началу отсеял юзкейсы как вообще невозможное в данном контексте :)

Ребята, спасибо за отклик ) но "света в конце туннеля" пока не вижу... Можете рассказать, конкретно вы используете use cases в процессе тестирования?

У меня все печально. У меня их нет и все requirements начинаются с user stories. Вообще все практически с них начинается. И ими же заканчивается на приемке.

Ребята, спасибо за отклик ) но "света в конце туннеля" пока не вижу... Можете рассказать, конкретно вы используете use cases в процессе тестирования?

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

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

Для меня переход к пользовательским сценариям произошел естественным образом как результат наращивания функционала в течение почти 2 лет работы над проектом. Побудительной причиной, потребителем стали ежемесячные демонстрации результатов итерации заказчику и внеплановые демонстрации функционала представителям заказчика. В первые месяцы функционал был, так сказать, кусочно непрерывным, но постепенно он дополнялся и наконец позволил реализовать важные последовательности действий пользователя.
Приложение сложное, многопользовательское, с различными ролями пользователей, позволяет реализовать множество случаев и сценариев использования (тестирования).
Процесс разработки достаточно динамичен и требуется регулярное регрессионное тестирование (smoke testing в первую очередь).
Также есть потребность в автоматизации регрессионного тестирования и нагрузочном (автоматизированном) тестировании.
Существует определенная текучесть тестировочных кадров.

Таким образом, перечислены предпосылки для использования так называемых Basic User Scenario (BUS, термин мой).
BUS не отменяют и не заменяют use cases, test cases и т.д., они позволяют сосредоточиться на критически важном функционале и быстром прогоне соответствующих тестов.
BUS это естественный способ приоритизации тестовых усилий в условиях недостатка ресурсов.

Вот мои ответы на вопросы:

1. На какой стадии разработки ПО пишутся пользовательские сценарии
Во-время, уточнения требований и создания основной тестовой документации ?

Предполагается, что требования известны, одновременно ведется разработка функционала и тестовой документации в рамках текущей итерации. С позиции зрелости приложения, смысл в BUS появляется, когда весь необходимый функционал разработан. Имеется в виду итерационный процесс разработки, когда функционал наращивается постепенно. По моему опыту это после 10-11 месяца из 24.

2. Какова их эффективность в сравнении с тестовыми случаями?

Вопрос кажется некорректным. BUS это логически, сценарно связанная последовательность Test Cases.

Судя по всему, мелкие дефекты так и останутся на ПМЖ в конечном продукте, однако предполагается выиграш во времени, потраченном на тестирование. Оправдано ли это?

Собственно, разработка и переход к BUS вызваны недостатком времени и попытка минимизировать этот риск (ограничение).

3. Предполагает ли использование юзер кейсов полного отказа от привычной тестовой документации (тест плана, чек листа, тестовых примеров)?

Тестовая документация (у нас) основывается на спецификации функциональных требований, содержащей use cases. Также BUS и пр. пишутся на основе знаний и опыта, здравого смысла, понимания предметной области, специфики использования софта.
Тест план, чек лист, тест примеры, BUS - все это используется по ситуации, догмы нет. Что от вас требуют, то и пишите. Если ничего не требуют, вааще лафа.

4. Оптимальная структура и где/как хранить? (uml диаграммы, MS Excel, mind maps)?

Тест менеджер, в идеале полностью интегрированный с функц. требованиями, SVN и тд. ;-)
Это бесплатный Testlink или дорогой SilkCentral.
Структура стандартная, стандарты разные, начиная от action/expected result и заканчивая неформальным описанием последовательности действий.

5. Кто должен проходить пользовательские сценарии?
Непосредственно ответственный qa специалист или возможно приглашать другого qa, который с "незамыленным взглядом" сможет увидеть то, что человеку знающему ПО в деталях уже неподвластно?

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

6.На каком этапе должны выполняться? (регрессионное тестирование или тестирование новой функциональности)

На обоих ;-)

7. Каково пересечение exploratory testing(о котором говорил Майкл Болтон) и use cases?

Я бы сказал, что пересечения нет. Exploratory testing дополняет, обеспечивает более полное покрытие критических функций в случае локальных или неполных требований. В моей практике Use Cases всегда локальны.

Сообщение отредактировал CVD1: 05 декабря 2010 - 18:46

Ребята, спасибо за отклик ) но "света в конце туннеля" пока не вижу... Можете рассказать, конкретно вы используете use cases в процессе тестирования?

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

У нас, к примеру, use case и (basic) user scenario разные вещи. Причем, use case это термин и сущность, которую можно обнаружить в спеке, а user scenario это мой личный тык скыть термин, для внутреннего употребления в тест тиме и тест доках. Мы парни простыя, на кохфыренцыи не ездим и книг не читаем, познаем на опыте..

4. Оптимальная структура и где/как хранить? (uml диаграммы, MS Excel, mind maps)?

Видимо где удобнее. *мысленно представляет как тестировщики будут тестировать апликуху по UML-диаграмме*

И зря вы пишете с таким сарказмом. Неуместным. Я тестировал. И мы использовали UML тул как ... ну скажем как карту продукта для тестирования. Правда потом отказались, но на то был ряд причин, могли бы и не отказываться.
А 1.5 года назад на SQA Days 5 был даже доклад на эту тему: http://www.slideshar...CORP/ss-1367049

5. Кто должен проходить пользовательские сценарии?

Кто угодно, особых навыков это не требует, точнее всё зависит от специфики приложения.

Взаимоисключающие утверждения особых навыков это не требует и точнее всё зависит от специфики приложения. Вероятно вы имели в виду, что зависит от сценариев?

7. Каково пересечение exploratory testing(о котором говорил Майкл Болтон) и use cases?

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

Никаких коварных деталей в ET (о котором говорил Болтон) нет. Никто не мешает писать "коварные" тест-кейсы. Почитайте того же Болтона, что он пишет об ЕТ.

P.P.S. Честно говоря раньше считал, что при разработки ПО происходят такие переходы: идея > use cases > user scenarios > test cases. Причем между user scenarios и test cases и происходит тест-дизайн, который есть фундамент всего тестирования, в котором суть тестирования.

А вот тут, на мой взгляд, есть очень существенный изъян в формуле идея > use cases > user scenarios > test cases.
Непонятно, что есть тут идея, но это мелочи.
Вариант использования (use case) - то, что программа допускает чтобы с ней делали.
Пользовательский сценарий (user scenario) - то, как пользователь (наиболее вероятно) будет использовать программу.
Для составления тест-кейсов (внезависимости от того, что вы понимаете под этим названием) пользовательские сценарии могут быть не нужны. И даже наоборот - они могут быть вредны, ибо мешают тестировщику думать шире, чем там описано.

Посетив sqa days 8, одной из центральных мыслей которых (на мой взгляд) был переход от написания тест планов и прохождения тестовых случаев к выполнению пользовательских сценариев, решили внедрить в рамках нашей компании user scenarios.

Анна, было бы хорошо, если бы Вы указали более точно, в каких именно выступлениях на конференции прозвучала такая идея.
Либо изложили чётко своё понимание того, что такое "пользовательские сценарии", которые Вы "решили внедрить".

Потому что я вижу, что обсуждение идёт бурное, но разговор получается как у слепого с глухим :)
В ход пошли термины "пользователькие сценарии", "user scenarios", "use cases", "user stories", и я подозреваю, что понимание этих терминов участниками обсуждения весьма сильно различается.

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

разговор получается как у слепого с глухим :)
В ход пошли термины "пользователькие сценарии", "user scenarios", "use cases", "user stories", и я подозреваю, что понимание этих терминов участниками обсуждения весьма сильно различается.

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

Поддерживаю, корректная терминология, term definition снимет все вопросы и тема исчерпает себя.

Посетив sqa days 8, одной из центральных мыслей которых (на мой взгляд) был переход от написания тест планов и прохождения тестовых случаев к выполнению пользовательских сценариев, решили внедрить в рамках нашей компании user scenarios.
Честно говоря у конференции не было центральной мысли - кто какие доклады слушал, тот такие выводы и сделал.
И как тут уже отметили, вы спутали в одну кучу use cases и user scenarios. Разницу, как я ее понимаю, я описал в предыдущем коменте - вы бы уточнили о чем речь.

1. На какой стадии разработки ПО пишутся пользовательские сценарии
Во-время, уточнения требований и создания основной тестовой документации ?
Неплохо еще узнать КЕМ? они пишутся. У меня нет ответа на ваши вопросы, т.к. не знаю ни какие продукты вы делаете ни как вы их делаете.

2. Какова их эффективность в сравнении с тестовыми случаями?
Судя по всему, мелкие дефекты так и останутся на ПМЖ в конечном продукте, однако предполагается выиграш во времени, потраченном на тестирование. Оправдано ли это?
Любые дефекты останутся в ПО, пока их не починит программист. У тех, что найдены - вероятность быть починенными выше. В целом вопрос не понятен: в чем эффективность тест-кейсов? Почему мелкие дефекты останутся на ПМЖ? Откуда взялся выйгрыш во времени? И значит ли выйгрыш во времени то, что программа будет передана клиенту раньше, если вы не будете тестировать по тест-кейсам?

3. Предполагает ли использование юзер кейсов полного отказа от привычной тестовой документации (тест плана, чек листа, тестовых примеров)?
Отнюдь. Я не знаю, что вы скрываете за понятиями тест-план и тестовый пример. Но да это не важно. Что use cases, что user scenarios - это входные данные для тестировщиков, которые они могут использовать для тестирования. Они могут быть прекрасным дополнением к чему угодно и не подразумевают отказа от чего-либо. Например тест план, в моем понимании, описывает ЧТО и КОГДА будет тестироваться. Но не КАК и не на основе каких входных данных. Так зачем отказываться от плана тестирования (стратегический документ) в пользу неважно чего, являющегося тактическим документом.

4. Оптимальная структура и где/как хранить? (uml диаграммы, MS Excel, mind maps)?
Ответ банален: как вам нравится и как вам удобно - так и храните! Именно вам и именно на этом месте работы. Не слушайте никого, "у кого так или сяк лучше". Можете попробовать как у других, но я бы вообще призывал не руководствоваться одним закостенелым форматом. Где-то достаточно несколько описанных шагов в простом txt фале, а где-то StateChart диаграмма будет лучшим выбором.

5. Кто должен проходить пользовательские сценарии?
Непосредственно ответственный qa специалист или возможно приглашать другого qa, который с "незамыленным взглядом" сможет увидеть то, что человеку знающему ПО в деталях уже неподвластно?
Еще один непонятный вопрос. Если конечно у вас есть большой выбор "незамыленных" тестеров, которым нечего делать и они готовы взять и качественно протестировать неважно что в любой момент... Мне не понять, почему источник, которым руководствуется человек проводящий тестирование, настолько важен, что может потребовать привлечения сторонних людей, ранее незадействованных в тестировании этого проекта?

6.На каком этапе должны выполняться? (регрессионное тестирование или тестирование новой функциональности)
Не имеет значения. Имхо. Но есть виды тестирования когда не use case не user scenario не нужны. Например статический анализ.

7. Каково пересечение exploratory testing(о котором говорил Майкл Болтон) и use cases?
А что общего между апельсинами и холодильником? Так же как вы можете поместить апельсин в холодильник, так и здесь - вы можете положить ваше знание об use cases в основу ЕТ. Если речь о user scenarios, то как я говорил, они иногда могут сузить рамки сознания. Но это не значит, что ЕТ заставляет тестировщика делать все что угодно, за исключением того, что наиболее вероятно будет делать пользователь.

anka_ua
Я правильно понял, что вы не в Москве? А то было бы интересно обсудить вашу ситуацию на встрече клуба тестеров.

И зря вы пишете с таким сарказмом. Неуместным. Я тестировал. И мы использовали UML тул как ... ну скажем как карту продукта для тестирования. Правда потом отказались, но на то был ряд причин, могли бы и не отказываться.
А 1.5 года назад на SQA Days 5 был даже доклад на эту тему: http://www.slideshar...CORP/ss-1367049

Спасибо за ссылку :) Вы тестировали по UML диаграммам представляющим use case? А как разбирались с ветвлением? Бо контролировать какие пути прошел, а какие ещё нет - нетривиальная задача. А как насчёт деталей? Например datasets или просто граничные значения, прямо в диаграмме всё это хранилось? А каковы были размеры этой диаграммы?
Сарказм был вот по какому поводу: топикстартер собирается перейти от тест-кейсов и чек-листов к usecase\user scenarios. То есть получается практически всё будет тестировать через оные, то есть всё будет тестироваться через UML диаграммы, если в них предполагается хранить usecase.

Взаимоисключающие утверждения особых навыков это не требует и точнее всё зависит от специфики приложения. Вероятно вы имели в виду, что зависит от сценариев?

1. Что бы просто пройтись по сценарию, который уже сделан, да ещё и в деталях особых навыков не требуется.
2. НО! Если программа сама по себе довольно сложна и требует дополнительных знаний, то естественно нужен человек, который этими знаниями или навыками обладает.
Пример: нужно протестировать новый мод к игре Quake III, в одном из user scenario встречает пункт "совершить распрыжку длительностью в 5 сек". Неосведомлённый человек даже не в курсе, что такое "распрыжка", а о том, что бы её повторить и речи нет.

Никаких коварных деталей в ET (о котором говорил Болтон) нет. Никто не мешает писать "коварные" тест-кейсы. Почитайте того же Болтона, что он пишет об ЕТ.

Ок, почитаю, я излагал своё мнение, а не мнение Болтона.

А вот тут, на мой взгляд, есть очень существенный изъян в формуле идея > use cases > user scenarios > test cases.
Непонятно, что есть тут идея, но это мелочи.
Вариант использования (use case) - то, что программа допускает чтобы с ней делали.
Пользовательский сценарий (user scenario) - то, как пользователь (наиболее вероятно) будет использовать программу.
Для составления тест-кейсов (внезависимости от того, что вы понимаете под этим названием) пользовательские сценарии могут быть не нужны. И даже наоборот - они могут быть вредны, ибо мешают тестировщику думать шире, чем там описано.]

Идея, требования, задумка, пожелания и т.д. В общем отправной пункт, тут этот смысл подразумевался.
Насчёт "могут быть вредны" полностью согласен, потому и не использую их во время тест-дизайна. Я привёл типичное применение user scenarios в рамках тестирования, поправьте меня, если это не так.

И зря вы пишете с таким сарказмом. Неуместным. Я тестировал. И мы использовали UML тул как ... ну скажем как карту продукта для тестирования. Правда потом отказались, но на то был ряд причин, могли бы и не отказываться.
А 1.5 года назад на SQA Days 5 был даже доклад на эту тему: http://www.slideshar...CORP/ss-1367049

Спасибо за ссылку :) Вы тестировали по UML диаграммам представляющим use case? А как разбирались с ветвлением? Бо контролировать какие пути прошел, а какие ещё нет - нетривиальная задача. А как насчёт деталей? Например datasets или просто граничные значения, прямо в диаграмме всё это хранилось? А каковы были размеры этой диаграммы?
Сарказм был вот по какому поводу: топикстартер собирается перейти от тест-кейсов и чек-листов к usecase\user scenarios. То есть получается практически всё будет тестировать через оные, то есть всё будет тестироваться через UML диаграммы, если в них предполагается хранить usecase.

Следовало бы, конечно, сказать, что компания разрабатывала UML-tool и хоть ее Борланд и похоронил под своии останками, но тул считаю до сих пор лучший для проектирования UML диаграмм, не говоря уж о том, что там не только редактор диаграмм был. Я о Together Control Center.

Диаграммы у нас были разные, кастомные, но на основе существующих. Одна была картой продукта, другая картой тестовых сущностей (тех же чеклистов и прочего). Естесственно, они были между собой связаны кросс-линками. Размер был большой ибо продукт рос и развивался. Можно было бы разделить на несколько диаграмм по каким-либо признакам логическим, но мы к тому времени перебрались на другой проект и посчитали нужным использовать его для наших тестовых нужд и от идеи диаграмм отказались. Зато появились XML, WebDav и тд.
Диаграммы не были use case диаграммами продукта и не были диаграммами последовательности действий пользователей. Составлялись нами.

Взаимоисключающие утверждения особых навыков это не требует и точнее всё зависит от специфики приложения. Вероятно вы имели в виду, что зависит от сценариев?

1. Что бы просто пройтись по сценарию, который уже сделан, да ещё и в деталях особых навыков не требуется.
2. НО! Если программа сама по себе довольно сложна и требует дополнительных знаний, то естественно нужен человек, который этими знаниями или навыками обладает.
Пример: нужно протестировать новый мод к игре Quake III, в одном из user scenario встречает пункт "совершить распрыжку длительностью в 5 сек". Неосведомлённый человек даже не в курсе, что такое "распрыжка", а о том, что бы её повторить и речи нет.

Я почему-то тоже хотел привести пример из какой-нить игры, когда писал про сценарии. Ну да, я вот например не знаю что такое "распрыжка" и в Quake III никогда не играл вообще. И скорее всего этот сценарий не для меня. А вот сценарий установки игры на компьютер - вполне для меня. Поэтому, я и пришел к мнению, что зависит от сценария.

LeshaL, "Например тест план, в моем понимании, описывает ЧТО и КОГДА будет тестироваться. Но не КАК и не на основе каких входных данных. "..
В рамках нашей компании мы пользуемся следующим определением
Тест план (Test plan)
Сущность с древообразной структурой, содержащая все тесты проекта, сгруппированные по определённому принципу (как правило в соответствии с модулями программы).
То, о чем говорите Вы - Мастер Тест План (на универсальность не претендуем, этим глоссарием пользуемся в нашей компании).

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

Так как складывается впечатление, что "разговор получается как у слепого с глухим :)
В ход пошли термины "пользователькие сценарии", "user scenarios", "use cases", "user stories", и я подозреваю, что понимание этих терминов участниками обсуждения весьма сильно различается.

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

Может давайте попробуем найти валидные определения для этих терминов ?