Списки и Сценарии

Списки и Сценарии (здесь и далее по тексту -- Лектио) -- это часть урока Суть Проверки Работ. В Брацкой Школе, уроки делятся на так называемые лектио, каждое из которых состоит из микролекции и одного или нескольких заключительных вопросов. Урок, в свою очередь, относится к практическому семинару Выбор Профессии.

Материалы

Предшественник этого Лектио -- План или Планирование.

Текст

Списки и Сценарии

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

В тестировании цифровых систем, пошаговые инструкции проведения тестов традиционно называются "сценариями" (test case). Сценарные тесты обыкновенно имитируют действия конечного пользователя и пишутся на основе пользовательских историй (user story). Пользовательские истории -- это один из форматов требований. Стандартный формат состоит из трёх секций:

1. Имея права (описывается пользователь или системная роль того, кто получит выгоду от функционала),
2. я хочу (описывается желаемый функционал),
3. чтобы (описывается выгода функционала.

Narrative

   A short introductory section with the following structure:

       As a: the person or role who will benefit from the feature;
       I want: the feature;
       so that: the benefit or value of the feature.

Acceptance criteria

   A description of each specific scenario of the narrative with the following structure:

       Given: the initial context at the beginning of the scenario, in one or more clauses;
       When: the event that triggers the scenario;
       Then: the expected outcome, in one or more clauses.

AC можно записывать в разных форматах. Есть два наиболее распространенных варианта, и третий вариант - разработать собственный формат:

   ориентированный на сценарий (Учитывая / Когда / Тогда)
   ориентированный на правила (контрольный список)
   специальные форматы

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

Сценарийно-ориентированный формат записи AC известен как тип Given / When / Then (GWT).

   Учитывая некоторые предварительные условия
   Когда я делаю какое-то действие
   Тогда я жду результата

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

Каждый критерий приемки, написанный в этом формате, содержит следующие утверждения:

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

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

Поставьте задачу и ощутите результат.

Давайте посмотрим на несколько примеров.

Пример 1

История пользователя: Как пользователь, я хочу иметь возможность восстановить пароль своей учетной записи, чтобы иметь доступ к своей учетной записи в случае, если я забыл пароль.

Сценарий: Забыли пароль

Дано: пользователь перешел на страницу входа

Когда: пользователь выбрал опцию забытого пароля

И: Ввели действующий адрес электронной почты, чтобы получить ссылку для восстановления пароля.

Затем: Система отправила ссылку на введенный адрес электронной почты.

Дано: пользователь получил ссылку по электронной почте

Когда: пользователь перешел по ссылке, полученной в электронном письме.

Затем: Система позволяет пользователю установить новый пароль.

Пример 2

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

Критерии приемки 1:

При условии, что счет кредитоспособен

И: карта действительна

И: в диспенсере есть наличные

Когда: клиент запрашивает наличные

Затем: убедитесь, что счет списан

И: обеспечить выдачу наличных

И: убедитесь, что карта возвращена

Критерии приемки 2:

Учитывая: что на счету овердрафт

И: карта действительна

Когда: клиент запрашивает наличные

Затем: убедитесь, что отображается сообщение об отказе

И: убедитесь, что наличные не выдаются Формат критериев приемлемости, ориентированный на правила

В некоторых случаях сложно вписать критерии приемки в структуру Given / When / Then. Например, GWT вряд ли пригодится в следующих случаях:

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

Вы можете решить эти случаи с помощью ориентированного на правила формата AC.

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

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

пример

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

Основные критерии приемки интерфейса поиска

   Поле поиска находится на верхней панели
   Поиск начинается, когда пользователь нажимает «Поиск».
   Поле содержит заполнитель с текстом серого цвета: «Куда вы собираетесь?»
   Заполнитель исчезает, когда пользователь начинает печатать
   Поиск выполняется, если пользователь вводит город, название отеля, улицу или все вместе
   Поиск ведется на английском, французском, немецком и украинском языках.
   Пользователь не может набрать более 200 символов.
   Поиск не поддерживает специальные символы (символы). Если пользователь ввел специальный символ, покажите предупреждающее сообщение: «Поисковый ввод не может содержать специальные символы».

Другие форматы

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

Термины

Функциональное Тестирование, Нефункциональное Тестирование, Требования, Регрессионное Тестирование, Прогрессионное Тесирование

Вопрос(ы)

Какое из приведенных ниже утверждений является правильным: --

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

Следующее лектио -- Тестировка Изделий