Инструкция по написанию тест-кейсов

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

Большинство компаний используют инструменты управления тест-кейсами, такие как Quality Center (HP QC), JIRA и т. д., но некоторые все еще пользуются таблицами excel для написания тест-кейсов.

Друзья, поддержите нас вступлением в наш телеграм канал QaRocks. Там много туториалов, задач по автоматизации и книг по QA.

Видео о том, как писать тест-кейсы вручную:

В чем разница между тестовым сценарием и тест-кейсом?

Тестовый сценарий дает представление о том, что мы должны тестировать. Тестовый сценарий – это как высокоуровневый тест-кейс.

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

Вот несколько тест-кейсов:

  1. Введите валидное имя пользователя и валидный пароль
  2. Введите валидное имя пользователя и невалидный пароль
  3. Введите невалидное имя пользователя и валидный пароль
  4. Введите невалидное имя пользователя и невалидный пароль

Кто пишет тест-кейсы?

В разных компаниях по-разному. Чаще всего это что-то вроде совместной работы разработчиков и тестировщиков.

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

Ниже приведен скриншот шаблона тест-кейса:

Написание тест-кейсов при ручном тестировании

1. ID тест-кейса

Каждый тест-кейс должен иметь уникальный идентификатор. Рекомендуется следовать соглашению об именовании.

2. Описание тес-кейса

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

Пример:

Сценарий тестирования: проверка входа в Gmail
Тест-кейс: введите правильное имя пользователя и правильный пароль

3. Предварительные условия

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

Пример: для входа в систему необходима действующая учетная запись Gmail.

4. Шаги тестирования

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

Пример:

  • Введите имя пользователя
  • Введите пароль
  • Нажмите кнопку “Войти”

5. Тестовые данные

Для выполнения шагов тестирования вам нужны соответствующие тестовые данные.

Пример:

  • Имя пользователя: rajkumar@softwaretestingmaterial.com
  • Пароль: STM

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

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

Пример: успешный вход в систему.

7.  Постусловия

Условия, которые ожидаются в случае, если тест-кейс успешно выполнен.

Пример: отображается почтовый ящик Gmail.

8. Фактический результат

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

Пример: перенаправление на почтовый ящик Gmail.

9. Статус

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

Пример:

Статус: пройден

Другие важные поля тест-кейса

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

Написание хороших тест-кейсов: best practices

Тест-кейсы должны обладать следующими характеристиками:

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

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

Пишите их просто и понятно

Чтобы тест-кейсы были понятны и выполнялись быстрее, нужно использовать простой и понятный язык, например “перейти на страницу входа”, “ввести имя пользователя”, “ввести пароль”, “нажать на кнопку входа” и так далее.

Создавайте тест-кейсы с точки зрения конечного пользователя

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

Используйте уникальные идентификаторы тест-кейсов

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

Напишите четкое описание

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

Добавьте соответствующие пред- и постусловия

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

Укажите точный ожидаемый результат

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

Пишите многоразовые тест-кейсы

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

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

Некоторые из популярных инструментов для управления процессом тестирования:

  1. PractiTest
  2. Test Rail
  3. Testpad
  4. Qase
  5. Klaros
  6. Test Collab
  7. QMetry
  8. Meliora Testlab
  9. TestLodge
  10. TestCaseLab

Перевод статьи «How to Write Test Cases: Test Case Template With Examples».

Оставьте комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *