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

Прочитали Савина? Помните, что «баги — это несоответствие ТЗ»? А теперь окунитесь в реальность — полноценного технического задания (ТЗ) не существует. Это миф. Не получится прийти на работу, поставить аватарку в JIRA и сказать: «Тестировать буду только по ТЗ, пока отдыхаю». ТЗ не будет.

Если компания:

маленькая — ТЗ нет вообще, все в головах разработчиков;

большая — ТЗ есть и много, но актуально процентов на 15.

Хорошо, когда есть небольшая инфостильная документация, которую заботливо написал внятный трезвый аналитик. Но мы рассматриваем ситуацию, когда ее нет. Что делать? Писать!

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

Что делать? Общаться с носителями знаний и записывать результат. Да, самому. Нет, не надорветесь.

Хочешь ТЗ и волшебные замки? Построй их сам

Есть несколько вариантов записи требований:

— диаграмма состояний и переходов;

— варианты использования;

— любовные записки;

— ...

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

• вариант — основной позитивный тест;
• каждая альтернатива — негативный тест;
• каждый параметр — дополнительный позитивный тест.

Тестировщики выбирают варианты! Давайте посмотрим, как это делать.

1. Найдите пользователя и цель, опишите сценарий

Для кого сделан функционал? Системы не делают ради систем.

Мы хотим, чтобы пользователь:

— сделал заказ;

— заплатил налоги;

— посмотрел на котика;

— прочитал блог-пост;

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

Чтобы написать вариант, надо подумать о будущем пользователе. Зачем он к нам придет? Что будет делать и как?

Пример с магазином. Основной сценарий.

Цель пользователя магазина — увидеть ЕГО и купить :)

СИ01. Найти товар и сделать покупку

1. Юзер открывает список товаров и фильтрует по категории.
2. Система отображает товары выбранной категории.
3. Юзер видит интересный товар и переходит на его карточку.
4. Система отображает карточку товара, оценку покупателей и отзывы.
5. Юзер изучает товар и кладет его в корзину.
6. Система добавляет товар в корзину.
7. Юзер переходит в корзину и оформляет заказ.
8. Система сохраняет заказ, отправляет уведомление по email.

СИ01 → Сценарий использования № 1

2. Продумайте альтернативы

Альтернативные сценарии - это отклонения от основной ветки. Даже типовой установщик Windows “Нажми Далее-Далее-Далее-Профит!” позволяет свернуть с основного сценария. Пользователь на каждом шаге может передумать и нажать “Назад”, или вообще отменить установку.

Нас такие альтернативы мало интересуют, иначе их было бы слишком много. Пользователь

— передумал покупать юбку;

— платье тоже передумал покупать;

— отменил все на этапе фильтрации товаров;

— отменил все, находясь в корзине;

— открыл в соседней вкладке bash.org;

— пошел налить чай;

— наклонился погладить кота;

— обожрался вкусняшек;

Не забываем о системе и внешних условиях:

— Внутренний сбой программы на любом этапе.

— Компьютер сдох. Сценарий завершился.

— Кот уронил сладкий кофе на клавиатуру.

— Уборщица шваброй выдернула сервер из розетки.

— На сервер упал метеорит.

— …

Да, это все возможно, но описывать бессмысленно. Получаем километровый текст, который никто не читает. Нужно вычленить те альтернативы, которые не “П передумал и закрыл браузер”. Сбой системы имеет смысл только тогда, когда система умеет находить выход из такой ситуации без потери данных и это действительно важно описать и проверить.

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

1. Альтернатива ссылается на основной сценарий. То есть пункт "2а" означает, что это отклонение от пункта "2" основного сценария. Сам пункт 2 копипастить не надо.
2. В альтернативах всегда надо писать, чем они заканчиваются. Это "Завершение сценария" или "Переход к шагу 7". Помните школу и программы на Basic? IF … GOTO 2 (возвращаемся к шагу 2 и все повторяем)

Пример с магазином. Альтернативы.

1а. Юзер фильтрует список по несуществующей категории. Система выдает ошибку. Завершение сценария.

2а. Товаров не найдено. Вывод сообщения об ошибке. Завершение сценария.

2б. Товаров слишком много. Система выводит первые 100 и предлагает сузить поиск.

5а. Юзер возвращается к покупкам. Переход к шагу 1.

3. Выделите параметры

Параметры — это когда одну операцию можно выполнить разными способами, но сам вариант от этого не меняется.

Например, открыть файл в блокноте можно как?

— даблклик по файлу;

— «File — Open» в блокноте;

— горячими клавишами.

В основной ветке мы пишем абстрактно —"П инициирует открытие файла". Это дает тестировщику свободу выбора! Хочу - открою даблкликом, хочу - через меню "Открыть". Когда все пункты жестко указывают, что делать пользователь может только так и никак иначе — это не очень хорошо. Все детали выносим отдельно, в параметры. И не надо будет копипастить сценарий ради изменения одной детали.

Параметры выглядят так:

название: значение 1, значение 2, значение 3

Без привязки к конкретному пункту сценария.

Запомните:

Альтернатива — это когда  ВМЕСТО исходного события происходит другое.

А параметры — это когда В ОДНОМ И ТОМ ЖЕ событии есть несколько вариаций, как его совершить.

Таким образом, параметр в одно значение бесполезен:

Способ оформления заказа: кнопка «Оформить заказ».

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

Время хранения товара в резерве: 2 часа с момента добавления в корзину.

Время хранения файла в системе: 2 часа с момента обработки файла.

Пример с магазином. Параметры

Категории товаров: платья, джинсы, свитера.

Время хранения товара в резерве: 2 часа с момента добавления в корзину.

     

4. Соберите все вместе

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

Читать удобнее именно в формате:

— основной вариант;

— альтернативы со ссылками на него;

— возможные параметры и особенности реализации.

Вернемся к нашему примеру с магазином и все соберем. В ИТ любят использовать сокращения для действующего лица. Это удобно тем, что ты сразу видишь само действие и нет скачка по тексту, то «юзер» в 4 буквы, то длинная «система».

Я к такому написанию уже привыкла, поэтому соберу вариант вместе с ним.

СИ01. Найти товар и сделать покупку

Легенда

П — пользователь

С — система

Сценарий использования

1. П открывает список товаров и фильтрует по категории.
2. С отображает товары выбранной категории.
3. П видит интересный товар и переходит на его карточку.
4. С отображает карточку товара, оценку покупателей и отзывы.
5. П изучает товар и кладет его в корзину.
6. С добавляет товар в корзину.
7. П переходит в корзину и оформляет заказ.
8. С сохраняет заказ, отправляет уведомление по email.

Альтернативные варианты

1а. П фильтрует список по несуществующей категории. Система выдает ошибку. Завершение сценария.

2а. Товаров не найдено. Вывод сообщения об ошибке. Завершение сценария.

2б. Товаров слишком много. Система выводит первые 100 и предлагает сузить поиск.

5а. П возвращается к покупкам. Переход к шагу 1.

Параметры

Категории товаров: платья, джинсы, свитера.

Время хранения товара в резерве: 2 часа с момента добавления в корзину.

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

Коберн предлагает до самого варианта расписать:

— основное действующее лицо;

— область действия;

— уровень;

— участники и интересы;

— предусловие;

— минимальные гарантии успеха;

— максимальные гарантии успеха

— …

Вы уже уснули? Вот и я засыпаю. Это как шаблон тест-плана по RUP — вроде все правильно, но сто-о-о-о-олько текста. Который никто не читает.

Текст, кому ты нужен?

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

НЕТ (Оригинальный Коберн)

ДА (Инфостильный Коберн)

Вариант использования 1. Oткрытие текстового файла. Основное действующее лицо: пользователь приложения NotePad, желающий открыть файл Область действия: текстовый редактор (NotePad) Уровень: цель пользователя Участники и интересы: Пользователь - хочет открыть текстовый файл в выбранном приложении. Предусловие: программа NotePad у пользователя уже открыта. Минимальные гарантии: файл открылся в приложении NotePad Гарантия успеха: файл без ошибок открылся в приложении, все данные файла корректно отражены и имеют удобный для чтения и понимания вид. Триггер:  пользователю необходимо увидеть содержание файла Основной сценарий: 1. Пользователь нажимает на меню "Файл" в верхнем левом углу приложения 2. Пользователь выбирает "Открыть" пункт-меню из предложенных вариантов 3. Приложение открывает диалоговое окно и запрашивает ввести полное имя файла, который пользователь желает открыть для чтения 4. Пользователь вводит полное имя файла, который он хочет отрыть или выбирает путь в ручную в навигаторе компьютера 5. Нажимает на кнопку "Открыть" в диалоговом окне 6. Приложение открывает файл. Вся информация из файла отражена корректно и удобна для чтения.      Альтернативы… Параметры...

Открытие файла в Notepad. Легенда: П — пользователь Б — блокнот Вариант. П инициирует открытие файла. Б открывает файл Альтернативы… Параметры..

Я устала от текста слева на 5 строке. А справа прочитала за минуту. Делайте выводы :-)

См также:
Сила примера — после варианта, альтернатив, параметров... Не забудьте про пример!

Типовые ошибки

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

1. Вариант начинает система

Инициирует сценарий всегда человек, убирайте сразу фразы вида

С предоставила П возможность выбора...

Пишите о действиях, не о статическом состоянии.

2. Система — ванга-терминатор

В домашних заданиях студентов часто вижу что-то типа:
1. Пользователь выбирает файл

2. Система отображает окно выбора файла

Итак, я пользователь, я открываю папку с файлами, рассматриваю их и думаю "ага, надо залить вот этот", мысленно выбрала. И ВДРУГ открывается сайт системы и начинает что-то делать!!!!

Терминатор отдыхает :) Я лично побоялась бы такого сайта ))) Но, может, система не такая страшная и пользователь все таки что-то делает? :)

3. Внутренний сбой везде и всюду

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

4. Действие по устранению вместо самой альтернативы

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

5. У сценария должно быть название

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

Сценарий заполнения полей доставки → плохой сценарий. Зачем мне заполнять какие-то поля?
Оформить покупку → а вот это уже больше похоже на реальность :)

6. Тут было что-то умное

Не бойтесь действовать!

Да, тестировщик — не аналитик. Но писать требования самому безумно интересно. Вы узнаете детали реализации, прикидываете будущий комплекст тест-кейсов и просто наносите много добра!

Как написать вариант:

1. Найти пользователя и цель.
2. Записать основной сценарий.
3. Продумать альтернативы.
4. Выделить параметры
5. Навести красоту.
6. Проверить в Главреде на стоп-слова.
7. Выкинуть лишнее.

Профит!

PS — статья написана в помощь моим студентам, ссылку на нее всегда можно найти на Testbase в навыке «Тестирование документации».

PPS — также эта статья является выдержкой из моей книги для начинающих тестировщиков!