2016-03-25 3 views
2

Я только начал использовать SpecFlow. Это инструмент для создания бизнес-понятных сценариев тестирования в стиле BDD. В основном он преобразует истории пользователей в модульные тесты.Насколько точны истории пользователей?

Я начинаю рассказы пользователей и интересуюсь его длиной. Является ли это хорошей практикой для создания очень точных историй пользователей? Вот пример:

In order to get help 
As a StackOverflow user 
I want to add post 
    with name and content 
    and add tags to it 
    and format the content 
    and the information about my post edits to be stored in the system 
    and some more things like that 

Должен ли я сохранять свои истории компактными? Если да - как я могу управлять подробными требованиями? Или, может быть, это ничего плохого в очень длинном и точном разделе I want в истории пользователя?

ответ

2

Если бы вы могли развить целую систему за пару недель и сделать это надежно, никто бы никогда не беспокоился о «историях пользователей». Они просто заставляют вас развивать систему, сидеть с вами и настраивать ее по мере ее появления.

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

Вот как я отношусь список вроде этого:

In order to get help 
As a StackOverflow user 
I want to add post 
    with name and content 
    and add tags to it 
    and format the content 
    and the information about my post edits to be stored in the system 

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

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

In order to award great content with appropriate recognition, 
as Stack Exchange, 
we want people's usernames to appear with their content. 

Конечно, пользователи хотят это тоже, но они не платят за нее (кроме как через рекламу). Так что работайте над тем, кто платит за это и почему.

In order to get more page impressions and keep people on the site for longer, 
as Stack Exchange, 
we want users to be able to find similar content really easily. 

Hm. Это немного сложнее. Смотрите, пользователь действительно не хочу, чтобы провести всю свою жизнь на StackOverflow. Просто если мы дадим им соответствующее признание и облегчим для других находить их контент, они могут это сделать. Не все «истории пользователей» действительно приносят пользу пользователям. Узнайте, кто платит за них и почему; то вы найдете своего реального заинтересованного лица. Также хорошо, что история может принести пользу более чем одному участнику, и легко понять, как перефразировать это с точки зрения пользователя.

format the content 

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

In order to avoid retyping my request every time 
As the user 
I want the information about my post edits to be stored in the system 

Хорошо, да, это было бы хорошо.

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

Если вы можете заменить «Я хочу ...» на «Я хочу быть в состоянии ...», вполне вероятно, что у вас там нет истории, но есть полная возможность . Большинство людей делают это инстинктивно. Многие люди называют эти «эпопеи».

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

Прежде всего, обратите внимание на ваши требования. Если есть что-то, о чем вы можете сказать: «Я хочу быть в состоянии ...» или «Кто-то хочет иметь возможность ...», тогда вы знаете, что это совершенно другая возможность, а это означает, что это будет отдельная история ,

Затем вы можете разделить их на контексты. Таким образом, вы могли бы иметь такие истории:

In order to free up our junior traders 
We want them to be able to generate contracts automatically 
So that they can help with the trade analysis instead of typing. 

Если это кажется слишком большой для цикла обратной связи (как правило, две недели спринта), вы можете разделить его дальше.

In order to free up our junior traders 
We want them to be able to generate *orange juice* contracts automatically 
So that they can help with the trade analysis instead of typing. 

Здесь мы сосредотачиваемся на возможность торговать апельсиновый сок, но в равной степени мы могли бы сузить историю вплоть до FTSE, или США, или Нью-Йоркской фондовой бирже. Именно так мы фокусируем усилия на том, что поставит: защита доходов, снижение затрат или повышение стоимости.

Чтобы включить их в сценарии, я спрашиваю: «Можете ли вы дать мне пример торговли OJ на фондовой бирже NY?» Если я увижу что-то общее, что я не понимаю, я спрашиваю: «Можете ли вы привести мне пример?»

Этот пример становится моим первым сценарием. Контекст (данный) определяется границами сюжета. Событие (когда) - это производительность. Результатом (тогда) является результирующее значение.

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

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

Ваши изменения: также историй.

2

Я всегда советую следующее:

Попробуйте резки ваши истории в сценариях. Чем больше сценариев, тем лучше вы можете определить, когда что-то идет не так. Дайте всем сценариям субъективные имена.

Теперь, например, ваш тест. Если шаг 1 идет не так, все ваши другие шаги не будут проверяться.

Также используйте теги Given, When и Then, чтобы легко прочитать ваши сценарии.

Так вместо этого, вы могли бы сказать:

Feature: As a StackOverflow user I want to add a post 

Scenario: I go to stackoverflow website 
Given I open the browser 
And I go to the stackoverflow website 
When I click New Post 
Then a new page appears to insert my data 

Scenario: I fill in data for my post - Name and content 
Given I do not modify this page 
When I fill in name 
And I fill in content 
Then I add tags to it 
And I format the content 

Scenario: Check if information about post edits are stored in the system 
Given... 

Думаю, вы получите, где это происходит :-)

+0

Хорошо, а как насчет точных определений, например, для проверки? Если я скажу, что форма из трех полей ввода, первые два требуются, сначала 50 символов макс, второй 20 и третий 100 - должна ли я иметь всю эту информацию, указанную в сценариях? – Landeeyo

+1

Да, я бы посоветовал вам это. Вы собираетесь использовать Selenium с SpecFlow? Сделайте свои сценарии максимально подробными. У меня когда-то был сценарий (перевод с голландского), в котором говорилось: Сценарий: Пользователь заполняет значения в понедельник с 08:00 до 10:00, во вторник с 08:00 до 12:00, с 14:00 до 18:00 и в воскресенье 09: 00 до 12:00. – Anand

+0

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

1

Там нет правильного уровня детализации историй пользователей, так как пользовательские истории уменьшаться в размерах (сфера охвата) и детально (с течением времени). Этот слайд показывает хорошую визуализацию от Gojko Adzic об этом: http://www.slideshare.net/chassa/2015-0214agile-reqend2endcomplete/6

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

Обычно вы начинаете с сценария основного аспекта (счастливый путь), а затем пытаетесь «разбить модель», придумывая новые примеры (случаи), которые исследуют другие аспекты истории. Вы начинаете с вопроса: «Как бы вы опробовали историю, когда она была реализована?» («Счастливый путь») и «Что должно произойти, если ...?», Чтобы собрать потенциальные сценарии для рассмотрения (возможно, определив некоторые из вопросов, которые должны быть из возможности для этой истории).

После этого вы пытаетесь ответить на эти вопросы (название сценария) и проиллюстрировать их конкретными примерами (сценарии). Этот слайд дает представление о «сломать модель»: http://www.slideshare.net/chassa/2015-0214agile-reqend2endcomplete/61

 Смежные вопросы

  • Нет связанных вопросов^_^