Благодарю за вопрос и дополнения. Все по делу. Здорово! (п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".
Спасибо за вопрос. Это пилотная статья и проба пера. Хочу в следующей статье более глубже рассмотреть поднятую тему. Приведенные примеры в таком объеме вы вряд ли найдете в книгах о тестировании. Скорее всего - понадобятся и журналы. Цель статьи не только донести информацию, напомнить на важность использования предусловий, но и призвать участников сообщества к диалогу, полемике по данной теме.
Хотелось бы от всей души поблагодарить автора за прекрасную статью и затраченные на нее силы. Весьма полезная и толковая статья, которая обязательно найдет отклик в умах своих читателей.
Ну а теперь перехожу непосредственно к своему развернутому комментарию.
Сильные стороны:
Практическая направленность: Автор статьи делится своим опытом применения техник тест-дизайна в реальном проекте, что делает материал более интересным и ценным для читателей, особенно для тех, кто только начинает свой путь в тестировании. Также стоит отметить, что автор уделяет внимание не только техникам тестирования, но и важности декомпозиции системы перед началом тестирования. Он подробно описывает, как он разбивает систему оплаты на отдельные компоненты и как это помогает ему более эффективно проводить тестирование.
Четкость и структурированность: Статья хорошо структурирована, содержит понятные определения и примеры, что облегчает восприятие информации.
Комплексный подход: Автор статьи не ограничивается описанием одной техники тест-дизайна, а рассматривает их комбинацию, что позволяет провести более полное тестирование системы.
Наглядность: Иллюстрации и схемы, используемые в статье, помогают лучше понять описываемые концепции.
Актуальность: Тема статьи актуальна для QA-специалистов, занимающихся тестированием систем оплаты.
Точки роста:
Недостаточно подробное описание некоторых техник: Автор статьи мог бы более подробно описать некоторые техники тест-дизайна, например, прогнозирование ошибок.
Не уделено достаточное внимания различным типам ошибок, которые могут возникнуть при тестировании систем оплаты. Он упоминает о "потере свойства оплаты", но не рассматривает другие возможные ошибки, такие как неправильное округление сумм, проблемы с обработкой возвратов и т.д.
Не упоминается о важности тестирования безопасности системы оплаты. В современном мире это является одним из ключевых аспектов тестирования, так как системы оплаты часто становятся целью для хакерских атак.
Отсутствие примеров тестовых сценариев: Примеры тестовых сценариев, основанных на описанных техниках, могли бы сделать статью еще более практичной.
Недостаточная фокусировка на нюансах: Автор статьи мог бы более подробно остановиться на нюансах тестирования систем оплаты, связанных с налогами, чеками, возвратными чеками, регионами, экономическими зонами.
Рекомендации:
Добавить больше примеров тестовых сценариев.
Более подробно описать прогнозирование ошибок.
Рассмотреть нюансы тестирования систем оплаты, связанные с налогами, чеками, возвратными чеками, регионами, экономическими зонами.
Общее впечатление:
Статья "Тест-дизайн на практике: комбинируем разные техники тестирования, на примере проверки систем оплаты" является ценным ресурсом для QA-специалистов, занимающихся тестированием систем оплаты. Автор статьи делится своим опытом применения техник тест-дизайна, что делает материал интересным и практичным.
Моя оценка: 4,5 из 5.
Дополнительные комментарии:
Автор статьи мог бы добавить раздел "Заключение", в котором он бы подвел итоги и дал рекомендации по применению описанных техник тест-дизайна.
В статье можно было бы использовать больше ссылок на дополнительные ресурсы по теме тестирования систем оплаты.
В целом, статья представляет собой полезный обзор техник тестирования систем оплаты и может быть интересна как начинающим, так и опытным тестировщикам. Она подчеркивает важность комбинирования различных техник и подхода к тестированию с разных сторон.
Статья из рода фантастики на IT тематику. Абсолютно отсутствует научный подход к методологии исследования. Его просто нет. Автор приводит данные, которые не обоснованы и не подкреплены никакой доказательной базой. Кроме того, данный материал можно уже смело использовать в суде как факт клеветы на IT-курсы, т.к. они не давали согласия на опубликование информации о своих выпускниках и результатах работы. Пишу не как защитник IT-курсов, а как IT-специалист с большим багажом научного опыта в прошлом. А модераторы Habr могут также "отхватить" за подобные публикации. Как минимум кто-то может в ближайшей перспективе сходить в суд вместе с автором статьи. Это реалии сегодняшнего времени.
Статью однозначно нужно переименовывать. Принципами тут и не пахнет, да и целью также. Цель всегда одна, ну 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" для статичных условий.
Для динамических действий используйте последовательные тест-кейсы или другие решения.
Четко формулируйте все условия и действия.
Спасибо за вопрос. Это пилотная статья и проба пера. Хочу в следующей статье более глубже рассмотреть поднятую тему. Приведенные примеры в таком объеме вы вряд ли найдете в книгах о тестировании. Скорее всего - понадобятся и журналы. Цель статьи не только донести информацию, напомнить на важность использования предусловий, но и призвать участников сообщества к диалогу, полемике по данной теме.
Хотелось бы от всей души поблагодарить автора за прекрасную статью и затраченные на нее силы. Весьма полезная и толковая статья, которая обязательно найдет отклик в умах своих читателей.
Ну а теперь перехожу непосредственно к своему развернутому комментарию.
Сильные стороны:
Практическая направленность: Автор статьи делится своим опытом применения техник тест-дизайна в реальном проекте, что делает материал более интересным и ценным для читателей, особенно для тех, кто только начинает свой путь в тестировании. Также стоит отметить, что автор уделяет внимание не только техникам тестирования, но и важности декомпозиции системы перед началом тестирования. Он подробно описывает, как он разбивает систему оплаты на отдельные компоненты и как это помогает ему более эффективно проводить тестирование.
Четкость и структурированность: Статья хорошо структурирована, содержит понятные определения и примеры, что облегчает восприятие информации.
Комплексный подход: Автор статьи не ограничивается описанием одной техники тест-дизайна, а рассматривает их комбинацию, что позволяет провести более полное тестирование системы.
Наглядность: Иллюстрации и схемы, используемые в статье, помогают лучше понять описываемые концепции.
Актуальность: Тема статьи актуальна для QA-специалистов, занимающихся тестированием систем оплаты.
Точки роста:
Недостаточно подробное описание некоторых техник: Автор статьи мог бы более подробно описать некоторые техники тест-дизайна, например, прогнозирование ошибок.
Не уделено достаточное внимания различным типам ошибок, которые могут возникнуть при тестировании систем оплаты. Он упоминает о "потере свойства оплаты", но не рассматривает другие возможные ошибки, такие как неправильное округление сумм, проблемы с обработкой возвратов и т.д.
Не упоминается о важности тестирования безопасности системы оплаты. В современном мире это является одним из ключевых аспектов тестирования, так как системы оплаты часто становятся целью для хакерских атак.
Отсутствие примеров тестовых сценариев: Примеры тестовых сценариев, основанных на описанных техниках, могли бы сделать статью еще более практичной.
Недостаточная фокусировка на нюансах: Автор статьи мог бы более подробно остановиться на нюансах тестирования систем оплаты, связанных с налогами, чеками, возвратными чеками, регионами, экономическими зонами.
Рекомендации:
Добавить больше примеров тестовых сценариев.
Более подробно описать прогнозирование ошибок.
Рассмотреть нюансы тестирования систем оплаты, связанные с налогами, чеками, возвратными чеками, регионами, экономическими зонами.
Общее впечатление:
Статья "Тест-дизайн на практике: комбинируем разные техники тестирования, на примере проверки систем оплаты" является ценным ресурсом для QA-специалистов, занимающихся тестированием систем оплаты. Автор статьи делится своим опытом применения техник тест-дизайна, что делает материал интересным и практичным.
Моя оценка: 4,5 из 5.
Дополнительные комментарии:
Автор статьи мог бы добавить раздел "Заключение", в котором он бы подвел итоги и дал рекомендации по применению описанных техник тест-дизайна.
В статье можно было бы использовать больше ссылок на дополнительные ресурсы по теме тестирования систем оплаты.
В целом, статья представляет собой полезный обзор техник тестирования систем оплаты и может быть интересна как начинающим, так и опытным тестировщикам. Она подчеркивает важность комбинирования различных техник и подхода к тестированию с разных сторон.
Отличная статья! Читал на одном дыхании. Огромное спасибо за рекомендации и личный опыт! Это очень важно!
Статья из рода фантастики на IT тематику. Абсолютно отсутствует научный подход к методологии исследования. Его просто нет. Автор приводит данные, которые не обоснованы и не подкреплены никакой доказательной базой. Кроме того, данный материал можно уже смело использовать в суде как факт клеветы на IT-курсы, т.к. они не давали согласия на опубликование информации о своих выпускниках и результатах работы. Пишу не как защитник IT-курсов, а как IT-специалист с большим багажом научного опыта в прошлом. А модераторы Habr могут также "отхватить" за подобные публикации. Как минимум кто-то может в ближайшей перспективе сходить в суд вместе с автором статьи. Это реалии сегодняшнего времени.
Статью однозначно нужно переименовывать. Принципами тут и не пахнет, да и целью также. Цель всегда одна, ну 2 - это максимум, а остальное это решаемые задачи на пути её достижения. Правильно уже ни один раз сказано о разнице между целями и принципами, однако никто не сказал, что это статья даже не о новой цели , а обыкновенной задаче. Предложение в цели тестирования нужно добавить еще один пункт - «Работать над улучшением продукта» на мой взгляд не является актуальным и с методологической точки зрения ошибочным, так как цель как я сказал одна, а задач много. Статья получилась очень сырая. Автору желаю успехов в написании новых, более грамотных и полезных статей.