В этой статье я собираюсь предложить использовать метод интерактивной раскадровки для анализа и разработки пользовательских историй.
Как вы пишете тестовые сценарии для автоматизированных приемочных испытаний? В гибкой разработке заказчик предоставляет уровень истории пользователя и критерия приемлемости, и мы начинаем анализировать историю и создавать тестовые сценарии.
Вам также может понравиться: Лучшие практики для успеха с историями пользователей
Критерии приемлемости на основе сценария, описанные в формате «Предоставлено, когда», уже выглядят как тестовый сценарий Следовательно, мы можем неправильно прочитать его исполняемый файл, который можно преобразовать в исполняемый тестовый скрипт. На самом деле, в данный момент клиент только что получил то, что ему нужно, исходя из деловых ценностей. Следовательно, они только рассматривали, нужна ли история для их бизнеса по сравнению с альтернативными вариантами.
С другой стороны, ожидается, что тестовые сценарии будут детализированы на уровне кодирования, который на каждом этапе представляет пользовательскую операцию или поведение системы. На этом этапе мы анализируем историю и классы дизайна и экраны с помощью логического мышления, который отличается от подхода для определения пользовательской истории и критериев приемлемости.
В этой статье предлагается использовать метод интерактивной раскадровки для анализа и разработки историй. И я представляю «storydoc» как инструмент для раскадровки, чтобы испытать поток экрана и генерировать тестовые сценарии и связанные документы из историй. Ниже показаны раскадровка HTML и документ storydoc, сгенерированный из 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
Given I open the website
2
When I search by model name
3
Then the system shows the product information
Критерии приемлемости уже выглядят как исполняемый тестовый сценарий, но это не так. Я создал тестовые сценарии, как показано ниже, на основе данной истории:
С
xxxxxxxxxx
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
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
Exception Scenario:
14
Given I open the website
15
When I search with an empty keyword
16
Then the system shows an error message
В реальном мире мы могли бы найти больше сценариев, но я упростил только типичные альтернативные и исключительные случаи в дополнение к основному сценарию, чтобы упростить пример кода.
Различия между критериями приемки и сценариями испытаний
Чтобы узнать, что необходимо сделать в процессе анализа и проектирования, полезно посмотреть, что было изменено и добавлено в примерные сценарии тестирования по сравнению с заданными критериями приемлемости.
Сначала мы видим, что в тестовые сценарии добавляются два сценария (альтернативный и исключительный). Альтернативный сценарий показывает другой курс, что система находит несколько продуктов. Сценарий исключения показывает курс ошибки, когда пользователь вводит недопустимое ключевое слово.
Далее мы видим небольшие отличия даже в основном сценарии. Критерии принятия говорят: «Когда я ищу по названию модели», а сценарий тестирования - «Когда я ввожу точное имя модели». Это вызвано альтернативным сценарием, когда система возвращает несколько продуктов. Чтобы отличиться от этого, мы должны четко сказать «точное название модели». Кроме того, когда мы пишем тестовый сценарий, мы уже разъяснили ход экрана и дизайн.
Мы знаем, что на странице есть поле ввода и кнопка поиска. Вот почему я изменил использовать выражение «enter», которое тесно связано с действиями пользователя, а не «search». В целом, мы часто видим больше выражений, связанных с элементами HTML, таких как «введите ключевое слово», «нажмите кнопку» в тестовых сценариях, а не критерии принятия по причине. Вот что добавлено в тестовые сценарии:
- Изменено использование выражений на основе пользовательского интерфейса.
- Добавлены альтернативные сценарии.
- Добавлены сценарии исключений (курсы ошибок).
Из вышеприведенных изменений видно, что в процессе анализа и проектирования будут выполнены следующие действия:
- Уточните поток экрана и элементы HTML на каждом экране.
- Найти возможные альтернативные курсы.
Раскадровка
Теперь мы знаем, что нужно сделать для реализации истории, а именно: найти экраны и альтернативные сценарии. Хотя вы можете рисовать изображения на экране с помощью программного обеспечения для презентаций, такого как PowerPoint, я предлагаю использовать инструмент storydoc для анализа историй.
Вам просто нужно создать HTML-файлы и определить экраны и действия с помощью тегов <screen> и <action>. Страница формы поиска может быть представлена как показано ниже:
HTML
xxxxxxxxxx
1
<screen>
2
<input>
3
<button>Search</button>
4
</screen>
5
<action name="I search by model name"
7
link="ProductDetail.html"/>
В раскадровке экран должен быть максимально простым, который называется «концептуальный экран». Концептуальный экран представлен только HTML-тегами, относящимися к действию. На этой странице пользователю нужны <input> и <button> для ввода названия модели и отправки. Вот почему в теге <screen> описаны только два тега.
После того, как вы создали HTML, вы можете испытать поток экрана с вашим браузером. Это называется раскадровка. С помощью приведенного ниже URL вы можете раскадрировать историю, определенную пользователем:
https://story-doc.github.io/SearchInitialStoryboard/index.html
Также по ссылке ниже показаны исходные коды HTML:
https://github.com/story-doc/js/tree/master/samples/SearchInitialStoryboard
Помимо раскадровки инструмент storydoc может генерировать тестовые сценарии и связанные документы из HTML. Запустите команду ниже из командной строки:
С
xxxxxxxxxx
1
C:> java -jar storydoc.jar index.html
Он генерирует storydoc.html в той же папке. HTML можно увидеть по URL ниже:
https://story-doc.github.io/SearchInitialStoryboard/storydoc.html
Как вы можете видеть, HTML-файл storydoc содержит следующие разделы:
- Диаграмма вариантов использования пользовательской истории.
- Описание пользовательской истории (основной сценарий).
- Карта навигации (Государственная диаграмма).
- Тестовые сценарии.
С
xxxxxxxxxx
1
Story: [US01] Product Search
2
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
C:> java -jar storydoc.jar index.html
Пересмотренный HTML-код можно увидеть по URL-адресу ниже:
https://story-doc.github.io/SearchStoryboard/storydoc.html
В документе вы увидите обновленное описание пользовательской истории, навигационную карту и тестовые сценарии с новыми действиями и экранами. Например, альтернативные сценарии и сценарии исключений были добавлены в навигационную карту, как показано ниже:
Вы также видите альтернативные и исключительные сценарии в сгенерированных тестовых сценариях:
С
xxxxxxxxxx
1
Story: [US01] Product Search
2
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
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
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
Это то, что мы хотели получить в качестве цели анализа и проектирования из истории клиента.
Заключение
Пользовательские истории на уровне функций определяются с учетом основных требований. Следовательно, пользовательский интерфейс и альтернативные курсы еще не рассматриваются. Системные аналитики и разработчики должны подробно анализировать истории и дизайн, используя подход, отличный от определяющих историй.
Раскадровка - рекомендуемая техника для анализа и разработки историй. Испытывая поток экрана, вы легко найдете более альтернативные сценарии. Кроме того, с помощью инструмента ваши изменения в документации могут быть сведены к минимуму, когда вы дорабатываете истории.
Дальнейшее чтение
Что такое пользовательские истории и кто должен их писать?