Меню

Что такое тест кейс простыми словами



Тест кейсы

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

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

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

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

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

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

Цель написания тест-кейсов:

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

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

Жизненный цикл тест-кейса

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

Рис. 4.2. Жизненный цикл тест-кейса

Создан (new) — типичное начальное состояние практически любого артефакта. Тест-кейс автоматически переходит в это состояние после создания.

Запланирован (planned, ready for testing) — в этом состоянии тест-кейс находится, когда он или явно включён в план ближайшей итерации тестирования, или, как минимум, готов для выполнения.

Не выполнен (not tested) — в некоторых системах управления тест-кейсами это состояние заменяет собой предыдущее («запланирован»). Нахождение тест-кейса в данном состоянии означает, что он готов к выполнению, но ещё не был выполнен.

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

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

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

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

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

Закрыт (closed) — очень редкий случай, т.к. тест-кейс, как правило, оставляют в состояниях «провален / пройден успешно / заблокирован / пропущен». В некоторых системах управления тест-кейс переводят в данное состояние, чтобы подчеркнуть тот факт, что на данной итерации тестирования все действия с ним завершены.

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

Структура тест кейса

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

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

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

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

потенциальной важностью дефекта, на поиск которого направлен тест-кейс;

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

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

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

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

механизм анализа параметров;

механизм сборки приложения;

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

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

механизм обхода дерева SOURCE_DIR;

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

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

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

состояние базы данных;

состояние файловой системы и её объектов;

состояние серверов и сетевой инфраструктуры.

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

Общие рекомендации по написанию шагов таковы:

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

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

Если вы пишете на русском языке, то используйте безличную форму (например, «открыть», «ввести», «добавить» вместо «откройте», «введите», «добавьте»), в английском языке не надо использовать частицу «to» (т.е. «запустить приложение» будет «start application», не «to start application»).

Читайте также:  Тесты психологической диагностики детей

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

Ссылайтесь на предыдущие шаги и их диапазоны для сокращения объёма текста (например, «повторить шаги 3–5 со значением…»).

Пишите шаги последовательно, без условных конструкций вида «если… то…».

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

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

Описывайте поведение системы так, чтобы исключить субъективное толкование (например, «приложение работает верно» — плохо, «появляется окно с надписью…» — хорошо).

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

Пишите кратко, но не в ущерб информативности.

Избегайте условных конструкций вида «если… то…».

Набор тест-кейсов (test case suite, test suite, test set) — совокупность тест-кейсов, выбранных с некоторой общей целью или по некоторому общему признаку.

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

Преимущества свободных наборов:

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

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

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

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

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

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

Классификация наборов тест-кейсов

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

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

Набор изолированных последовательных тест-кейсов: действия из раздела «приготовления» нужно повторять перед каждым тест-кейсом, а сами тест-кейсы нужно выполнять в строго определённом порядке.

Набор обобщённых последовательных тест-кейсов: действия из раздела «приготовления» нужно выполнить один раз (а потом просто выполнять тест-кейсы), а сами тест-кейсы нужно выполнять в строго определённом порядке.

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

Главное преимущество обобщённости: приготовления не нужно повторять (экономия времени).

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

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

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

Подходы к составлению наборов тест-кейсов:

На основе чек-листов.

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

По принципу проверки самых важных, менее важных и всех остальных функций приложения.

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

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

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

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

Источник

Тест кейс (test case)

Тест кейс ТЕСТ КЕЙС (TEST CASE) – это комплекс исходных данных, условий и ожидаемых результатов, разработанный с целью проверки требуемого свойства продукта. Test cases, собранные в последовательность для достижения некоторой цели образуют test suite (набор тестов).

Еще одно определение test case — это спецификация входных данных, условий выполнения, процедуры тестирования и ожидаемых результатов, которые определяют один тест, который должен быть выполнен для достижения конкретной цели тестирования программного обеспечения, например для выполнения определенного пути программы или для проверки соответствия определенному требованию

Содержание

  • В чем сложность написания тест кейсов?
  • Зачем нужно написание тест кейсов?
  • Как писать тест кейсы?
  • Что может являться атрибутом тест кейса?
  • Написание тест кейсов: примеры

Чтобы больше прояснить ситуацию с терминами и определениями, давайте сопоставим некоторые термины касательно этой темы:

  • Тест-кейс и тест = синоним
  • Не путаем чек-лист и тест. Отличие тест кейса от чек-листа заключается в том, что чек-лист это всего лишь идея будущего теста, а тест кейс, как мы говорили выше, набор данных и ожидаемых результатов. Часто чек лист становится хорошим началом атрибута Test description в тест-кейсе.
  • Не путаем тест план и тест кейс. Что касается мы уже определились, а вот тест план это фундаментальный документ, который описывает разные аспекты процесса тестирования. Подробно о тест плане мы поговорим в отдельной статье.
  • Тест сценарий и тест кейс, также неравны. Тестовый сценарий (test scenario) – набор тестов (тест-кейсов), собранных в последовательность для достижения некоторой цели. Хороший тестовые сценарии и тест кейсы в нем всегда следуют некоторой логике, например: типичному использованию приложения, удобству тестирования, распределению функций по модулям и т.д.

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

В чем сложность написания тест кейсов?

Признаться честно, разработка тест кейсов не совсем приятное для многих тестировщиков занятие. И эта неприязнь легко поддается объяснению, ведь их создание требует от Software Testing Engineer следующего:

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

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

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

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

Зачем нужно написание тест кейсов?

написание тест кейсов

Как мы отмечали выше создание тестов не простое занятие для большинства нестировщиков. Тем не менее, позитивные свойства качественных тест кейсов заключаются в том, что они позволяют:

  • Найти проблемные места в требованиях. Если требование не понятно и не тестируемо в принципе, то написание тест кейса это проявит. Вместе с тем, здесь нужно быть предельно ответственным, нельзя копипастить требования в ТК.
  • Структурировать всю информацию. Логика и структура дадут нам больше шансов тратить меньше времени на вникание в сам тест кейс (одно будет вытекать из другого). Кейсы, максимально замапленные на требования, позволяют потом не искать, откуда же эта информация взята.
  • Ускорить регрессию. Чтобы провести качественный регресс, надо выбрать правильные тест кейсы smoke test, высокоуровневый тест кейсы и тд. Помимо этого, тест кейсы, содержащие максимум вспомогательной информации: логины, пароли – тем самым экономим время.
  • Хранить и собирать информацию. Все сложные настройки должны быть описаны в тест кейсах (логины, пароли, валидация полей, сертификаты, данные карт и тд.). Всегда можно приатачить к кейсам дополнительные файлы с нужной инфой или даже какое-то важное письмо.
  • Отслеживать процесс тестирования. Тут важно отметить следующие особенности, что одна ячейка таблицы=один тест, так четко и без проблем ставим статус. Можно создаем статистику (пройдено /не пройдено, не протестировано)
Читайте также:  Тест люшера какие цвета лучше выбирать

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

Как писать тест кейсы?

как писать тест кейсы

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

  • Подробный или общий?
  • Позитивный или негативный?
  • Простой или сложный?
  • Независимый или объединенный?

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

Подробный или общий тест кейс?

Пример оформления 1

2.In the field B, type 3

3.Click Add button.

Плюсы и минусы

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

Пример оформления 2

1.In the field A, enter valid integer

2.In the field B, enter valid integer

3.Click Add button.

4.Check value of the field C

Плюсы и минусы

  • Мы не привязаны к точным значениям
  • Время на поддержку теста сокращается
  • Мы перечисляем конкретные цифры, которые должны быть проверены в тесте

Позитивные или негативные тест кейсы?

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

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

Помня эти принципы, тестировщику проще не совершить крен в ту или иную сторону будь-то при написании тест кейсов игры или use case testing.

Простые или сложные тест кейсы?

Начиная разработку ТК сотруднику необходимо помнить, следующую последовательность разработки, а потом и выполнения тестов:

  • Простые позитивные
  • Простые негативные
  • Сложные позитивные
  • Сложные негативные

Такая очередность позволяет оптимизировать процесс написания и в дальнейшем легче определять приоритет тест кейса.

Независимые или объединенные тест кейсы?

В данной ситуации нет однозначного ответа да этот вопрос, все зависит от конкретного проекта. Поэтому просто перечислим типичные характеристики данных тест кейсов

Независимые:

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

Объединенные:

  • Сценарии повторяют поведения пользователя
  • Эффективны, когда в 1 шаге у нас по 10 подшагов
  • Мы не создаем каждый раз новые данные, а используем созданное на предыдущем шаге
  • Характерны для интеграционного и системного тестирования

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

Best practices тест кейсы:

  • Используйте простой разговорный язык
  • Всегда используйте полное описание и наименование элементов
  • Не объясняйте Windows basics
  • [button], (?), “field name”, ‘label’
  • “Open”, а не “go”

Теперь пришло время поговорить про поля тест кейса и характерные атрибуты.

Что может являться атрибутом тест кейса?

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

Названия атрибутов тест кейса
ID Priority Req. ID Module Sub-Module Test description Expected result Result Comment

Следует отметить, что атрибуты тест кейса могут отличаться в зависимости от компании и инструмента, с помощью которого данные тесты создаются, поэтому мы перечислим наиболее распространенные атрибуты тест кейса:

  1. ID — уникальный идентификатор. Если проставляется руками, то желательно делать его осмысленным. Часто генерируется автоматически.
  2. Priority (приоритет тест кейса) – атрибут, который указывает приоритетность ТК, и принимает значение, согласно принятой в компании классификации (A-B-C-D-E, High-Medium-Lowи тд.)
  3. Req. ID – атрибут, указывающий на связанный с тестом пункт требования
  4. Module – здесь указывается связанный с тест кейсом модуль.
  5. Sub-Module – аналогично предыдущему пункту, только вписывается более мелкая структурная единица.
  6. Test description (описание тест кейсов) – важный атрибут, в котором указывается заголовок (суть теста), условия для его выполнения, шаги и действия после прохождения теста. Test description, соответственно, может и должен содержать:
  • Precondition
  • Steps
  • Postcondition
  1. Expected result (ожидаемый результат тест кейса) – данный атрибут отражает ожидаемый результат по каждому шагу.
  2. Result – сюда заносятся данные о результате пройденного теста (passed/failed и др.)
  3. Comment – сюда можно вносить свои примечания к тесту (вопросы заказчику, какие-либо наблюдения или детали)

back to menu ↑

Написание тест кейсов: примеры

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

Написание тест кейсов: примеры

Скачать тест кейс пример оформления в формате xlsx

Источник

Что такое тест кейс простыми словами

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

Как составить Тест-кейс?

Как составить Тест-кейс?

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

И так, начнем с того, что Тест-кейс – это задокументированная ситуация, которая проверяет условие взятое например из документации. Тест-кейсы собираются в Тест-комплекты, например “Тест-комплект Поиска на главной странице”.

Также для составления Тест-кейса нам нужно понять “Основные атрибуты Тест-кейса”:

  • Заголовок

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

  • Приоритет

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

Уровни приоритета: Hight, Medium и Low. Приоритет выставляется в соответствии с важностью функционала и т.д.

  • Уникальный ID

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

  • Краткое описание
Читайте также:  Квалификационный экзамен руководителя в ЖКХ

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

  • Шаги-воспроизведения

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

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

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

  • Результат тест-кейса

Поле служит для проставления результата по каждому тест кейсу. Если ожидаемый результат совпадает с реальным, то проставляем pass, в противном случае ставим fail. Возможно еще несколько статусов в зависимости от процессов и правил в IT компании

  • Комментарий

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

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

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

Полезным будет, также, если приложить видео.

Источник

Правильно пишем тест-кейсы. Памятка начинающему специалисту по тестированию

Правильно пишем тест-кейсы. Памятка начинающему специалисту по тестированию

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

Для начинающих поясним, что такое тест-кейс озвучив определение из глоссария терминов 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), то можете скачать шаблон тест-кейсов. В файле две вкладки. На одной шаблон единичного тест-кейса, а на второй пример порядка размещения группы тест-кейсов.

Источник