Должен ли я иметь пользовательские истории, касающиеся случая, когда пользователь не аутентифицирован?

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

В положительных сценариях у меня есть такой контекст:

Given I am authenticated
When I create meeting X
Then meeting X is well created

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

Given I am not authenticated  //note the 'not' word
When I create meeting X
Then meeting X is not created
And an authentication error should be thrown

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

Это практика, которую я должен соблюдать?
Правильно ли я считаю этот «защитный» сценарий реальным бизнес-правилом, которое я могу обсудить с командой «Бизнес»?

Обратите внимание, что мои приемочные тесты не проверяются через часть графического интерфейса, а только непосредственно через часть вариантов использования (сервисы/бизнес-правила).

Создание тегов для корнишонов или огурцов может быть полезно для таких вопросов, но может легко соскользнуть в инженерию.
«Учитывая, что я не аутентифицирован... Когда я создаю собрание X»: следует подумать еще о том, почему пользователь, не прошедший проверку подлинности, может даже попытаться создать собрание. Это больше похоже на проблему дизайна UX, чем на полезный тестовый пример. Как всегда, YMMV.

Ответы (4)

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

Я привык смотреть на это несколько иначе. Обычно User Story — это один шаг вверх, например:

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

Тогда я бы использовал оба эти критерия приемлемости для этой истории.

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

Кажется, что ваше предложение является для меня ярлыком функции, а не пользовательской истории. Функция направлена ​​на то, чтобы сосредоточиться на цели («Я бы хотел...»), история пользователя (сценарий) — это путь к ее достижению (или нет) с помощью «Дано/Когда/Тогда».
У меня определенно был разный опыт в терминологии, но похоже, что мы на одной странице — «Я хотел бы» описывает цель, а «Дано/Когда/Тогда» описывает ожидаемое поведение внутри нее. . В любом случае, я думаю, что это хорошо и даже важно, что вы учитываете ожидаемое негативное поведение. Я ожидаю, что ваши тестировщики обнаружат еще больше, что необходимо учитывать.

Фиксируйте бизнес-концепции (а не этапы разработки) в Gherkin

Это практика, которую я должен соблюдать?

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

Выразите экономическое обоснование

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

Given that a user is not authenticated
When the user performs any action
Then the user is redirected to the login page.

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

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

Есть золотая середина: очертания Сенарио.

Используйте схемы сценария

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

Например:

Scenario Outline: force authentication on all pages
  Given an unauthenticated user
  When the user connected to the <function> page
  Then the user should be redirected to the login page.

  Examples:
    | function |
    | meeting  |
    | calendar |
    | profile  |
    | launch thermonuclear warheads |

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

Резюме

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

что отличается от моей практики в моем ОП? То, что я упоминаю о возврате ошибки? звучит слишком технично, даже если «абстрактно»? Мне это нужно, потому что мои приемочные тесты нацелены непосредственно на варианты использования, а не на графический интерфейс или какой-либо механизм «перенаправления».
Разница, если я правильно понимаю — по крайней мере, я бы проголосовал за это — состоит в том, что вы сохраняете это общее требование в одном месте. Это упрощает обслуживание требований (представьте, что произойдет, если в этом отношении что-то изменится; в вашем случае вам придется обновить много мест), а также создание тестовых случаев или низкоуровневых технических требований.
@ Mik378 Mik378 По своей сути вы пытаетесь поднять ступеньки до первоклассного статуса в своих сценариях. Хотя вы можете сделать это, и достоинства этого можно обсудить в другом месте (например, на сайте, посвященном тестированию QA), этот сайт посвящен управлению проектами. С точки зрения PM, низкоуровневые тесты и инженерно-ориентированный язык не должны быть первоклассными артефактами проекта. На самом деле, я считаю, что отчеты инженерного уровня, маскирующиеся под «приемочное тестирование», являются серьезным запахом проекта, который определенно следует рассматривать как анти-шаблон. YMMV.
@CodeGnome Я не думаю, что это низкоуровневые тесты. Сценарий — это не низкоуровневый тест, а спецификация, востребованная Бизнесом.

TL;DR: Да, вы можете оставить это так.

Длинный ответ

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

Первый случай: сценарий используется для критериев приемлемости

История

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

Критерии приемлемости

  • Пользователь, прошедший проверку подлинности, может создавать собрания через графический интерфейс пользователя или API.
  • Анонимные пользователи не должны иметь возможности создавать собрания и вместо этого получать сообщение об ошибке

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

Неполный пример:

счастливый путь

  1. открыть браузер -> появляется экран входа в систему
  2. аутентификация -> сообщение об успешном входе в систему
  3. создать встречу -> посмотреть подробности встречи

без аутентификации

  1. открыть браузер -> появляется экран входа в систему
  2. создать собрание -> увидеть, что создание не удалось из-за ошибки аутентификации

Примечание

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

То, что вы называете историей, я называю особенностью. То, что вы называете критериями, я называю историей или сценарием. Это корнишоны.
Я вижу, может быть, вы заменили тег на корнишон :) Неважно, кроме терминов, этот ответ как-то полезен?
Да, ответ полезен, но я не согласен с тем, что регрессионное тестирование должно происходить через графический интерфейс. 8thlight.com/blog/doug-bradbury/2011/04/26/… (в конце этой статьи)
Интересные мысли :) Просто для ясности, кроме регрессионных тестов, мы используем модульные тесты, чтобы получить быстрые результаты (почти без ожидания) и автоматические регрессионные тесты каждый день, проверяя все приемочные тесты на "реальных" средах (плюс несколько версий и системы БД). Таким образом мы убеждаемся, что все работает как надо, даже при небольших изменениях. До этого у нас часто случалась ситуация, что слишком много в наших тестах имитировалось и выдавало ошибки после релиза в другие окружения.
Я практикую ATDD, заключающийся в приемочных тестах, реализуемых через несколько циклов TDD (модульных тестов). Как только эти модульные тесты пройдены (инкрементальный алгоритм), соответствующие приемочные тесты должны быть пройдены.
Дядя Боб (Роберт С. Мартин) глубоко обсуждает ваш образ действий. Недостатком вашего подхода является то, что вы связываете графический интерфейс с бизнес-правилами. Вы меняете графический интерфейс (например, тяжелый клиент на веб-клиент), вы нарушаете тесты по бизнес-правилам... Кроме того, ваши тесты будут медленными, очень медленными, если вы примете во внимание графический интерфейс. Тесты, связанные с графическим интерфейсом, должны проверять не бизнес-правила, а только элементы графического интерфейса.
Действительно, производительность - это проблема, и да, изменение графического интерфейса заставляет вас изменить тест - поэтому наша бизнес-логика полностью протестирована с помощью модульных тестов! Регрессионные тесты в том виде, в каком мы их используем, с графическим интерфейсом максимально приближены к способу работы пользователей, поэтому они мне нравятся.
Модульных тестов недостаточно, хотя они и выглядят как приемочные тесты ( vimeo.com/68375232 ). Разница в том, что приемочными тестами занимается бизнес-команда, а не только разработчики. Огурец, например, собирается поговорить с Бизнесом. Огуречные файлы являются источником приемочных тестов, они не должны иметь дело с графическим интерфейсом. 8thlight.com/blog/uncle-bob/2013/09/26/AT-FAIL.html ctrl+f => «Что меняется больше, чем пользовательский интерфейс»

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

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

Плохой:

Учитывая, что я аутентифицирован

Когда я создаю встречу X

Лучше:

Учитывая, что я аутентифицирован

Когда я отправляю запрос на создание встречи

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

хм, я не согласен, как я объяснил выше. Приемочные тесты должны быть сосредоточены не на части графического интерфейса или контроллера, а непосредственно на сценарии использования. Когда вы упоминаете «отправить»/«запрос», это термины web => gui. Графический интерфейс — это деталь реализации, и детали не должны быть частью приемочных тестов. Например, если ваш клиент представляет собой чистую консоль (терминал), а не сеть, условия вашего приемочного теста будут неуместными.
Я думал о твоей точке зрения. Я нашел следующий пример, который значительно улучшает связность сценария: agilealliance.org/glossary/gwt (внизу). Мне нравится подход «я пытаюсь…», означающий, что результат еще не предсказуем, прежде чем действовать. Это достаточно абстрактно, чтобы выполнить мой агностицизм пользовательского интерфейса и похоже на ваше «Я подчиняюсь ...».
@Mik378: Да, это тоже должно сработать.
Должен ли я иметь пользовательские истории, касающиеся случая, когда пользователь не аутентифицирован?
СпросиСетьПолитика конфиденциальности1y, 0v