Название тестового сценария

Что такое тест-кейс? Тест-кейс — это профессиональная документация тестировщика, последовательность действий направленная на проверку какого-либо функционала, оп...

Пишем максимально эффективный тест-кейс

Что такое тест-кейс?

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

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

Зачем нужны тест-кейсы?

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

Атрибуты тест-кейса

Любой тест-кейс обязательно включает в себя:

  • Уникальный идентификатор тест-кейса — необходим для удобной организации хранения и навигации по нашим тест-наборам.
  • Название — основная тема, или идея тест-кейса. Кратное описание его сути.
  • Предусловия — описание условий, которые не имеют прямого отношения к проверяемому функционалу, но должны быть выполнены.
    Например, оставить комментарий на вашем портале может только зарегистрированный пользователь. Значит для тест-кейса «Создание комментария» будет необходимо выполнение предусловия «пользователь зарегистрирован», и «пользователь авторизован»
  • Шаги — описание последовательности действий, которая должна привести нас к ожидаемому результату
  • Ожидаемый результат — результат: что мы ожидаем увидеть после выполнения шагов.

Не обязательно, но желательно добавить в тест-кейс атрибут история редактирования — это сильно облегчит вам жизнь. Лаконичный журнал изменений, где отраженно: кем, как, и когда был изменен тест-кейс.

Что еще необходимо знать, перед созданием тест-кейса?

Во-первых, каждый выполненный тест-кейс, дает нам один из трех результатов:

1.Положительный результат, если фактический результат равен ожидаемому результату,
2.Отрицательный результат, если фактический результат не равен ожидаемому результату. В этом случае, найдена ошибка.
3.Выполнение теста блокировано, если после одного из шагов продолжение теста невозможно. В этом случае так же, найдена ошибка.

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

Чего не должно быть в тест-кейсе

1. Зависимостей от других тест-кейсов;
2. Нечеткой формулировки шагов или ожидаемого результата;
3. Отсутствия необходимой для прохождения тест-кейса информации;
4. Излишней детализации.

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

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

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

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

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

Источник

Тестовые сценарии (Test case), тестовые варианты. Оформление результатов тестирования.

ТЕРМИНОЛОГИЯ И ОБЩИЕ СВЕДЕНИЯ

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

Во главе всего лежит термин «тест». Официальное определение звучит так.

Тест — набор из одного или нескольких тест-кейсов.

Поскольку среди всех прочих терминов этот легче и быстрее всего произносить, в зависимости от контекста под ним могут понимать и отдельный пункт чек-листа, и отдельный шаг в тест-кейсе, и сам тест-кейс, и набор тест-кейсов и… продолжать можно долго. Главное здесь одно: если вы слышите или видите слово «тест», воспринимайте его в контексте.

Теперь рассмотрим самый главный для нас термин — «тест-кейс».

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

Под тест-кейсом также может пониматься соответствующий документ, представляющий формальную запись тест-кейса.

Мы ещё вернёмся к этой мысли, но уже сейчас критически важно понять и запомнить: если у тест-кейса не указаны входные данные, условия выполнения и ожидаемые результаты, и/или не ясна цель тест-кейса — это плохой тест-кейс (иногда он не имеет смысла, иногда его и
вовсе невозможно выполнить).

Иногда термин «test case» на русский язык переводят как «тестовый случай». Это вполне адекватный перевод, но из-за того, что «тест-кейс» короче произносить, наибольшее распространение получил именно этот вариант.

Высокоуровневый тест-кейс — тест-кейс без конкретных входных дан-
ных и ожидаемых результатов.

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

Низкоуровневый тест-кейс — тест-кейс с конкретными входными дан-
ными и ожидаемыми результатами.

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

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

Спецификация теста — документ, состоящий из спецификации тест-дизайна, спецификации тест-кейса и/или спецификации тест-процедуры.

Тест-сценарий — документ, описывающий последовательность действий по выполнению теста (также известен как «тест-скрипт»).

ЦЕЛЬ НАПИСАНИЯ ТЕСТ-КЕЙСОВ

Тестирование можно проводить и без тест-кейсов (не нужно, но можно; да, эффективность такого подхода варьируется в очень широком диапазоне в зависимости от множества факторов).

Наличие же тест-кейсов позволяет:

  • Структурировать и систематизировать подход к тестированию (без чего крупный проект почти гарантированно обречён на провал).
  • Вычислять метрики тестового покрытия (test coverage 296 metrics) и принимать меры по его увеличению (тест-кейсы здесь являются главным источником информации, без которого существование подобных метрик теряет смысл).
  • Отслеживать соответствие текущей ситуации плану (сколько примерно понадобится тест-кейсов, сколько уже есть, сколько выполнено из запланированного на данном этапе количества и т.д.).
  • Уточнить взаимопонимание между заказчиком, разработчиками и тестировщиками (тест-кейсы зачастую намного более наглядно показывают поведение приложения, чем это отражено в требованиях).
  • Хранить информацию для длительного использования и обмена опытом между сотрудниками и командами (или как минимум — не пытаться удержать в голове сотни страниц текста).
  • Проводить регрессионное тестирование и повторное тестирование (которые без тест-кейсов было бы вообще невозможно выполнить).
  • Повышать качество требований (мы это уже рассматривали: написание чек-листов и тест-кейсов — хорошая техника тестирования требований).
  • Быстро вводить в курс дела нового сотрудника, недавно подключившегося к проекту.

ЖИЗНЕННЫЙ ЦИКЛ ТЕСТ-КЕЙСА

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

  • Создан — типичное начальное состояние практически любого артефакта. Тест-кейс автоматически переходит в это состояние после создания.
  • Запланирован — в этом состоянии тест-кейс находится, когда он
    или явно включён в план ближайшей итерации тестирования, или как минимум готов для выполнения.
  • Не выполнен — в некоторых системах управления тест-кейсами это состояние заменяет собой предыдущее («запланирован»). Нахождение тест-кейса в данном состоянии означает, что он готов к выполнению, но ещё не был выполнен.
  • Выполняется — если тест-кейс требует длительного времени на выполнение, он может быть переведён в это состояние для подчёркивания того факта, что работа идёт, и скоро можно ожидать её результатов. Если выполнение тест-кейса занимает мало времени, это состояние, как правило, пропускается, а тест-кейс сразу переводится в одно из трёх следующих состояний — «провален», «пройден успешно» или «заблокирован».
  • Пропущен — бывают ситуации, когда выполнение тест-кейса отменяется по соображениям нехватки времени или изменения логики тестирования.
  • Провален — данное состояние означает, что в процессе выполнения тест-кейса был обнаружен дефект, заключающийся в том, что ожидаемый результат по как минимум одному шагу тест-кейса не совпадает с фактическим результатом. Если в процессе выполнения тест-кейса был «случайно» обнаружен дефект, никак не связанный с шагами тест-кейса и их ожидаемыми результатами, тест-кейс считается пройденным успешно (при этом, естественно, по обнаруженному дефекту создаётся отчёт о дефекте).
  • Пройден успешно — данное состояние означает, что в процессе выполнения тест-кейса не было обнаружено дефектов, связанных с расхождением ожидаемых и фактических результатов его шагов.
  • Заблокирован — данное состояние означает, что по какой-то причине выполнение тест-кейса невозможно (как правило, такой причиной является наличие дефекта, не позволяющего реализовать некий пользовательский сценарий).
  • Закрыт — очень редкий случай, т.к. тест-кейс, как правило, оставляют в состояниях «провален / пройден успешно / заблокирован / пропущен». В данное состояние в некоторых системах управления тест-кейс переводят, чтобы подчеркнуть тот факт, что на данной итерации тестирования все действия с ним завершены.
  • Требует доработки — как видно из схемы, в это состояние (и из него) тест-кейс может быть преведён в любой момент времени, если в нём будет обнаружена ошибка, если изменятся требования, по которым он был написан, или наступит иная ситуация, не позволяющая считать тест-кейс пригодным для выполнения и перевода в иные состояния.

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

Атрибуты (поля) тест-кейса.

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

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

Общий вид всей структуры тест-кейса представлен ниже:

Теперь рассмотрим каждый атрибут подробно.

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

Приоритет показывает важность тест-кейса. Он может быть выражен буквами (A, B, C, D, E), цифрами (1, 2, 3, 4, 5), словами («крайне высокий», «высокий», «средний», «низкий», «крайне низкий») или иным удобным способом. Количество градаций также не фиксировано, но чаще всего лежит в диапазоне от трёх до пяти.

Приоритет тест-кейса может коррелировать с:

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

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

Связанное с тест-кейсом требование показывает то основное требование, проверке выполнения которого посвящён тест-кейс (основное — потому, что один тест-кейс может затрагивать несколько требований). Наличие этого поля улучшает такое свойство тест-кейса,
как прослеживаемость.

Частые вопросы, связанные с заполнением этого поля, таковы:

  • Можно ли его оставить пустым? Да. Тест-кейс вполне мог разрабатываться вне прямой привязки к требованиям, и (пока?) значение этого поля определить сложно. Хоть такой вариант и не считается хорошим, он достаточно распространён.
  • Можно ли в этом поле указывать несколько требований? Да, но чаще всего стараются выбрать одно самое главное или «более высокоуровневое» (например, вместо того, чтобы перечислять R56.1, R56.2, R56.3 и т.д., можно просто написать R56). Чаще всего в инструментах управления тестами это поле представляет собой выпадающий список, где можно выбрать только одно значение, и этот вопрос становится неактуальным. К тому же многие тест-кейсы всё же направлены на проверку строго одного требования, и для них этот вопрос также неактуален.

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

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

Теперь — самое сложное: как выбираются модули и подмодули. В реальности проще всего отталкиваться от архитектуры и дизайна приложения. Например, в уже знакомом нам приложении можно выделить такую иерархию модулей и подмодулей:

  • Механизм запуска:

    • механизм анализа параметров;
    • механизм сборки приложения;
    • механизм обработки ошибочных ситуаций.

  • Механизм взаимодействия с файловой системой:

    • механизм обхода дерева SOURCE_DIR;
    • механизм обработки ошибочных ситуаций.

  • Механизм преобразования файлов:

    • механизм определения кодировок;
    • механизм преобразования кодировок;
    • механизм обработки ошибочных ситуаций.

  • Механизм ведения журнала:

    • механизм записи журнала;
    • механизм отображения журнала в консоли;
    • механизм обработки ошибочных ситуаций.

Согласитесь, что такие длинные названия с постоянно повторяющимся словом «механизм» читать и запоминать сложно. Перепишем:

  • Стартер:
    • анализатор параметров;
    • сборщик приложения;
    • обработчик ошибок.
  • Сканер:
    • обходчик;
    • обработчик ошибок.
  • Преобразователь:
    • детектор;
    • конвертер;
    • обработчик ошибок.
  • Регистратор:
    • дисковый регистратор;
    • консольный регистратор;
    • обработчик ошибок.

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

Внимание! Частая ошибка! Модуль и подмодуль приложения — это НЕ действия, это именно структурные части, «куски» приложения. В заблуждение вас могут ввести такие названия, как, например, «печать, настройка принтера» (но здесь имеются в виду именно части приложения, отвечающие за печать и за настройку принтера (и названы
они отглагольными существительными), а не процесс печати или настройки принтера).

Сравните (на примере человека): «дыхательная система, лёгкие» — это модуль и подмодуль, а «дыхание», «сопение», «чихание» — нет; «голова, мозг» — это модуль и подмодуль, а «кивание», «думание» — нет.

Наличие полей «Модуль» и «Подмодуль» улучшает такое свойство тест-кейса, как прослеживаемость.

Заглавие тест-кейса призвано упростить и ускорить понимание основной идеи (цели) тест-кейса без обращения к его остальным атрибутам. Именно это поле является наиболее информативным при просмотре списка тест-кейсов.

Сравните.

Плохо Хорошо
Тест 1 Запуск, одна копия, верные параметры
Тест 2 Запуск одной копии с неверными путями
Тест 78 (улучшенный) Запуск, много копий, без конфликтов
Остановка Остановка по Ctrl+C
Закрытие Остановка закрытием консоли

Заглавие тест-кейса может быть полноценным предложением, фразой, набором словосочетаний — главное, чтобы выполнялись следующие условия:

  • Информативность.
  • Хотя бы относительная уникальность (чтобы не путать разные тест-кейсы).

Внимание! Частая ошибка! Если инструмент управления тест-кейсами не требует писать заглавие, его всё равно надо писать. Тест-кейсы без заглавий превращаются в мешанину информации, использование которой сопряжено с колоссальными и совершенно бессмысленными затратами.

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

Исходные данные, необходимые для выполнения тест-кейса, позволяют описать всё то, что должно быть подготовлено до начала выполнения тест-кейса, например:

  • Состояние базы данных.
  • Состояние файловой системы и её объектов.
  • Состояние серверов и сетевой инфраструктуры.

То, что описывается в этом поле, готовится БЕЗ использования тестируемого приложения, и таким образом, если здесь возникают проблемы, нельзя писать отчёт о дефекте в приложении.
Эта мысль очень и очень важна, потому поясним её простым жизненным примером. Представьте, что вы дегустируете конфеты. В поле «исходные данные» можно прописать «купить конфеты таких-то сортов в таком-то количестве». Если таких конфет нет в продаже, если закрыт магазин,
если не хватило денег и т. д. — всё это НЕ проблемы вкуса конфет, и нельзя писать отчёт о дефекте конфет вида «конфеты невкусные потому, что закрыт магазин».

Некоторые авторы не следуют этой логике и допускают в приготовлениях работу с тестируемым приложением. И здесь нет «правильного варианта» — просто в одной традиции решено одним образом, в другой — другим. Во многом это — ещё и терминологическая проблема: «preparation», «initial data» и «setup» вполне логично выполнять без участия тестируемого приложения, в то время как «precondition» по смыслу ближе к описанию состояния тестируемого приложения. В реальной рабочей обстановке вам достаточно будет прочитать несколько тест-кейсов, уже созданных вашими коллегами,
чтобы понять, какой точки зрения на данный вопрос они придерживаются.

Шаги тест-кейса описывают последовательность действий, которые необходимо реализовать в процессе выполнения тест-кейса. Общие рекомендации по написанию шагов таковы:

  • начинайте с понятного и очевидного места, не пишите лишних начальных шагов (запуск приложения, очевидные операции с интерфейсом и т. п.);
  • даже если в тест-кейсе всего один шаг, нумеруйте его (иначе возрастает вероятность в будущем случайно «приклеить» описание этого шага к новому тексту);
  • если вы пишете на русском языке, используйте безличную форму (например, «открыть», «ввести», «добавить» вместо «откройте», «введите», «добавьте»), в английском языке не надо использовать частицу «to» (т.е. «запустить приложение» будет «start application», не «to start application»);
  • соотносите степень детализации шагов и их параметров с целью тест-кейса, его сложностью, уровнем и т. д. — в зависимости от этих и многих других факторов степень детализации может варьироваться от общих идей до предельно чётко прописанных значений и указаний;
  • ссылайтесь на предыдущие шаги и их диапазоны для сокращения объёма текста (например, «повторить шаги 3–5 со значением…»);
  • пишите шаги последовательно, без условных конструкций вида «если… то…».

Внимание! Частая ошибка! Категорически запрещено ссылаться на шаги из других тест-кейсов и другие тест-кейсы целиком: если те, другие тест-кейсы будут изменены или удалены, ваш тест-кейс начнёт ссылаться на неверные данные или в пустоту, а если в процессе выполнения те, другие тест-кейсы или шаги приведут к возникновению
ошибки, вы не сможете закончить выполнение вашего тест-кейса.

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

По написанию ожидаемых результатов можно порекомендовать следующее:

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

Внимание! Частая ошибка! В ожидаемых результатах ВСЕГДА описывается КОРРЕКТНАЯ работа приложения. Нет и не может быть ожидаемого результата в виде «приложение вызывает ошибку в операционной системе и аварийно завершается с потерей всех пользовательских данных».

При этом корректная работа приложения вполне может предполагать отображение сообщений о неверных действиях пользователя или неких критических ситуациях. Так, сообщение «Невозможно сохранить файл по указанному пути: на целевом носителе недостаточно свободного места» — это не ошибка приложения, это его совершенно нормальная и правильная работа. Ошибкой приложения (в этой же ситуации) было бы
отсутствие такого сообщения, и/или повреждение, или потеря записываемых данных.

Для более глубокого понимания принципов оформления тест-кейсов рекомендуется прямо сейчас ознакомиться с главой «Типичные ошибки при разработке чек-листов, тест-кейсов и наборов тест-кейсов».

Свойства качественных тест-кейсов

Даже правильно оформленный тест-кейс может оказаться некачественным, если в нём нарушено одно из следующих свойств.

Правильный технический язык, точность и единообразие формулировок. Это свойство в равной мере относится и к требованиям, и к тест-кейсам, и к отчётам о дефектах — к любой до-
кументации. Основные идеи уже были описаны (см. главу «Атрибуты (поля) тест-кейсов»), а из самого общего и важного напомним и добавим:

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

Баланс между специфичностью и общностью. Тест-кейс считается тем более специфичным, чем более детально в нём расписаны конкретные действия, конкретные значения и т. д., т. е. чем в нём больше конкретики. Соответственно, тест-кейс считается тем более общим, чем в нём меньше конкретики.

Рассмотрим поля «шаги» и «ожидаемые результаты» двух тест-кейсов (подумайте, какой тест-кейс вы бы посчитали хорошим, а какой — плохим и почему):

Тест-кейс 1:

Шаги Ожидаемые результаты
Конвертация из всех поддерживаемых кодировок
Приготовления:
— Создать папки C:/A, C:/B, C:/C, C:/D.
— Разместить в папке C:/D файлы 1.html, 2.txt, 3.md из прилагаемого архива.
1. Запустить приложение, выполнив команду php converter.php c:/a c:/b c:/c/converter.log.
2. Скопировать файлы 1.html, 2.txt, 3.md из папки C:/D в папку C:/A.
3. Остановить приложение нажатием Crtl+C.		 1. Отображается консольный журнал приложения с сообщением «текущее_время started, source dir c:/a, destination dir c:/b, log file c:/c/converter.log», в папке C:/C появляется файл converter.log, в котором появляется запись «текущее_время started, source dir c:/a, destination dir c:/b, log file c:/c/converter.log».
2. Файлы 1.html, 2.txt, 3.md появляются в папке C:/A, затем пропадают оттуда и появляются в папке C:/B. В консольном журнале и файле C:/C/converter.log появляются сообщения (записи) «текущее_время processing 1.html (KOI8-R)», «текущее_время processing 2.txt (CP-1251)», «текущее_время processing 3.md (CP-866)».
3. В файле C:/C/converter.log появляется запись «текущее_время closed». Приложение завершает работу.

Тест-кейс 2:

Шаги Ожидаемые результаты
Конвертация из всех поддерживаемых кодировок
1. Выполнить конвертацию трёх файлов до пустимого размера в трёх разных кодировках всех трёх допустимых форматов.		 1. Файлы перемещаются в папку-приёмник, кодировка всех файлов меняется на UTF-8.

Если вернуться к вопросу «какой тест-кейс вы бы посчитали хорошим, а какой — плохим и почему», то ответ таков: оба тест-кейса плохие потому, что первый является слишком специфичным, а второй — слишком общим. Можно сказать, что здесь до абсурда доведены идеи низкоуровневых и высокоуровневых тест-кейсов.

Почему плоха излишняя специфичность (тест-кейс 1):

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

Почему плоха излишняя общность (тест-кейс 2):

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

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

Вот пример такого срединного подхода:

Тест-кейс 3:

Шаги Ожидаемые результаты
Конвертация из всех поддерживаемых кодировок
Приготовления:
— Создать в корне любого диска четыре отдельные папки для входных файлов, выходных файлов, файла журнала и временного хранения тестовых файлов.
— Распаковать содержимое прилагаемого архива в папку для временного хранения тестовых файлов.
1. Запустить приложение, указав в параметрах соответствующие пути из приготовления к тесту (имя файла журнала — произвольное).
2. Скопировать файлы из папки для временного хранения в папку для входных файлов.
3. Остановить приложение.		 1. Приложение запускается и выводит сообщение о своём запуске в консоль и файл журнала.
2. Файлы из папки для входных файлов перемещаются в папку для выходных файлов, в консоли и файле журнала отображаются сообщения о конвертации каждого из файлов с указанием его исходной кодировки.
3. Приложение выводит сообщение о завершении работы в файл журнала и завершает работу.

В этом тест-кейсе есть всё необходимое для понимания и выполнения, но при этом он стал короче и проще для выполнения, а отсутствие строго указанных значений приводит к тому, что
при многократном выполнении тест-кейса (особенно — разными тестировщиками) конкретные параметры будут менять свои значения, что увеличивает вероятность обнаружения ошибки.

Ещё раз главная мысль: сами по себе специфичность или общность тест-кейса не являются чем-то плохим, но резкий перекос в ту или иную сторону снижает качество тест-кейса.

Баланс между простотой и сложностью. Здесь не существует академических определений, но принято считать, что простой тест-кейс оперирует одним объектом (или в нём явно виден
главный объект), а также содержит небольшое количество тривиальных действий; сложный тест-кейс оперирует несколькими равноправными объектами и содержит много нетривиальных
действий.

Преимущества простых тест-кейсов:

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

Преимущества сложных тест-кейсов:

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

Рассмотрим примеры.

Шаблон тестового сценария по стандартам WorldSkills (демо-экзамен) с комментариями

Для выполнения процедуры тестирования удаления товаров Вам нужно описать пять сценариев.

Удаление может быть выполнимо, а может быть отклонено согласно требованиям предметной области.

Необходимо, чтобы варианты тестирования демонстрировали различные исходы работы алгоритма. Для описания тестовых сценариев в ресурсах предоставлен шаблон testing-template.docx (есть в этом репозитории в каталоге docs).

Расшифровка тестовых информационных полей:

Поле Описание
Название проекта Название тестируемого проекта
Рабочая версия Версия проекта/программного обеспечения (первый тест считается 1.0).
Имя тестирующего Имя того, кто проводил тесты
Дата(ы) теста Дата(ы) проведения тестов – это один или несколько дней. Если тесты проводились в более протяженный период времени, нужно отметить отдельную дату для каждого теста.
Тестовый пример # Уникальный ID для каждого тестового примера. Следуйте некоторым конвенциям, чтобы указать типы тестов. Например,‘TC_UI_1′ означает‘user interface test case #1′ ( ТС_ПИ_1: тестовый случай пользовательского интерфейса#1)
Приоритет тестирования (Низкий/Средний/Высокий) Насколько важен каждый тест. Приоритет тестирования для бизнес-правил и функциональных тестовых случаев может быть средним или высоким, в то время как незначительные случаи пользовательского интерфейса могут иметь низкий приоритет.
Заголовок/название теста Название тестового случая. Например, Подтвердите страницу авторизации с действительным именем пользователя и паролем.
Краткое изложение теста Описание того, что должен достичь тест.
Этапы теста Перечислите все этапы теста подробно. Запишите этапы теста в том порядке, в котором они должны быть реализованы. Предоставьте как можно больше подробностей и разъяснений. Пронумерованный список – хорошая идея.
Тестовые данные Перечислите/опишите все тестовые данные, используемые для данного тестового случая. Так, фактические используемые входные данные можно отслеживать по результатам тестирования. Например, Имя пользователя и пароль для подтверждения входа.
Ожидаемый результат Каким должен быть вывод системы после выполнения теста? Подробно опишите ожидаемый результат, включая все сообщения/ошибки, которые должны отображаться на экране.
Фактический результат Каким должен быть фактический результат после выполнения теста? Опишите любое релевантное поведение системы после выполнения теста.
Предварительное условие Любые предварительные условия, которые должны быть выполнены до выполнения теста. Перечислите все предварительные условия для выполнения этого тестового случая.
Постусловие Каким должно быть состояние системы после выполнения теста?
Статус (Зачет/Незачет) Если фактический результат не соответствует ожидаемому результату, отметьте тест как неудачный. В ином случае обновление пройдено.
Примечания/комментарии Используйте эту область для любых дополнительных заметок/комментариев/вопросов. Эта область предназначена для поддержки вышеуказанных полей (например, если есть некоторые особые условия, которые не могут быть описаны в любом из вышеуказанных полей, или если есть вопросы, связанные с ожидаемыми или фактическими результатами).

Аннотация теста

    Мои комментарии
Название проекта DoeduSam
Рабочая версия 1.0 Эту версию не плохо бы вписать в свойства проекта
Имя тестирующего DEMO_xx
Дата(ы) теста 21.12.2020 текущая

Тестовый пример #1:

    Мои комментарии
Тестовый пример # TC_DP_1 расшифровывается: TestCase_DeleteProduct_x
Приоритет тестирования средний бизнес-правило
Заголовок/название теста Удаление товара без продаж и дополнительных товаров
Краткое изложение теста Товар должен без ошибок удалиться из таблицы товаров
Этапы теста 1. Очистить таблицы продаж, дополнительных товаров, дополнительных картинок и товаров. 2. Добавить тестовый товар в таблицу Products
3. Вызвать метод удаления товара
4. Проверить наличие удаленной записи в таблице
Тестовые данные Название: Моторное масло Motor Oil KE900-90042-R
Изображение: Товары автосервиса8FE07916.jpg
Производитель: Nissan
Активен: да
Цена: 2060		 Тут нужно вставить содержимое любой записи из products_a_import
Ожидаемый результат Запись должна быть удалена из таблицы без ошибок и исключений
Фактический результат Запись удалена
Статус зачет
Предварительное условие В базу должны быть загружен тестовый продукт
Постусловие Таблица товаров должна быть пустой
Примечания/комментарии Т.к. мы добавили только товар без продаж и дополнительных товаров, то ошибок в принципе быть не может ни по вине кода ни по ограничениям базы

Что еще можно проверить

  • №2 — удаление товара с дополнительными товарами. Если ограничения настроены правильно (каскадное удаление), то тоже долно удаляться нормально.

  • №3 — удаление товара с дополнительными картинками. Аналогично №2.

  • №4 — удаление товара с продажами. Вариант без предварительной проверки — база должна вернуть ошибку, приложение это исключение должно перехватить и выдать сообщение, что удалять нельзя.

  • №5 — удаление товара с продажами. Вариант с предварительной проверкой — в коде нужно проверить есть ли у товара продажи и при наличии продаж вывести сообщение, что удалять товар нельзя.

Источник

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

Для начинающих поясним, что такое тест-кейс озвучив определение из глоссария терминов ISTQB: 

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

Определение тест-кейса языком обывателя: 

Тест-кейс — это чёткое описание действий, которые необходимо выполнить, для того чтобы проверить работу программы (поля для ввода, кнопки и т.д.). Данное описание содержит: действия, которые надо выполнить до начала проверки — предусловия; действия, которые надо выполнить для проверки — шаги; описание того, что должно произойти, после выполнения действий для проверки — ожидаемый результат. 

Надеюсь, теперь многим стало понятно, что такое тест-кейс. Теперь перейдём к правилам написания тест-кейсов, которые вырабатывались не один год и показывают свою эффективность до сих пор. 

Обязательные атрибуты для заполнения 

  • Номер тест-кейса — уникальный идентификатор тест-кейса (такие системы как TestRail, TestLink и подобные автоматически присваивают тест-кейсам уникальные номера). Если у вас тысячи тест-кейсов, то при общении с коллегами, вам будет удобнее сообщить номер тест-кейса ссылаясь на него, а не пытаться словами рассказать, где и как найти определённый тест-кейс. 
  • Заголовок — краткое, понятное и ёмкое описание сути проверки. 
  • Предусловия — описание действий, которые необходимо предварительно выполнить или учесть, и которые не имеют прямого отношения к проверке. 
  • Шаги проверки — описание последовательности действий, которые необходимо выполнить для проверки. 
  • Ожидаемый результат — проверка, которая устанавливает, что мы ожидаем получить, после выполнения определённых действий в соответствующем шаге. 

В зависимости от специфики компании могут присутствовать дополнительные атрибуты для заполнения: приоритет, функциональный блок, программа, ссылка на требование, номер требования и т.д. 

Правила написания тест-кейсов 

  1. Заголовок:
    • должен быть чётким, кратким, понятным и однозначно характеризующим суть тест-кейса;
    • не может содержать выполняемые шаги и ожидаемый результат.
  2. Предусловие:
    • может содержать полную информацию о состоянии системы или объекта, необходимом для начала выполнения шагов тест-кейса; 
    • может содержать ссылки на информационные источники, которые необходимо изучить перед прохождением тест-кейса (инструкции, описание систем…); 
    • не может содержать ссылки на тестируемый ресурс, если у информационной системы более одной среды (прод, тест, препрод…), данная информация должна быть вынесена в инструкцию, и ссылка приложена в предусловии; 
    • не может содержать данные для авторизации, данная информация должна быть вынесена в инструкцию, и ссылка приложена в предусловии; 
    • не может содержать выполняемые шаги и ожидаемый результат, если нам нужно, чтобы до выполнения шагов проверки у нас была открыта главная страница, то мы в предусловии указываем «открыта главная страница сайта»; 
    • не может содержать ожидаемый результат. 
  3. Шаги проверки: 
    • должны быть чёткими, понятными и последовательными; 
    • следует избегать излишней детализации шагов. Правильно: «ввести в поле число 12».
      Неправильно: «нажать на клавиатуре на цифру ‘1’, следующим шагом нажать на клавиатуре на цифру ‘2’»; 
    • должны использоваться безличные глаголы.
      Правильно: нажать, ввести, перейти.
      Неправильно: нажмите, введите, идите; 
    • не должно быть комментариев и пояснений, если есть необходимость привести мини-инструкцию, то оформляем инструкции в базе-знаний и в предусловии ссылаемся на неё; 
    • не должно быть жёстко прописанных статических данных (логины, пароли, имена файлов) и примеров, для исключения эффекта пестицида. 
  4. Ожидаемый результат: 
    • должен быть у каждого шага проверки; 
    • должно быть кратко и понятно описано состояние системы или объекта, наступающее после выполнения соответствующего шага; 
    • не должно быть избыточного описания. 
  5. Общие требования к тест-кейсам: 
    • язык описания тест-кейсов должен быть понятен широкому кругу пользователей, а не узкой группе лиц; 
    • тест-кейс должен быть максимально независим от других тест-кейсов и не ссылаться на другие тест-кейсы (лучшая практика, когда зависимостей нет вообще); 
    • тест-кейсы группируются в функциональные блоки по их назначению; 
    • в тест-кейсах проверяющих работу функционала скриншотов быть не должно, иначе вы будете посвящать сотни часов на изменение всех скриншотов в тысячах тест-кейсах при изменении интерфейса тестируемой программы. Скриншоты могут быть добавлены только в тест-кейсы проверяющие отображение страниц и форм. 

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

Примеры 

Для наглядности приведу пару примеров. Рассмотрим на примере сайта, на котором вы сейчас находитесь. 

Тест-кейс №1. Корректный

Номер 1 
Заголовок  Отправка сообщения через форму обратной связи на странице “Контакты” 
Предусловие  Открыта главная страница сайта victorz.ru. Есть доступ к почте администратора сайта victorz.ru 
   
Шаг  Ожидаемый результат 
В верхнем меню сайта нажать на ссылку “Контакты”  Открылась страница “Контакты” 
Ввести значение в поле “Ваше имя” состоящее из латинских букв, кириллицы  В поле “Ваше имя” отображается введённое имя 
Ввести корректный email в поле “Ваш e-mail”  В поле “Ваш e-mail” отображается введённый email 
Ввести в поле “Тема” значение состоящее из латинских букв, кириллицы, спецсимволов и чисел  В поле “Тема” отображается введённый текст 
Ввести в поле “Сообщение” значение состоящее из латинских букв, кириллицы, спецсимволов и чисел  В поле “Сообщение” отображается введённый текст 
Ввести в поле капчи требуемое капчей значение  В поле капчи отображается введённое значение 
Нажать под заполняемой формой на кнопку “Отправить”  Под кнопкой «Отправить» появился текст “Спасибо. Ваше сообщение было отправлено.”
Все заполненные поля очищены.
Проверить почту администратора сайта  На почту пришло сообщение, отправленное с сайта через форму обратной связи и содержащее в теле сообщения данные введённые на шагах 1-5. 

Тест-кейс №2. Некорректный 

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

Номер  1 
Заголовок  Отправить сообщение через форму обратной связи (Указываем, что проверяем или что делаем?) 
Предусловие  Перейти на главную страницу сайта victorz.ru (Это не предусловие, а описание шага) 
   
Шаг  Ожидаемый результат 
Нажать на ссылку “Контакты” (Где она находится?)  Открылась страница (Какая?) 
Ввести имя в поле “Ваше имя” (Какие символы вводить?)  (Ничего не указано в ожидаемом результате, что должно произойти?) 
Ввести email в поле “Ваш e-mail” (корректный или некорректный?)  В поле отображается email (Какой? Введённый? В каком поле отображается?) 
Ввести в поле значение, состоящее из латинских букв, кириллицы, спецсимволов и чисел (В какое поле?)  В поле “Тема” отображается текст (Какой?) 
Ввести в поле “Сообщение” текст (Какие символы вводить?)  Видим в поле “Сообщение” введённый текст (Видим или отображается?) 
Вводим в поле капчи требуемое капчей значение (Помните только безличные глаголы — Ввести).  В поле капчи будет введённое значение (Что будет делать? Танцевать?) 
Нажать под заполняемой формой на кнопку (На какую?)  Появился текст “Спасибо. Ваше сообщение было отправлено.” (Где появится?) 
(Последний шаг не заполнен, а это неправильно, так как мы не проверим действительно ли работает отправка писем через форму обратной связи)   

Во второй части видео (с 8-й минуты) разбираю на примерах создание тест-кейсов:

Главное в нашем деле практика. Практикуйтесь в написании тест-кейсов. 

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

Источник

В тестировании, чтобы проверить, корректно ли работает программное обеспечение (ПО), делают определенные действия и сверяют полученный результат с ожидаемым. Другими словами — моделируют ситуацию работы ПО. Чтобы описать шаги, создают тест-кейсы.

Что такое тест-кейсы

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

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

Отличия

🚀 От чек-листа

В чек-листе перечисляют аспекты ПО, которые нужно проверить. Когда составляют тест-кейс, описывают состояние программного обеспечения и то, как его изменяют. То есть чек-листом определяют, что тестировать. А тест-кейсом — как тестировать. Чек-лист подойдет в качестве исходного документа, чтобы составить тест-кейсы.

🚀 От баг-репорта

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

Виды тест-кейсов

Классификация зависит от типа входных данных, действий и ожидаемого поведения ПО.

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

2️⃣ Отрицательные. Показывают, что ПО способно обрабатывать некорректные входные данные или неверные действия пользователя. Например, выводить соответствующие сообщения, подсказывать, как исправить ситуацию.

3️⃣ Деструктивные. Демонстрируют, что никакие внешние воздействия или высокие нагрузки не приводят к потере данных пользователя, ПО можно использовать. Условие: нагрузки не разрушают аппаратную часть.

Пример 

У вас есть требование к программной системе расписания занятий: «В систему нужно добавлять новые уроки».

Положительные тест-кейсы должны демонстрировать, что, если ввести корректные данные, новый урок появится в расписании.

Негативные попытаются сломать нормальную работу системы. Например, если добавляют урок, когда нет места в расписании, или не указывают его название.

Деструктивные покажут, сохранится ли расписание при сбоях. Например, если внезапно завершат программу или введут огромное количество данных за короткое время.

Жизненный цикл

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

1️⃣ Не запускался. Тест-кейс создали, но тестирование по нему не проводили.

2️⃣ Пройден успешно. Ожидаемые и фактические результаты работы ПО совпадают.

3️⃣ Провален. Обнаружили дефект: ожидаемый результат минимум по одному шагу тест-кейса не совпадает с фактическим.

4️⃣ Пропущен. Тест-кейс отменили. Например, потому что изменили требования к ПО.

Обязательные атрибуты

Они тоже зависят от внутренней культуры компании или возможностей систем управления тест-кейсами. И даже от типа тестируемого ПО. Но обычно выделяют следующие атрибуты:

✅ Уникальный идентификатор — некое уникальное значение. По нему на тест-кейс ссылаются из других документов или тест-кейсов. Бывает буквенным, числовым, буквенно-числовым. Чаще всего применяют простую сквозную нумерацию.

✅ Краткое описание — лаконичное описание сути тест-кейса. Может содержать ссылку на требование к ПО.

✅ Входные данные — сведения о первоначальном состоянии системы, которое важно для тест-кейса. А еще значения для ввода или передачи ПО.

✅ Шаги — полная последовательность действий. Ее выполняют, чтобы провести описываемую тест-кейсом проверку.

✅ Ожидаемый результат — описание планируемого поведения или результата ПО. Может базироваться на требовании к программному обеспечению, общей логике работы.

✅ Фактический результат — описание итогового поведения или результата ПО. Если они совпадают, это указывают. Когда не совпадают, подробно описывают расхождения. Пометка «не совпадает», «отличается» — это грубая ошибка.

✅ Статус — текущее состояние тест-кейса.

Правила составления тест-кейса

👉 Создавайте простые тест-кейсы. То есть лаконичные и понятные не только вам. Используйте повелительное наклонение, например: «перейдите на домашнюю страницу», «введите данные», «нажмите здесь». Шаги должны быть четкие, без лишних деталей. Так проще понять шаги теста и ускорить работу.

👉 Учитывайте интересы конечного пользователя. Конечная цель любого программного проекта — простое и понятное приложение, отвечающее запросу клиентов. Тестировщик создает тест-кейсы с учетом мнения конечного пользователя.

👉 Избегайте повторов. Если тест-кейс нужен, чтобы выполнить другой тест-кейс, оставьте ссылку по идентификатору в столбце предварительного условия.

👉 Не предполагайте. Не додумывайте функциональность и возможности ПО. Строго придерживайтесь спецификации.

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

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

👉 Внедряйте методы тестирования. Эти техники помогают спланировать несколько тест-кейсов и находить ошибки:

  • анализ граничных значений — проверяйте верхние и нижние границы для допустимого диапазона значений;
  • эквивалентное разделение — разбивайте диапазон всевозможных тест-кейсов на равные части/группы с одинаковым поведением;
  • техника перехода состояний — создавайте тест-кейсы, которые покроют поведение ПО при переходе из одного состояния в другое.

👉 Внедряйте самоочистку. Тест-кейс должен возвращать среду в предтестовое состояние. Особенно это касается тестирования конфигураций.

👉 Создавайте повторяемые и самостоятельные текст-кейсы. Они должны всегда генерировать одинаковые результаты: независимо от того, кто их тестирует.

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

Учитесь создавать тест-кейсы и системы управления ими на курсе «Инженер по тестированию» Skypro. Кроме этого узнаете, как писать чек-листы и тест-планы, составлять отчеты в системах отслеживания ошибок. Проведете функциональное, UX/UI- и регрессионное тестирование — и это только в одном модуле. На курсе рассмотрим еще и тестирование мобильных приложений и API, инструменты тестировщика.

На курсе больше 330 часов теории и практики, пройдете 7 мастер-классов, создадите 4 проекта для портфолио. Доступ к материалам останется навсегда.

Шаблон и пример тест-кейса

Идентификатор Описание Шаги Входные данные Ожидаемые результаты Фактические результаты Статус
TU01 Проверка входа пользователя с существующими логином и паролем Откройте сайт http://blahblahblah.ru

↓

Введите логин

↓

Введите пароль

↓

Нажмите кнопку «Войти»

 Логин = user99 Пароль = pass99 Пользователь должен попасть на главную страницу Как ожидали Пройден успешно
TU02 Проверка входа пользователя с несуществующими логином и паролем Откройте сайт http://blahblahblah.ru

↓

Введите логин

↓

Введите пароль

↓

Нажмите кнопку «Войти»

 Логин = user99 Пароль = badlass99 Пользователь должен остаться на странице логина. Появится сообщение «Неверные логин или пароль» Как ожидали Пройден успешно

Главное о тест-кейсах

  • Тест-кейс — это четкое описание входных данных, условий выполнения, процедуры тестирования и ожидаемых результатов.
  • Исходным документом для тест-кейсов может быть чек-лист. Проваленный тест-кейс служит источником данных для баг-репорта.
  • Обязательные атрибуты тест-кейса: уникальный идентификатор, краткое описание, входные данные. А еще шаги, ожидаемый результат, фактический результат, статус.
  • От правильности написания тест-кейсов зависит качество тестирования. Создавайте простые тест-кейсы с учетом интересов конечного пользователя. Избегайте повторов и не предполагайте, пишите тестовые примеры. Внедряйте методы тестирования, самоочистку, консультируйтесь с экспертами.
Источник



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



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

В статье рассказывается:

  1. Что такое тест-кейс
  2. Атрибуты тест-кейса
  3. Отличия тест-кейсов от чек-листов
  4. Плюсы и минусы тест-кейсов
  5. Виды тест-кейсов
  6. Правила разработки тест-кейсов
  7. Ошибки при создании тест-кейсов

  8. Пройди тест и узнай, какая сфера тебе подходит:
    айти, дизайн или маркетинг.

    Бесплатно от Geekbrains

Что такое тест-кейс

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

Словарь терминов некоммерческой организации, занимающейся сертификацией в области тестирования (ISTQB), предлагает следующее определение тест-кейса: «… набор входных значений, предусловий выполнения, ожидаемых результатов и постусловий выполнения, разработанный для определенной цели или тестового условия, таких как выполнение определенного пути программы или же для проверки соответствия определенному требованию».

Комплект из нескольких тест-кейсов принято называть тестовым набором (test suite). Не путайте с понятием тест-плана. Оно обозначает именно планирование работы: что, когда, зачем, как и т.д.

Что такое тест-кейс

Что такое тест-кейс

Атрибуты тест-кейса

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

  • Уникальный идентификационный номер, состоящий из комбинации букв и цифр.
  • Заголовок. Описывает цель тест-кейса. К примеру, тест-кейс для тестирования страницы входа может иметь заголовок «Проверка входа пользователя с верными данными».
  • Предусловия. Шаги, предваряющие реализацию тест-кейса. При определенных условиях требуется ввод учетных данных.
  • Шаги. Изложение действий, составляющих проверку.
  • Постусловия. Список действий, необходимых для восстановления системы до исходного состояния. Указываются, если есть необходимость.
  • Ожидаемый результат. Предполагаемый результат, к которому мы придем после реализации тест-кейса.
  • Фактический результат. Состояние системы после совершения всех действий тест-кейса(не является обязательным).
  • Статус. Успех (Success)/ провал (Failed)/ блокировка (Blocked). Отмечается не всегда, если требуется.

Скачать файл

К некоторым формам тест-кейсов добавляют и другие атрибуты. Среди них:

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

Отличия тест-кейсов от чек-листов

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

Что такое скрипт: применение, языки написания

Читайте также

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

Плюсы и минусы тест-кейсов

Главное достоинство тест-кейса состоит в том, что его может провести практически любой сотрудник компании, не имеющий отношения к работе над проектом. Если к созданию тест-кейса подошли ответственно, исполнитель справится с ним без труда.

Плюсы и минусы тест-кейсов

Плюсы и минусы тест-кейсов

Минусы такого типа тестирования тесно взаимосвязаны.

  • Заполнение требует долгой монотонной работы. Например, при тестировании корректного ввода ФИО надо выполнять простейшие одинаковые шаги: «ввести только символы, «ввести только числа» и т.д. Это особенно заметно, если посмотреть несколько тест-кейсов на один и тот же функционал.
  • Затратное по времени редактирование. Малейшее изменение содержания сайта требует коррекции сотен сценариев тест-кейса. Не самое увлекательное и довольно выматывающее занятие.
  • Некорректность тест-кейсов. Возникает из-за того, что при создании нового берутся элементы старого, которые не поменяли.

pdf иконка

Топ-30 самых востребованных и высокооплачиваемых профессий 2022

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

doc иконка

Подборка 50+ ресурсов об IT-сфере

Только лучшие телеграм-каналы, каналы Youtube, подкасты, форумы и многое другое для того, чтобы узнавать новое про IT

pdf иконка

ТОП 50+ сервисов и приложений от Geekbrains

Безопасные и надежные программы для работы в наши дни

Уже скачали 18556
pdf иконка

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

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

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

Виды тест-кейсов

Тест-кейсы делят на несколько групп в зависимости от входных данных, действий и предполагаемого поведения системы.

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

Пример.

Надо проверить требование к системе записи клиентов в салон красоты: «В систему нужно добавлять новые филиалы и мастеров».

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

При проведении негативных тест-кейсов тестировщик проверяет, как реагирует система при некорректном введении данных. Например, при вводе неполного адреса салона или одного и того же мастера дважды.

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

Правила разработки тест-кейсов

При разработке тест-кейсов учитывают следующие требования для каждого из его атрибутов.

Заголовок

  • важна четкая короткая формулировка, ясно выражающая суть тест-кейса;
  • не должен включать ожидаемый результат и выполняемые шаги.

pdf иконка

Точный инструмент «Колесо компетенций»

Для детального самоанализа по выбору IT-профессии

pdf иконка

Список грубых ошибок в IT, из-за которых сразу увольняют

Об этом мало кто рассказывает, но это должен знать каждый

doc иконка

Мини-тест из 11 вопросов от нашего личного психолога

Вы сразу поймете, что в данный момент тормозит ваш успех

Регистрируйтесь на бесплатный интенсив, чтобы за 3 часа начать разбираться в IT лучше 90% новичков.

Только до 6 февраля

Осталось 17 мест

Предусловие

  • подробно описывает состояние объекта или системы, требуемое для выполнения шагов тест-кейса;
  • список источников информации (описание системы, инструкции), которые тестировщик должен прочитать перед тем, как начать выполнение тест-кейса;
  • если тестируемая информационная система обладает несколькими средами (прод, тест, препрод…), предусловие не должно включать ссылки на нее. Информацию о ресурсе следует разместить в инструкции, а ссылку добавить в предусловие.
  • не прописываются данные для авторизации, их размещают в инструкции, оставляя ссылку в поле тест-кейса для предусловия;
  • не должно включать ожидаемый результат и выполняемые шаги. Если есть необходимость держать открытой главную страницу сайта перед тем, как приступаем к шагам проверки, в предусловии отмечается: «открыта главная страница сайта»;
  • не должно описывать ожидаемый результат.

Правила разработки тест-кейсов

Правила разработки тест-кейсов

Шаги проверки

  • ключевые качества: доступность, четкость, последовательность;
  • важно избавляться от чрезмерной подробности в описании. Например, вместо «первый шаг — нажать на клавиатуре цифру 2, второй шаг — нажать на клавиатуре цифру 5», следует писать «ввести число 25 в данном поле»;
  • применяются только глаголы в неопределенной форме: ввести, нажать, удалить и т.д. Недопустимо: введите, нажмите, удалите;
  • если требуется добавить комментарии или пояснения, они размещаются в виде инструкции в базе знаний, а в предусловии размещаем ссылку на нее;
  • не допускаются конкретные статистические данные (названия файлов, логины и пароли) и примеры, во избежание эффекта пестицида.

Ожидаемый результат

  • описывается у каждого шага проверки;
  • содержит внятное и краткое описание состояния, в которое приходит программа или объект после реализации конкретного шага;
  • не допустимы лишние описания.

Общие требования к тест-кейсам

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

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

Ошибки при создании тест-кейсов

Посмотрим, как правильно писать тест-кейсы и какие ошибки в них недопустимы.

  • Слишком обобщенное название тест-кейса

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

Неправильно: Уведомление пользователя об отсутствии интернет-соединения.
Правильно: Уведомление пользователя о потере Wi-Fi сигнала вручную.

Операторы SQL: какие есть и как с ними работать

Читайте также

  • Употребление повелительного наклонения в тест-кейсе

Дело не в практической целесообразности, а в элементарной вежливости.

Неправильно: перейди на страницу; введи значение и т.д.
Правильно: перейти на страницу; ввести значение и т.д.

  • Некликабельные ссылки

Это касается как гиперссылок внутри программы, так и внешних ресурсов. Каждую ссылку надо делать кликабельной с помощью Ctrl + K.

  • Слишком подробные описания действий

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

Неправильно: Наведите мышку и нажмите на зеленую кнопку внизу страницы посередине с надписью «Согласен».

Правильно: Нажмите на кнопку «Согласен».

  • Слишком краткое описание действий

Правильный тест-кейс лаконичен, но при этом не требует дополнительных объяснений.

Неправильно: Открыть меню «Дополнительные возможности».
Правильно:

  • Нажать на иконку «Профиль».
  • Перейти во вкладку «Настройки».
  • Выбрать пункт «Дополнительные возможности».

Приоритет тест-кейсов и чек-листов заключается в том, что они делают процесс тестирования программного обеспечения структурированным и доступным для неспециалистов. В чек-листах прописываются объекты проверки, а в тест-кейсах — пошаговый алгоритм.

Ошибки при создании тест-кейсов

Ошибки при создании тест-кейсов

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

Источник
  • Что такое тест-кейс и зачем он нужен
  • Чем отличаются тест-кейс и чеклист
  • Типы тест-кейсов
  • Атрибуты тест-кейса ручного тестирования
  • Характеристики хорошего тест-кейса
  • Лучшие практики в написании тест-кейсов
  • Формирование тест-кейсов
  • Примеры тест-кейсов ручного тестирования
    • Позитивный
    • Деструктивный
    • Негативный
  • Итоги: тестирование тест-кейса

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

Что такое тест-кейс и зачем он нужен

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

Тестировщик создает тест-кейс, чтобы проверить, работает ли определенная фича должным образом, и чтобы подтвердить, что функционал, UI/UX и другие параметры системы удовлетворяют всем соответствующим стандартам, руководствам и требованиям клиентов.

Чем отличаются тест-кейс и чеклист

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

Чеклист QA — это список того, что нужно протестировать. Благодаря ему процесс тестирования проходит более четко и аккуратно.

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

Позитивные, негативные и деструктивные тест-кейсы

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

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

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

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

Если вернуться к нашему примеру, пользователь не должен иметь возможность создать пароль, состоящий из 11 символов.

Деструктивные тест-кейсы создаются, чтобы узнать предел прочности системы. Нагрузочное тестирование — распространенный вариант деструктивного тестирования. 

Для деструктивного тестирования QA-специалисты могут применять следующие методы:

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

Атрибуты тест-кейса для ручного тестирования

Как и все тестировочные документы, тест-кейс имеет определенный формат. Он содержит следующие атрибуты:

  1. ID — уникальное сочетание букв и цифр.
  2. Заголовок — основная идея тест-кейса, краткое описание его сути. Например, заголовок тест-кейса для ручного тестирования страницы входа может выглядеть следующим образом: «Проверить вход пользователя с корректными данными».
  3. Предусловия — список действий, которые необходимо выполнить перед выполнением тест-кейса. При необходимости здесь могут указываться учетные данные.
  4. Шаги — описание действий, необходимых для проверки.
  5. Постусловия — список действий, возвращающих систему в исходное состояние (указывается при необходимости).
  6. Ожидаемый результат — то, что мы ожидаем получить после успешного выполнения тест-кейса.
  7. Фактический результат — то, что мы получаем после выполнения тест-кейса (указывается при необходимости).
  8. Статус — Success (успех), Failed (провал), Blocked (блокировка) (указывается при необходимости).

Кроме того, для некоторых тест-кейсов могут потребоваться дополнительные атрибуты:

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

Характеристики хорошего тест-кейса

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

Короче говоря, хороший тест-кейс:

  • понятен любому члену команды;
  • аккуратно и точно написан;
  • соответствует требованиям;
  • воспроизводим;
  • пригоден для многократного использования.

Best practices в написании тест-кейсов

Под  best practices мы подразумеваем правила, которые помогают создавать простые, понятные и полезные тест-кейсы:

  • Перед созданием нового тест-кейса убедитесь, что он не дублирует ни один из уже существующих в системе.
  • Убедитесь, что тест-кейс покрывает 100% требований, которые вы должны проверить.
  • Помните о теории методов тестирования, таких как анализ граничных значений, разделение эквивалентности, техника перехода состояния, угадывание ошибок.
  • Помимо требований к системе, всегда помните о конечном пользователе, который будет взаимодействовать с системой.
  • Не забудьте указать учетные данные, если они необходимы для выполнения теста.
  • Позаботьтесь о тестировщиках, которые будут работать с этим тест-кейсом в будущем. В частности, убедитесь, что все ссылки верны и кликабельны. Пожалуйста, не используйте ссылки на продакшен.
  • Используйте повелительное наклонение, например: «Перейдите на главную страницу», «Введите данные», «Кликните» и т. д. Такая формулировка упрощает понимание этапов тестирования и ускоряет их выполнение.

Формирование тест-кейсов

Обычно при написании тест-кейсов тестировщики пользуются таблицами Excel. Но вы также можете использовать инструменты управления тестированием, такие как TestRail.

Примеры тест-кейсов для ручного тестирования

Позитивный тест-кейс

Давайте попробуем создать наш собственный тест-кейс для ручного тестирования функции поиска на e-commerce сайте компании FootWear. Начнем с позитивного теста.

ID: FWSF-1. (Лучше использовать числа в возрастающем порядке. FWSF = FootWear Search Functionality. Попробуйте придумать комбинацию букв, имеющую отношение к проекту или функции, которую вы собираетесь тестировать).

Заголовок: Проверить результаты поиска с корректными входными данными. (Узнать, какие значения допустимы, мы можем в требованиях).

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

Шаги:

  1. Откройте домашнюю страницу. (Ссылка не обязательна, ее наличие может затруднить поддержку тест-кейса в будущем).
  2. Введите в поле поиска ключевое слово, связанное с названием доступного продукта.
  3. Выполните поиск, кликнув значок поиска или нажав Enter.
  4. Проверьте результаты.

Ожидаемый результат: На странице результатов поиска отображаются все релевантные результаты.

Деструктивный тест-кейс

Еще один пример — деструктивный тест-кейс.

ID: FWSF-2.

Заголовок: Проверить устойчивость поиска к SQL-инъекциям.

Предусловия: Подготовьте SQL-запрос, который вы собираетесь вставить в поиск.

Шаги:

  1. Откройте домашнюю страницу.
  2. Введите SQL-запрос в поле поиска.
  3. Выполните поиск, кликнув значок поиска или нажав Enter.
  4. Проверьте, правильно ли отображаются результаты, нет ли сообщений об ошибках на странице результатов поиска.

Ожидаемый результат: Для защиты от SQL-инъекций отображение предупреждающих сообщений должно быть отключено.

Негативный тест-кейс

Наконец, вот вам негативный тест-кейс.

ID: FWSF-3.

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

Предусловия: Выпишите недопустимые значения для поля ввода поиска из системных требований.

Шаги:

  1. Откройте домашнюю страницу.
  2. Введите комбинацию недопустимых значений в поле поиска.
  3. Выполните поиск, кликнув значок поиска или нажав Enter.
  4. Проверьте, отображается ли предупреждающее сообщение «Пожалуйста, используйте только допустимые символы».

Ожидаемый результат: Отображается предупреждающее сообщение «Пожалуйста, используйте только допустимые символы». Поиск можно продолжить.

Итоги: тестирование тест-кейса

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

Источник

Тестовый сценарий (test case): Набор входных значений, предусловий выполнения, ожидаемых результатов и постусловий выполнения, разработанный для определенной цели или тестового условия, таких как выполнения определенного пути программы или же для проверки соответствия определенному требованию. (IEEE 610)

Тестовый сценарий высокого уровня (high level test case): Тестовый сценарий без конкретных (уровня реализации) значений входных данных и ожидаемых результатов. Использует логические операторы, а экземпляры реальных значений еще не определены и/или доступны. (ISTQB)

Тестовый сценарий низкого уровня (low level test case): Тестовый сценарий с конкретными (уровня реализации) значениями входных данных и ожидаемых результатов. Логические операторы из тестовых сценариев высокого уровня заменяются реальными значениями, которые соответствуют целям этих логических операторов. (ISTQB)

Test case (тест-кейс, тестовый пример/случай) — это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или ее части. Более строго — формализованное описание одной показательной проверки на соответствие требованиям прямым или косвенным.

  • Идентификатор набора тестов (Test Suite ID): Идентификатор набора тестов, в которых входит этот кейс;

  • Идентификатор тестового кейса (Test Case ID): Идентификатор самого кейса;

  • Заголовок кейса (Test Case Summary): Краткое и емкое название проводимой проверки;

  • Связанное требование (Related Requirement): Идентификатор требования, к которому относится / отслеживается данный тестовый пример;

  • Предварительные условия (Prerequisites): Любые предпосылки или предварительные условия, которые должны быть выполнены перед выполнением теста;

  • Шаги выполнения (Test Script / Procedure): Шаги выполнения теста;

  • Тестовые данные (Test Data): Тестовые данные или ссылки на тестовые данные, которые должны использоваться при проведении теста;

  • Ожидаемый результат (Expected Result): результат, который мы ожидаем получить после выполнения шагов теста;

  • Статус пройден или не пройден (Status): Другие статусы могут быть «Не выполнено», если тестирование не проводится, и «Заблокировано», если тестирование заблокировано;

  • Заметки (Remarks): Любые комментарии к тесту или выполнению теста;

  • Создано (Created By): Имя автора тестового примера;

  • Дата создания (Date of Creation): Дата создания тестового примера (опционально модификации);

  • Выполнено (Executed By): Имя человека, выполнившего тест;

  • Дата выполнения (Date of Execution): Дата выполнения теста;

  • Тестовое окружение (Test Environment): оборудование / программное обеспечение / сеть, в которых выполнялся тест, т.е. все необходимые сведения об окружении, чтобы можно было воспроизвести полученный результат.

В иностранной литературе часто делят кейсы на две категории:

  • Высокоуровневый тест-кейс (high level test case или logical test case) — тест-кейс без конкретных входных данных и ожидаемых результатов. Как правило, ограничивается общими идеями и операциями, схож по своей сути с подробно описанным пунктом чек-листа. Достаточно часто встречается в интеграционном тестировании и системном тестировании, а также на уровне smoke. Может служить отправной точкой для проведения исследовательского тестирования или для создания низкоуровневых тест-кейсов.

  • Низкоуровневый тест-кейс (low level test case) — тест-кейс с конкретными входными данными и ожидаемыми результатами. Представляет собой «полностью готовый к выполнению» тест-кейс и вообще является наиболее классическим видом тест-кейсов. Начинающих тестировщиков чаще всего учат писать именно такие тесты, т.к. прописать все данные подробно — намного проще, чем понять, какой информацией можно пренебречь, при этом не снизив ценность тест-кейса.

Нужно ли вообще писать кейсы? Ответ тот же, что и для любого документа — если написание кейсов решает определенную задачу и это обоснованно, то писать. Если вы один, не путаетесь в небольшом проекте, пользуетесь чек листами/mind map/.., можете и без TMS/test runs reports наглядно предоставлять актуальные сведения о протестированности/качестве заинтересованным лицам, то не писать.

Может ли быть несколько ожидаемых результатов? Может, если это необходимо, но сразу после каждого шага.

Можно ли объединять позитивные и негативные тест-кейсы? Позитивные можно, негативные нельзя, поскольку сложно будет понять, что именно влияет на результат.

Источник

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

Что же это за документы и как их сделать помощниками, а не врагами? Ответ на эти вопросы лежат в статье.

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

Тест-кейс

Тестовый случай, тестовый сценарий (test case) — набор входных значений, предусловий выполнения, ожидаемых результатов и постусловий выполнения, разработанный для определенной цели или тестового условия, таких как выполнения определенного пути программы или же для проверки соответствия определенному требованию. [IEEE 610]

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

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

Шаблон тест-кейса
Шаблон тест-кейса

1.ID — уникальный номер.
Обычно проставляется автоматически в системах хранения тест-кейсов.

2. Краткое описание тест-кейса (Name).
Название тест-кейса должно быть коротким и понятным. Оба эти слова важны.

Если мы сделаем название только коротким, то в таких кейсах будет очень сложно ориентироваться.
Например, мы проверяем регистрацию и называем тест-кейс: “Проверить успешную регистрацию”. Вроде логично, но такое название включает в себя проверку регистрации по нескольким полям. И получается, что название не информативно.

Если делать название тест-кейса слишком длинным, то его будет очень сложно читать, например: “Проверить правильную регистрацию, когда вводим логин латинскими буквами без цифр и пробелов с паролем из цифр”.
Такое название неудобно читать. Плюс некоторые инструменты хранения тест-кейсов могут обрезать длинные названия.

Что делать? Немного сократить название, убрать “Проверить” и слова, которые не несут важного смысла и получим следующее: “Регистрация с латинским логином”, “Регистрация с логином из цифр” и так далее.

3. Ссылка на требования — ссылка на требование или ТЗ, на основе которого был составлен тест-кейс.

4. Автор тест-кейсы (Author) — тестировщик, который написал тест-кейс.

5. Приоритет (Priority) — насколько важен этот тест-кейс, в какую очередь его стоит выполнять.

6. Название/модуль/версия продукта (Component/Version) — описание ПО, на котором можно выполнить тест-кейс.

7. Предварительные условия (pre-condition) — шаги, которые необходимо выполнить перед началом тестирования по этому тест-кейсу.

8. Шаги (steps) — точная последовательность действий для выполнения проверки.

Шаги должны быть четкими и понятными. В идеале их нужно писать так, чтобы понял даже человек, который видит проект и тестирование в первый раз. Четкие шаги снизят риски того, что тест-кейс будет неправильно понят, а соответственно и неправильно протестирован другими тестировщиками, особенно новичками, которые только пришли на проект. Скажу даже больше: иногда вы сами спустя какое-то время с трудом разбираете, что имели ввиду написав тот или иной шаг.

9. Ожидаемый результат (expected result) — что мы получаем после выполнения шагов.

10. Приложения (attachments) — дополнительная информация, которая поможет выполнить тест-кейс, например, скриншоты, текстовые файлы и прочие файлы.

Тест-кейс для авторизации на сайте

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

Форма авторизации на сайте
Форма авторизации на сайте

1.ID
Пусть будет №1, так как это наш первый тест-кейс

2. Краткое описание тест-кейса (Name)
Авторизация существующего пользователя.

Если бы нам на выбор было предложено несколько способов регистрации (Телефон, E-mail, ВКонтакте, Фейсбук и т.п.), то название могла бы выглядеть вот так “Авторизация существующего пользователя через ВКонтакте”.

3. Ссылка на требования
В нашем случае требований нет. Значит поле оставляем пустым

4. Автор тест-кейсы (Author)
Иванов И.

5. Приоритет (Priority)
Высокий, так как функциональность важная. В двух словах, чем важнее объект тестирования и проверки, тем выше приоритет.

6. Название/модуль/версия продукта (Component/Version)
Кейс относится напрямую к авторизации, следовательно этот модуль и укажем.

7. Предварительные условия (pre-condition)
Во-первых, нужно зайти на сайт по адресу https://msk.farfor.ru. Во-вторых, пользователь должен существовать и быть не залогинен.

8. Шаги (steps)
1) Вводим в поле телефона “+7 900 000-00-00”,
2) Вводим в поле password пароль “123”,
3) Нажимаем кнопку “Вход”.

9. Ожидаемый результат (expected result)
Авторизация прошла успешна, пользователь остался на странице https://msk.farfor.ru

10. Приложения (attachments)
В этот раз файлы нам не нужны, поэтому обойдемся без них.

Для наглядности соберем все это в таблицу.

Тест-кейс «Авторизация существующего пользователя»
Тест-кейс «Авторизация существующего пользователя»

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

В рассмотренном примере все шаги приводят к одному результату. Но также есть ситуации, когда на каждый шаг будет свой ожидаемый результат.

Если будет много проверок на один компонент, то тест-кейсы можно объединить в тестовый набор или по-другому Test Suite.

Теперь давайте немного поговорим о чек-листах в тестировании.

Чек-лист

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

Можно сказать, что чек-лист — это упрощенный тест-кейс без шагов и прочего описания. Просто список того, что необходимо проверить. Более того, иногда список тест-кейсов является своего рода чек-листом, если смотреть просто на названия тест-кейсов. Например, чек лист «Авторизация пользователя» может выглядеть следующим образом:
1. Авторизация пользователя через E-mail
2. Авторизация пользователя через ВКонтакте
3. Авторизация пользователя с пустым E-mail
4. Авторизация пользователя с неверным паролем и так далее

________________________________
Чек-лист экономит время тестировщика и упрощает поддержку тестовой документации, но, с другой стороны, многие вещи при проверки остаются на совести тестировщика. Например, какой е-mail вводим, какой неправильный пароль и так далее
________________________________

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

***

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

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

Источник

Что такое тестовый сценарий?

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

Что такое тестирование сценария?

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

Давайте изучим это с помощью видео ниже —

Зачем создавать тестовые сценарии?

Тестовые сценарии создаются по следующим причинам:

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

Когда не создать тестовый сценарий?

Тестовые сценарии не могут быть созданы, когда

  • Тестируемое приложение является сложным, нестабильным, и в проекте есть время.
  • Проекты, которые следуют Agile методологии, такие как Scrum, Kanban, могут не создавать тестовые сценарии.
  • Сценарий тестирования не может быть создан для исправления новой ошибки или регрессионного тестирования . В таких случаях сценарии тестирования должны быть уже задокументированы в предыдущих циклах тестирования. Это особенно верно для проектов технического обслуживания.

Как написать тестовые сценарии

Как тестер, вы можете выполнить следующие пять шагов для создания тестовых сценариев:

  • Шаг 1 : Прочтите документы с требованиями, такие как BRS, SRS, FRS, тестируемой системы (SUT). Вы также можете сослаться на примеры использования, книги, руководства и т. Д. Приложения, подлежащего тестированию.
  • Шаг 2 : Для каждого требования определите возможные действия и цели пользователей. Определить технические аспекты требования. Определите возможные сценарии злоупотребления системой и оцените пользователей с менталитетом хакера.
  • Шаг 3: После прочтения Документа с требованиями и проведения надлежащего анализа перечислите различные сценарии тестирования, которые проверяют каждую функцию программного обеспечения.
  • Шаг 4: После того, как вы перечислили все возможные сценарии тестирования, создается матрица отслеживания, чтобы убедиться, что каждому требованию соответствует соответствующий сценарий тестирования.
  • Шаг 5: Созданные сценарии проверяются вашим руководителем. Позже они также рассматриваются другими заинтересованными сторонами в проекте.

Советы по созданию тестовых сценариев

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

Пример 1. Сценарий тестирования для приложения электронной коммерции

Для приложения электронной коммерции несколько тестовых сценариев

Тестовый сценарий 1: проверка функциональности входа

тестовый сценарий

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

  1. Проверьте поведение системы при вводе действительного адреса электронной почты и пароля.
  2. Проверьте поведение системы при вводе неверного идентификатора электронной почты и действительного пароля.
  3. Проверьте поведение системы при вводе действительного адреса электронной почты и неверного пароля.
  4. Проверьте поведение системы при вводе неверного идентификатора электронной почты и неверного пароля.
  5. Проверьте поведение системы, если адрес электронной почты и пароль оставлены пустыми и введен вход.
  6. Проверить Забыли пароль работает как положено
  7. Проверьте поведение системы при вводе действительного / недействительного номера телефона и пароля.
  8. Проверять поведение системы, когда установлен флажок «Держать меня в подписи»

Как видно, тестовые случаи являются более конкретными.

Тестовый сценарий 2. Проверка функциональности поиска

тестовый сценарий

Тестовый сценарий 3: проверьте страницу описания продукта

тестовый сценарий

Сценарий тестирования 4: Проверьте функциональность платежей

тестовый сценарий

Тестовый сценарий 5: проверка истории заказов

тестовый сценарий

Помимо этих 5 сценариев, здесь приведен список всех других сценариев.

  • Проверьте поведение домашней страницы для постоянных клиентов
  • Проверьте категорию / страницы продукта
  • Проверьте службу поддержки / контактные страницы
  • Проверьте страницы ежедневных предложений

Пример 2: Тестовые сценарии для банковского сайта

Тестовый сценарий 1 : Проверьте функциональность входа и аутентификации

Тестовый сценарий 2 : Проверить перевод денег можно

Тестовый сценарий 3. Проверьте выписку со счета.

Тестовый сценарий 4 : Проверка фиксированного депозита / периодического депозита может быть создана

И так далее…

Шаблон сценария тестирования

Скачать шаблон тестового сценария Excel (.xlsx)

Источник

Понравилась статья? Поделить с друзьями:
  • Название танцевального праздника
  • Название сценария праздника масленица
  • Название сценария на день учителя
  • Название сценария на день сельского хозяйства
  • Название праздника ко дню защитника отечества

    • 0 0 голоса
    Рейтинг статьи
    Подписаться
    Уведомить о
    guest

    0 комментариев
    Старые
    Новые Популярные
    Межтекстовые Отзывы
    Посмотреть все комментарии