Комментарии 4
Привет, спасибо за статью - этот вопрос и правда часто встает даже у опытных, пару примеров особенно полезные и интересные! Хочу уточнить по некоторым моментам, по которым возникли размышления:
"п.6. Авторизация/аутентификация" - здесь речь идет про какую-то первичную авторизацию в системе, .tp которой не доступно приложение, или доступ к какой-то тестовой сборке? Потому что если речь про обычную авторизацию - в духе авторизоваться, перейти в корзину, оформить заказ..., то я считаю, такое не получится прописать в предшагах, тк на мой взгляд предшаги - это что-то, что можно сделать предварительно, и оно будет в этом состоянии, пока не отменят эти настройки или не удалят эти данные или тп. Тк пользователь не может сидеть авторизованным вечно, через какое-то время авторизация сбросится, а значит авторизацию придется писать в шагах, потому что ее надо будет выполнить непосредственно перед нужными для теста действиями.
"п.10. Предыдущие действия" - аналогично, не получится заранее установить пользователю какое-то состояние, что он "нажал на кнопку »Забыли пароль?”"(кстати, тут пунктуация сохранена, в тексте с кавычками напутано)) и у него остается это состояние. Т.е. на эту кнопку придется нажать непосредственно перед проверкой восстановления пароля.
Заранее спасибо, если прокомментируешь эти моменты!
P.S. В п.7 "Версии" похоже прописано сразу 2 отдельных примера, потому что дальше по тексту в этом пункте идет "Состояние приложения".
Благодарю за вопрос и дополнения. Все по делу. Здорово! (п7 исправил. Там действительно был 8 внутри 7-го, поэтому теперь их стало 17 и твой п 10 стал 11.).
Отвечая на Ваш вопрос по п.6 хочу уточнить и дополнить некоторые моменты:
В поле "Pre-conditions" (Предварительные условия) тест-кейса можно и нужно прописывать требование авторизации/аутентификации, но с нюансами:
Прежде всего важно отметить ,что уровни авторизации можно разделить на 2 уровня (первичной и вторичной авторизации) и также не забыть сказать о динамической природе авторизации (как раз тот момент на который Вы обратили внимание). За что вам отдельное спасибо! Итак начнем по порядку.
1) Уровень авторизации: а) первичная авторизация: если для доступа к приложению или тестовой сборке требуется авторизация, это обязательно следует указать в "Pre-conditions". Это первичный уровень, без которого тест не может быть запущен.
б) вторичная авторизация: если авторизация требуется для определенных функций внутри уже доступного приложения, то ее не обязательно прописывать в "Pre-conditions".
2) Динамическая природа авторизации:
Сброс авторизации: Вы правы, что авторизация не может длиться вечно. Если она сбрасывается за время выполнения теста, то ее необходимо повторить в шагах тест-кейса.
Сохранение авторизации: Если авторизация сохраняется на протяжении всего теста, то ее достаточно указать в "Pre-conditions".
Приведу 2 примера :
Пример 1:
Pre-conditions:Пользователь авторизован в системе под учетной записью "tester".
Шаги:
Открыть раздел "Корзина".
Добавить товар в корзину.
Оформить заказ.
Комментарий. В данном случае:
Первичная авторизация необходима для доступа к приложению.
Вторичная авторизация не требуется, т.к. она уже выполнена в "Pre-conditions".
Пример 2:
Pre-conditions: Пользователь находится на странице "Личный кабинет".
Шаги:
Перейти в раздел "Настройки безопасности".
Изменить пароль.
Комментарий. В данном случае:
Первичная авторизация не упоминается, т.к. она подразумевается.
Вторичная авторизация не требуется, т.к. пользователь уже находится в "Личном кабинете".
3) Важные рекомендации к авторизации:
Четко формулируйте требования к авторизации.
Указывайте уровень авторизации: первичная или вторичная.
Учитывайте динамическую природу авторизации: сброс или сохранение.
Используйте здравый смысл: если авторизация очевидна, не дублируйте
Надеюсь я ответил на этот вопрос.
Что касается п.10 (теперь п.11) "Предыдущие действия", то здесь Вы абсолютно правы он имеет свои ограничения:
1. Динамические действия:
Действия, которые не сохраняют свое состояние (например, нажатие кнопки), нельзя прописать в "Pre-conditions".
Пример 1:
Pre-conditions: Пользователь нажал кнопку "Забыли пароль?".
Это некорректно, т.к. после нажатия кнопка меняет свое состояние, и тест не сработает.
2. Последовательные действия:
Вместо "Предыдущие действия" для таких случаев используйте последовательные тест-кейсы.
Пример 2:
Тест-кейс 1: Нажать кнопку "Забыли пароль?".
Тест-кейс 2: Проверить возможность восстановления пароля.
Рекомендации:
Используйте "Pre-conditions" для статичных условий.
Для динамических действий используйте последовательные тест-кейсы или другие решения.
Четко формулируйте все условия и действия.
Добрый день, спасибо за статью.
Но чем статья отличается от «вырезки» из книг / курсов по тестированию?
Спасибо за вопрос. Это пилотная статья и проба пера. Хочу в следующей статье более глубже рассмотреть поднятую тему. Приведенные примеры в таком объеме вы вряд ли найдете в книгах о тестировании. Скорее всего - понадобятся и журналы. Цель статьи не только донести информацию, напомнить на важность использования предусловий, но и призвать участников сообщества к диалогу, полемике по данной теме.
Что можно и стоит писать в поле Pre-conditions в тест-кейсах