Автор — Нина Полторакова (Агеева)
При написании статьи были использованы материалы Владимира Беленя, подготовленные в рамках внутреннего обучающего семинара проектной команды Лаборатории качества «User story & friends».
Процесс тестирования прикладного ПО всегда имеет свои особенности и тонкости. Зная о них и правильно определив целевую аудиторию и ее потребности, специалист может провести проверку быстрее и качественнее. Одной из таких «тонкостей» является техника User story. В нашей статье мы постараемся выяснить, что это за техника, и почему она не только применима, но и удобна в тестировании страховых продуктов, а также наметим способы обнаружения критичных багов функционала с ее помощью.
User story
Для начала определимся, что же такое User story. Пользовательские истории (англ. User Story) – способ описания требований к разрабатываемой системе, сформулированных как одно или несколько предложений на повседневном или деловом языке пользователя. Пользовательские истории – это один из самых быстрых способов документирования требований клиента (цель документирования состоит в том, чтобы оперативно и без затрат реагировать на возникающие изменения).
Главное действующее лицо User story – это некий персонаж, который будет совершать какие-либо действия с нашим тестируемым продуктом с учетом его потребностей. Персонаж сопровождается описанием проблем, которые он может (и хочет) решить с помощью нашего продукта. Потребность представляет собой тезис в 1-2 предложения. Для одного пользователя может быть разработано несколько (например, 4-6) User Story.
Как определить персонажей и их потребности?
Итак, кем является персонаж, каковы его потребности, и почему они важны для нас?
Персонаж – типичный представитель целевой аудитории компании. Это не реальный человек, а некий собирательный образ, который описывается на основе поведения и мотивов многих пользователей; он сочетает в себе изложение действий, совершаемых пользователем, а также причин этих действий. Персонажи просты, но их применение требует затрат времени и сил проектировщика. Увы, недостаточно просто «слепить» пару пользователей на основе своих представлений о целевой аудитории компании, приложить готовое фото из интернета и добавить описание должности. От таких персонажей пользы не будет.
Для того, чтобы персонажи стали эффективными инструментами проектирования сайта, потребуется не только провести исследование, но и выявить закономерности в поведении пользователей. Как правило, принято создавать и детально прорабатывать одного основного (как показано на mind-map ниже) и несколько второстепенных персонажей.
По клику на картинку откроется полная версия.
Однако, мы на своем опыте убедились, что к прикладному ПО данное правило неприменимо по одной просто причине: мы не можем сгруппировать мотивы и потребности бухгалтера, страхового агента и руководителя филиала. Вывод прост: нам необходимо выделить сразу несколько основных персонажей, которые будут использовать тот или иной набор функциональных блоков тестируемого ПО. В данной статье мы рассмотрим в качестве примера одного основного и одного второстепенного персонажа.
По клику на картинку откроется полная версия.
Для этого нам потребуется помощь заказчика и плотное взаимодействие по вопросу создания персонажей. К сожалению, большинство заказчиков, отвечая на вопрос «кто ваша целевая аудитория?», дают ответ: «Все люди». Это неверно. Например, уборщица страховой компании Вера Ивановна 63-х лет и охранник Володя 37 лет не имеют никакого отношения к ПО, являясь при этом сотрудниками.
Как же выявить нужных нам персонажей и определить их потребности? Это довольно просто: оцениваем количество модулей продукта и их смысловую нагрузку, а затем задаем заказчику правильные вопросы. В той же страховой компании функциональные модули «Контрагенты», «Агентские договоры», «Договоры страхования» и «Вознаграждение» говорят нам о том, что в системе может быть создан страховой агент, для которого будут заведены условия вознаграждения, а при наличии договоров страхования – произведен расчет комиссионного вознаграждения.
Необходимо расспросить заказчика об агентах: сидят ли они в офисе или работают «в полях», занимаются продажами и сопровождением ОСАГО и КАСКО или обзванивают «холодный круг» (клиентов из числа тех, с кем ранее никогда не контактировали)? После фиксации и анализа ответов можно приступать к проектированию персонажей.
Пользовательский сценарий
После того, как мы определились с персонажами, нужно проработать User story, в которой следует более детально описать предысторию, раскрывающую мотивы персонажа совершить определенные действия, используя наш продукт.
В тестируемом нами ПО для страховой компании существует 15 функциональных модулей. В модуле «Контрагенты» хранится информация обо всех действующих агентах и контрагентах, которые сотрудничают со «Страховой компанией». В модуле «Агентские договоры» производится учет условий вознаграждения для агентов. Модуль «Договоры страхования» систематизирует договоры страхования по различным видам: авто, несчастный случай, имущество физических и юридических лиц и др.
Наш персонаж – страховой агент Мария. Мария сделала неплохую карьеру, сотрудничая со «Страховой компанией» на протяжении трех лет, она имеет несколько десятков агентских договоров по разным видам с индивидуальными условиями вознаграждения. Последний ее клиент, которому она предоставила скидку за счет своего комиссионного вознаграждения при оформлении полиса КАСКО, недавно стал ее мужем. После регистрации брака Мария сменила фамилию. Теперь Марии необходимо изменить фамилию в личной карточке «Страховой компании».
Итак, перед нами типичная и абсолютно реальная User story, имеющая несколько особенностей: персонаж, выполняющий действия, сами действия и необходимость или ценность выполняемых действий. Однако, в данном случае Мария не сама будет вносить изменения в карточку, это сделает сотрудник «Страховой компании», отвечающий за учет и хранение данных о контрагентах. Таким образом, у нас есть второстепенный и основной персонажи. Занесем информацию:
По клику на картинку откроется полная версия.
Мы смоделировали одну из возможных жизненных ситуаций. Что делать дальше? Приступать к тестированию? Пожалуй, рановато. На этом этапе логичнее будет разработать Use case (варианты использования) и при необходимости составить на их основе тест-кейсы. Более подробно о Use case вы можете почитать в книге А.Коберна «Современные методы описания функциональных требований к системам». В этом труде содержится много полезного материала, но в рамках функционального тестирования нам достаточно знать основной принцип применения этой техники – выделение обобщенных последовательностей действий лиц и ответов системы на эти действия. Ответы, в свою очередь, составляются на основе анализа действующих лиц и их конечных целей в различных условиях (с учетом соглашения о поведении рассматриваемой системы).
Нетрудно заметить, что после определения действующих лиц и целей использования нам остается только составить последовательность действий, которая приведет к желаемой цели. Правильным будет сначала составить наиболее стандартный порядок действий, а далее подумать о возможных отклонениях от этого порядка (расширения варианта использования). Расширения могут быть добавлены к любому действию и ответу системы и должны привести к определенному результату. При этом результат может отличаться от конечной цели пользователя.
Составляем основной сценарий:
- Мария обращается в «Страховую компанию» с просьбой изменить ее фамилию в системе.
- Вероника (сотрудник, отвечающий за учет данных о контрагентах) запрашивает документы у Марии.
- Мария предоставляет свидетельство о заключении брака, новый паспорт и другие требуемые документы.
- Вероника проверяет и сканирует документы.
- Вероника находит/открывает личную карточку агента Марии.
- Вероника вносит изменения в карточке контрагента, прикрепляет сканы к электронной карточке.
- Вероника сохраняет изменения в карточке контрагента.
- Система сохраняет данные и вносит изменения в сущности, в которых содержится информация о данном контрагенте (карточка агента, агентские договоры, неактивированные договоры страхования).
- Мария открывает любой свой агентский договор и убеждается в том, что все данные верны.
Далее пишем расширенный сценарий:
- Мария обращается в «Страховую компанию» с просьбой изменить ее фамилию в системе.
- Вероника (сотрудник, отвечающий за учет данных о контрагентах) запрашивает документы у Марии.
- Мария предоставляет свидетельство о заключении брака, новый паспорт и другие требуемые документы.
- Вероника проверяет и сканирует документы.
- Вероника находит/открывает личную карточку агента Марии.
- Вероника вносит изменения в карточке контрагента, прикрепляет сканы к электронной карточке:
6а. Вероника вводит некорректные данные (опечатка).
6b. Система выводит сообщение о некорректности данных.
Далее (если нам необходимо составить тест-кейсы на основе Use case) для удобства использования полученную информацию можно перевести в табличный вид, где в первой колонке будет основной сценарий, а в других – последовательности с отклонениями:
Таким образом, мы получили заготовки для наших будущих тест-кейсов. Теперь остается выявить существующие в шагах параметры и их значения. Для этого нам понадобятся знания других техник тест-дизайна, о которых подробно написано в статье Антона Алексеева.
Почему User story удобны при тестировании страховых продуктов?
Согласитесь, к тестированию можно было бы подойти иначе. Не используя User story (особенно этап создания персонажей) и Use case, мы могли проверить функциональность модуля «Контрагенты» в плане создания, сохранения и редактирования данных, а потом завести баги в случае неверной работы какой-то части модуля. Однако, этого оказалось бы совершенно недостаточно, так как все модули тестируемого страхового ПО взаимосвязаны между собой. Изменения, внесенные в один модуль, должны быть обработаны другим модулем: так, исправления в карточке контрагента влекут за собой корректировку данных в агентских договорах, договорах страхования и в агентском портале.
Заключение
Итак, техника User story (включая создание персонажей) позволяет не только ясно оценить набор функциональных модулей ПО, затрагиваемых действиями персонажа, но и грамотно составить тестовые наборы с акцентом на корректность взаимосвязи изменения данных в различных модулях. Поняв это, мы решили опробовать техники на практике. Так, в приведенном в статье примере они позволили нам локализовать два критичных дефекта: во-первых, данные изменялись не полностью (в частности, в карточке уже действующего агентского договора не менялись данные агента), а во-вторых, система давала возможность заменить агента на другого без заключения дополнительных соглашений.
Таким образом, мы можем однозначно сказать: применение в тандеме техник User story и Use case оправдано в силу того, что они дополняют друг друга и позволяют не только качественно протестировать продукт, но и получить, дополнить и проверить требования в случае их наличия.
