Home

Автор: Нина Агеева, тест-менеджер компании "Лаборатория качества"

Оригинальная публикация: http://quality-lab.ru/user-story-as-one-of-the-features-of-insurance-products-testing/

При написании статьи были использованы материалы Владимира Беленя, подготовленные в рамках внутреннего обучающего семинара проектной команды Лаборатории качества «User story & friends».

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

User story

Для начала определимся, что же такое User story. Пользовательские истории (англ. User Story) – способ описания требований к разрабатываемой системе, сформулированных как одно или несколько предложений на повседневном или деловом языке пользователя. Пользовательские истории – это один из самых быстрых способов документирования требований клиента (цель документирования состоит в том, чтобы оперативно и без затрат реагировать на возникающие изменения).

Главное действующее лицо User story – это некий персонаж, который будет совершать какие-либо действия с нашим тестируемым продуктом с учетом его потребностей. Персонаж сопровождается описанием проблем, которые он может (и хочет) решить с помощью нашего продукта. Потребность представляет собой тезис в 1-2 предложения. Для одного пользователя может быть разработано несколько (например, 4-6) User Story.

Как определить персонажей и их потребности?

Итак, кем является персонаж, каковы его потребности, и почему они важны для нас?
Персонаж – типичный представитель целевой аудитории компании. Это не реальный человек, а некий собирательный образ, который описывается на основе поведения и мотивов многих пользователей; он сочетает в себе изложение действий, совершаемых пользователем, а также причин этих действий. Персонажи просты, но их применение требует затрат времени и сил проектировщика. Увы, недостаточно просто «слепить» пару пользователей на основе своих представлений о целевой аудитории компании, приложить готовое фото из интернета и добавить описание должности. От таких персонажей пользы не будет.

Для этого нам потребуется помощь заказчика и плотное взаимодействие по вопросу создания персонажей. К сожалению, большинство заказчиков, отвечая на вопрос «кто ваша целевая аудитория?», дают ответ: «Все люди». Это неверно. Например, уборщица страховой компании Вера Ивановна 63-х лет и охранник Володя 37 лет не имеют никакого отношения к ПО, являясь при этом сотрудниками.

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

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

Пользовательский сценарий

После того, как мы определились с персонажами, нужно проработать User story, в которой следует более детально описать предысторию, раскрывающую мотивы персонажа совершить определенные действия, используя наш продукт.

В тестируемом нами ПО для страховой компании существует 15 функциональных модулей. В модуле «Контрагенты» хранится информация обо всех действующих агентах и контрагентах, которые сотрудничают со «Страховой компанией». В модуле «Агентские договоры» производится учет условий вознаграждения для агентов. Модуль «Договоры страхования» систематизирует договоры страхования по различным видам: авто, несчастный случай, имущество физических и юридических лиц и др.

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

Мы смоделировали одну из возможных жизненных ситуаций. Что делать дальше? Приступать к тестированию? Пожалуй, рановато. На этом этапе логичнее будет разработать Use case (варианты использования) и при необходимости составить на их основе тест-кейсы. Более подробно о Use case вы можете почитать в книге А.Коберна «Современные методы описания функциональных требований к системам». В этом труде содержится много полезного материала, но в рамках функционального тестирования нам достаточно знать основной принцип применения этой техники – выделение обобщенных последовательностей действий лиц и ответов системы на эти действия. Ответы, в свою очередь, составляются на основе анализа действующих лиц и их конечных целей в различных условиях (с учетом соглашения о поведении рассматриваемой системы).

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

Почему User story удобны при тестировании страховых продуктов?

Согласитесь, к тестированию можно было бы подойти иначе. Не используя User story (особенно этап создания персонажей) и Use case, мы могли проверить функциональность модуля «Контрагенты» в плане создания, сохранения и редактирования данных, а потом завести баги в случае неверной работы какой-то части модуля. Однако, этого оказалось бы совершенно недостаточно, так как все модули тестируемого страхового ПО взаимосвязаны между собой. Изменения, внесенные в один модуль, должны быть обработаны другим модулем: так, исправления в карточке контрагента влекут за собой корректировку данных в агентских договорах, договорах страхования и в агентском портале.

Заключение

Итак, техника User story (включая создание персонажей) позволяет не только ясно оценить набор функциональных модулей ПО, затрагиваемых действиями персонажа, но и грамотно составить тестовые наборы с акцентом на корректность взаимосвязи изменения данных в различных модулях. Поняв это, мы решили опробовать техники на практике. Так, в приведенном в статье примере они позволили нам локализовать два критичных дефекта: во-первых, данные изменялись не полностью (в частности, в карточке уже действующего агентского договора не менялись данные агента), а во-вторых, система давала возможность заменить агента на другого без заключения дополнительных соглашений.

Таким образом, мы можем однозначно сказать: применение в тандеме техник User story и Use case оправдано в силу того, что они дополняют друг друга и позволяют не только качественно протестировать продукт, но и получить, дополнить и проверить требования в случае их наличия.

Обсудить в форуме