Реализация пользовательской истории с раскадровкой


Узнайте больше о том, как правильно использовать раскадровки!

В этой статье я собираюсь предложить использовать метод интерактивной раскадровки для анализа и разработки пользовательских историй.

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

Вам также может понравиться: Лучшие практики для успеха с историями пользователей

пользовательская история

Критерии приемлемости на основе сценария, которые описаны в формате «Предоставлено, когда», уже выглядят как тестовый сценарий. Следовательно, мы можем неправильно прочитать его исполняемый файл, который можно преобразовать в исполняемый тестовый скрипт. На самом деле, в данный момент клиент только что получил то, что ему нужно, исходя из бизнес-ценностей. Следовательно, они только рассмотрели, нужна ли история для их бизнеса по сравнению с альтернативными вариантами.

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

сбор требований и анализ и дизайн

В этой статье предлагается использовать метод интерактивной раскадровки для анализа и разработки историй. И я представляю «storydoc» как инструмент для раскадровки, чтобы испытать поток экрана и генерировать тестовые сценарии и связанные документы из историй. Ниже показан HTML-код раскадровки и документ storydoc, сгенерированный из HTML:

раскадровка HTML

История поиска товара

В этой статье я буду использовать историю поиска продукта в качестве примера пользовательской истории. История определяет функцию, по которой пользователь ищет продукт по названию модели. В форме поиска пользователь вводит название модели и нажимает кнопку «Поиск». Затем система открывает страницу сведений о продукте с отображением информации о продукте.

Вышеупомянутая особенность может быть зафиксирована как следующая история и критерии принятия:

С

Икс

1

As a website user,

2

I want to search products by a model name

3

so that I can find the information on the product.

С

xxxxxxxxxx

1

1

Given I open the website

2

When I search by model name

3

Then the system shows the product information

Критерии приемлемости уже выглядят как исполняемый тестовый сценарий, но это не так. Я создал тестовые сценарии, как показано ниже, на основе данной истории:

С

xxxxxxxxxx

1

16

1

Main Scenario:

2

       Given I open the website

3

       When I enter an exact model name

4

       Then the system shows the product information

5


6

Alternative Scenario:

7

       Given I open the website

8

       When I enter a partial model name

9

       Then the system shows a list of products

10

       When I select a product

11

       Then the system shows the product information

12


13

Exception Scenario:

14

       Given I open the website

15

       When I search with an empty keyword

16

       Then the system shows an error message

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

Различия между критериями приемки и сценариями испытаний

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

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

Далее мы видим небольшие различия даже в основном сценарии. Критерии принятия говорят: «Когда я ищу по названию модели», а сценарий тестирования – «Когда я ввожу точное имя модели». Это вызвано альтернативным сценарием, когда система возвращает несколько продуктов. Чтобы отличиться от этого, мы должны четко сказать «точное название модели». Кроме того, когда мы пишем тестовый сценарий, мы уже разъяснили ход экрана и дизайн.

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

  • Изменено использование выражений на основе пользовательского интерфейса.
  • Добавлены альтернативные сценарии.
  • Добавлены сценарии исключений (курсы ошибок).

Из вышеприведенных изменений видно, что в процессе анализа и проектирования будут выполнены следующие действия:

  • Уточнить экранный поток и элементы HTML на каждом экране.
  • Найти возможные альтернативные курсы.

Раскадровка

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

Вам просто нужно создать HTML-файлы и определить экраны и действия с помощью и теги. Страница формы поиска может быть представлена ​​как показано ниже:

HTML

<div class = "codeMirror-code – wrapper" data-code = '


'data-lang = "text / html”>

xxxxxxxxxx

1

1

<screen>

2

  <input> 

3

  <button>Searchbutton>

4

screen>

5


6

<action name="I search by model name"

7

        link="ProductDetail.html"/>

В раскадровке экран должен быть как можно более простым, который называется «концептуальный экран». Концептуальный экран представлен только HTML-тегами, относящимися к действию. На этой странице пользователю нужен и

Он генерирует storydoc.html в той же папке. HTML можно увидеть по URL ниже:

https://story-doc.github.io/SearchInitialStoryboard/storydoc.html

Как вы можете видеть, HTML-файл storydoc содержит следующие разделы:

  • Диаграмма вариантов использования пользовательской истории.
  • Описание пользовательской истории (основной сценарий).
  • Карта навигации (Государственная диаграмма).
  • Тестовые сценарии.

С

xxxxxxxxxx

1

1

Story: (US01) Product Search

2


3

Main Scenario:

4

       Given I open the website

5

  M-1. When I search by model name

6

       Then the system shows the product information

Хотя в приведенном выше тестовом сценарии добавлены некоторые дополнительные строки и метки, в настоящий момент они в основном соответствуют критериям приемлемости.

Найти альтернативные и исключительные сценарии

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

Для вновь найденных действий вы должны определить как альтернативные (или исключительные) сценарии, чтобы ваше приложение могло обрабатывать все возможные курсы. Мы нашли два новых действия в форме поиска:

  • Я ввожу частичное название модели.
  • Я ищу с пустым ключевым словом.

Кроме того, чтобы выразить отличие от случая с частичным названием модели, я изменил исходное имя действия «Я ищу по названию модели» на

  • Я ввожу точное название модели.

Теперь три действия определены на странице формы поиска, как показано ниже:

Рисунок выше также содержит два новых экрана:

  • Страница результатов поиска для отображения списка продуктов и
  • Страница ошибки для отображения сообщения об ошибке

Я пересмотрел раскадровку с новыми действиями и экранами:

https://story-doc.github.io/SearchStoryboard/index.html

Также по ссылке ниже показаны исходные коды HTML:

https://github.com/story-doc/js/tree/master/samples/SearchStoryboard

Снова запустите инструмент storydoc, чтобы заново сгенерировать HTML HTML storydoc:

С

xxxxxxxxxx

1

1

C:> java -jar storydoc.jar index.html

Пересмотренный HTML-код можно увидеть по URL-адресу ниже:

https://story-doc.github.io/SearchStoryboard/storydoc.html

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

Вы также видите альтернативные и исключительные сценарии в сгенерированных тестовых сценариях:

С

xxxxxxxxxx

1

20

1

Story: (US01) Product Search

2


3

Main Scenario:

4

       Given I open the website

5

  M-1. When I enter an exact model name

6

       Then the system shows the product information

7


8

Alternative Scenario 1:

9

       Given I open the website

10

  A1-1. When I enter a partial model name

11

       Then the system shows a list of products

12

  A1-2. When I select a product

13

       Then the system shows the product information

14


15

Exception Scenario 1:

16

       Given I open the website

17

  E1-1. When I search with an empty keyword

18

       Then the system shows an error message

19

  E1-2. When I go back to the search form

20

 #E1-3. Go back to M-1

Это то, что мы хотели получить в качестве цели анализа и проектирования из истории клиента.

Вывод

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

Раскадровка – рекомендуемая техника для анализа и дизайна историй. Испытывая поток экрана, вы легко найдете больше альтернативных сценариев. Кроме того, с помощью инструмента ваши изменения в документации могут быть сведены к минимуму, когда вы дорабатываете истории.

Дальнейшее чтение

Что такое пользовательские истории и кто должен их писать?

Магия маленьких пользовательских историй

Каков правильный размер для пользовательской истории?