Как я могу не повторяться, когда у меня есть сценарии с огурцами, которые у разных персонажей схожи?

Я в процессе написания сценариев Gherkin и сталкиваюсь с проблемой, когда пользовательские истории применяются к нескольким персонажам в разрабатываемой нами системе с небольшими различиями.

Основываясь на том, что я прочитал, предпочтительный подход - писать файлы функций с этой точки зрения:

Как [роль / персона]

Я хочу [особенность]

Так что [выгода]

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

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

Один из способов решения этой проблемы - ориентировать Feature / User Story на сущность (заявителя), а не на личность, т.е.

Функция

Как пользователь приложения (NB. Вместо того, чтобы упоминать конкретную личность, мы ссылаемся на "общий" пользовательский образ)

Я хочу видеть кандидатов

Чтобы я мог выполнять свои рабочие обязанности

Сценарий

Когда я прошу просмотреть кандидатов

Затем я должен просмотреть кандидатов, которые мне разрешены на основе моих разрешений.

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

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


person Rob    schedule 03.03.2016    source источник


Ответы (2)


Я бы меньше беспокоился о дублировании и больше сосредоточился на ясности.

Если заинтересованной стороне важно видеть, что региональному менеджеру разрешено видеть некоторые материалы, а внешнему заказчику разрешено видеть другие материалы об этом же приложении, я бы выразил это в Gherkin.

Я уверен, что эти правила не будут часто меняться, поскольку они, вероятно, лежат в основе домена. Это означает, что вы не будете их часто менять. Если вам нужно их изменить, ваша заинтересованная сторона должна легко это понять.

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

Если изменения носят скорее технический характер и вашей заинтересованной стороне все равно, то используйте модульные тесты для фиксации реализации, а не Gherkin.

Но в этом случае меньше сосредотачивайтесь на дублировании и больше на создании общего понимания, которое легко передать.

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

person Thomas Sundberg    schedule 04.03.2016

«Как [роль]» не о том, кто является пользователем функции, а о том, кому эта функция требуется. Чаще всего некоторые заинтересованные стороны нуждаются в функциях, чтобы компания могла получать выгоду и вести более эффективный бизнес.

В вашем случае речь идет о просмотре претендентов. Различный доступ должен быть описан несколькими сценариями в одном файле функций. Однако не все ваши роли доступа важны для объяснения этой функции. Несмотря на то, что инструменты, лежащие в основе Gherkin, можно тестировать, функции и сценарии Gherkin больше отражают идею, стоящую за ними, чем охватывают все возможные сценарии. Выберите 1-2 наиболее важных роли доступа, а остальные относятся к более низким уровням тестирования, в основном модульным тестам.

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

person Jakub Zapletal    schedule 07.03.2016