Для чего нужен тест кейс

Для чего нужен тест кейс

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

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

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

Начнем с небольшой теории..

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

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

Исследовательское тестирование

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

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

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

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

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

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

Преимущества исследовательского похода:

Преимущества сценарного подхода:

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

Недостатки исследовательского подхода:

Недостатки сценарного подхода:

Источник

Тестовая документация. Тест кейс

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

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

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

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

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

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

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

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

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

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

Создан (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) указывают на части приложения, к которым относится тест-кейс, и позволяют лучше понять его цель. Идея деления приложения на модули и подмодули проистекает из того, что в сложных системах практически невозможно охватить взглядом весь проект целиком, и вопрос «как протестировать это приложение» становится недопустимо сложным. Тогда приложение логически разделяется на компоненты (модули), а те, в свою очередь, на более мелкие компоненты (подмодули). Как правило, иерархия модулей и подмодулей создаётся как единый набор для всей проектной команды, чтобы исключить путаницу из-за того, что разные люди будут использовать разные подходы к такому разделению или даже просто разные названия одних и тех же частей приложения. В реальности проще всего отталкиваться от архитектуры и дизайна приложения. Например, в уже знакомом нам приложении можно выделить такую иерархию модулей и подмодулей:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

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

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

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

Содержание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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