Документация тестирования: Тест-кейс(test-case)
Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для Вас с целью персонализации сервисов и предложений. Вы можете прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом без изменения настроек, вы даёте согласие на использование ваших cookie-файлов.
speech bubble

Документация тестирования: Тест-кейс(test-case)

Документация тестирования: Тест-кейс(test-case)

Тест-кейс - популярнейший вид документации для тестирования. Документацию на основе кейсов пишут тестировщики(QA инженеры) или тест-дизайнеры. Для вас не составит особого труда в понимании документа, если вы хотя бы раз в жизни читали инструкцию или руководство к сборке комода. Тест-кейс имеет классическую структуру и документируют в Word, Excel, txt, таск трекингах (task-tracking). 

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

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

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

Высокоуровневый тест-кейс (high-level test case) - тестовый сценарий с абстрактными предусловиями, входными данными, ожидаемыми результатами, постусловиями и действиями (где применимо).

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

Исходный тест-кейс (source test case) - пройденный тестовый сценарий, использующийся в качестве основы для последующих тестов в тестировании.

Последующий тест-кейс (follow-up test case) - тестовый сценарий, созданный путем применения иерархического отношения к исходному тестовому набору во время тестирования.

Взрыв тест-кейсов (test case explosion) - непропорциональный рост количества тест-кейсов с ростом размера тестовой базы при использовании определенной методики проектирования тестов. Например, добавление всех тестовых сценариев после применения техники тест-дизайна pairwise testing.

 

 

Цель тест-кейса

Для поддерживания тестовой документации в виде тест-кейсов преследуются конкретные цели.

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

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

 

Минусы и недостатки тест-кейсов на проекте:   

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

 

Атрибуты тест-кейса (test-case)

Обязательные атрибуты, требования тест-кейса:

  • ID (Идентификатор тест-кейса) – уникальный номер документа, присваивается зачастую автоматически.
  • IDEA(Идея) – Какую именно идею мы хотим проверить. Зачастую информация из поля "Идея" переносится в Title.
  • Title(Наименование тест-кейса) – краткое описание проверки.
  • Steps (Шаги выполнения тест-кейса) – сценарий(шаги) для выполнения тестового сценария.
  • Expected result (Ожидаемый результат) – результат, который должен получиться по итогу выполнения сценария. Описывается для каждого шага в кейсе.
  • Actual result (Фактический результат) – добавляется напротив ожидаемого результата каждого шага. В случае успешного прохождения шага тест-кейса, ставится отметка «Passed». Некоторые проекты игнорируют данный атрибут, добавляя фактический результат только в случае проваленного теста.
  • Comment (Комментарий) – дополнительная информация тестировщика после выполнения тест-кейса.
  • Status (Статус) – результат(Статус) прохождения тест-кейса. Добавляется тестировщиком после прохождения тест-кейса.

Необязательные атрибуты, требования тест-кейса:

  • DATA (Тестовые данные) – значения, данные, табличные данные, необходимые для проверки. Могут быть в виде таблицы, либо вынесены в отдельный файл.
  • Priority (Приоритет тест-кейса) – приоритет выполнения, очередность.
  • Enviroment (Окружение) - тест-кейс является специфичным для проверяемого окружения.
  • Type (Тип тест-кейса) – ставится отметка «Позитивный» или «Негативный» сценарий. Помогает распределить, отсортировать и понять тестовые сценарии, написанные согласно требованиям.
  • Pre-condition (Предусловия) – необходимые действия, которые надо выполнить перед выполнением тест-кейса. Например, регистрация, авторизация, скачивание файла и так далее.
  • Post-condition(Постусловия) – действия, которые необходимо сделать по окончанию выполнения тест-кейса. Например, очистить данные, удалить записи, файлы и так далее.

 

Помните! В шагах тест-кейса глаголы пишутся в инфинитиве. Правильно: "Нажать", "Кликнуть", "Осмотреть", "Получить". Неправильно: "Нажмите", "Перейдите", "Примите".

 

Статусы результатов проверки тест-кейса:

  • passed — проверено, соответствует ожидаемому результаты, работает согласно заявленным требованиям. Комментарий необязателен.
  • failed — поведение системы не соответствует ожидаемым требованиям, найден дефект. Пишется подробный комментарий.
  • blocked — выполнить проверку невозможно, имеются обстоятельства (дефект, модуль, компонент), которые блокируют дальнейшую проверку. В комментарии указывается причина.
  • skipped — тест пропущен. Возможно, отсутствует необходимый модуль для проверки, который будет не реализован. В комментарии указывается причина пропуска.
  • draft - тест пропущен, либо не начат. Отсутствует объект тестирования, который будет реализован позже. Комментарий не обязателен.
  • work in progress – переводится в случае длительного выполнения. Чаще всего статус пропускают и ставят конечный результат «failed», «passed» или «blocked».

 

Пример тест-кейсов на проверку загрузки файла

Предположим, QA инженеру прислали требования на загрузку файлов.

П 1. На странице галереи необходимо добавить поле для загрузки файлов в формате png, jpg, gif.

П 2. Для загрузки файлов пользователь должен быть авторизован.

П 3. Максимальный размер файла 5МБ.

П 4. Пустое поле запрещено отправлять. 

 

Полученные тест-кейсы после применения техник тест-дизайна:

Примеры тест-кейсов

*Для формата jpg аналогичный тест-кейс.

 

Набор тест-кейсов

В документации тестирования существует понятие набора, тест-сьюта, тест-комплект тест-кейсов (test suite, test case suite). 

Набор тест-кейсов (test case suite, test suite) — сочетание тест-кейсов, объединенных по общему признаку проверки модуля, версии, системы.

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

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

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

 

Схема наборов тест-кейсов на проекте

 

Заключение

Тест-кейсы – основная почва для проведения тестирования. Зачастую проекты отказываются от тест-кейсов, остающихся на лидирующих позициях, из-за существенных недостатков и самым главным «Время=деньги», отдавая предпочтение расширенным чек листам.

 

Материалы для скачивания

 

Для комментирования необходимо авторизоваться