Как правильно писать тест-кейсы для тестирования ПО

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

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

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

Содержание:

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

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

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

  1. Проверка результатов при вводе допустимых значений пользователя и пароля.
  2. Проверка результатов при вводе неверных значений пользователя и пароля.
  3. Проверка реакции при пустом значении пользователя и нажатии кнопки входа.

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

Видеоролик о тест-кейсе

Формат стандартных тест-кейсов

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

Test Case IDОписание тест-кейсаШаги воспроизведенияТестовые данныеОжидаемые результатыФактические результатыСтатус прохождения
TU01Проверка правильности ввода данных для входа в систему1. Перейти на сайт http://demo.guru99.com
2. Введите идентификатор пользователя
3. Введите пароль
4. Нажмите кнопку “Sign in”
Userid = guru99 Password = pass99Пользователь должен войти в приложениеКак и ожидалосьPass
TU02Проверка входа клиента в систему с недопустимыми данными1. Перейти на сайт http://demo.guru99.com
2. Введите имя пользователя
3. Введите пароль
4. Нажмите кнопку “Sign in”
Userid = guru99 Password = glass99
Пользователь не должен входить в системуКак и ожидалосьPass

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

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

Давайте по этапно создадим тест-кейс для следующего сценария : Проверка функциональности входа в систему

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

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

Test Case #Описание тест-кейса
1Проверка ответа при вводе правильного email и пароля

Шаг 2. Тестирование данных

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

Test Case #Описание тест-кейсаТестовые данные
1Проверка ответа при вводе правильного email и пароляEmail: guru99@email.com
Password: lNf9^Oti7^2h

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

Шаг 3. Выполнение действий

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

Test Case #Описание тест-кейсаШаги воспроизведенияТестовые данные
1Проверка ответа при вводе правильного email и пароля1. Введите адрес электронной почты
2. Введите пароль
3. Нажмите кнопку “Sign in”
Email: guru99@email.com
Password: lNf9^Oti7^2h

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

Шаг 4. Проверка поведения

Test Case #Описание тест-кейсаТестовые данныеОжидаемый результат
1Проверка ответа при вводе правильного email и пароляEmail: guru99@email.com
Password: lNf9^Oti7^2h
Вход в систему должен быть успешным

Во время выполнения теста тестировщик сверяет ожидаемые результаты с фактическими и присваивает статус “пройден” или “не пройден”.

Test Case #Описание тест-кейсаТестовые данныеОжидаемый результатФактический результатPass/Fail
1Проверка ответа при вводе правильного email и пароляEmail: guru99@email.com
Password: lNf9^Oti7^2h
Вход в систему должен быть успешнымВход в систему прошел успешноPass

Шаг 5. Предварительные условия и постусловия. В этом разделе вашего тест-кейса может быть такое поле, как
”Предварительные условия”(Pre-Condition), в котором указывается, какие условия должны быть выполнены до запуска теста. Для нашего тест-кейса предварительным условием будет наличие установленного браузера для доступа к тестируемому сайту. Тест-кейс также может содержать поле “Постусловия” (Post-Conditions), определяющее, каким должно быть состояние системы после выполнения данного теста. Для нашего тест-кейса постусловием будет сохранение в базе данных времени и даты входа в систему.

Тест-кейсы: советы и рекомендации

Тест-кейсы: советы и рекомендации

1. Тест-кейсы должны быть простыми и ясными:

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

Используйте утвердительные формулировки, например, перейдите на домашнюю страницу, введите данные, нажмите на это и т.д.

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

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

3. Избегайте повторения тест-кейсов.

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

4. Не предполагайте.

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

5.  Обеспечьте 100-процентное покрытие.

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

6. Тест-кейсы должны быть идентифицируемыми.

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

7. Применение техник тест-дизайна.

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

  • Анализ граничных значений – Boundary Value Analysis (BVA). Как следует из названия, это методика, определяющая тестирование границ для заданного диапазона значений.
  • Разбиение на эквивалентные классы – Equivalence Partition (EP). Эта техника разбивает диапазон на равные части/группы, которые, как правило, имеют одинаковое поведение. 
  • Метод перехода состояний – State Transition Technique. Метод используется, когда поведение программного обеспечения изменяется от одного состояния к другому в соответствии с определенным действием.
  • Предугадывание ошибок – Error Guessing Technique. Метод предполагает угадывание/предсказание ошибок, которые могут возникнуть при ручном тестировании. Этот метод не является формальным и используется тестировщиком, имеющим опыт работы с подобным приложением.

8. Возвращение тестовой среды к первоначальному состоянию.

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

9. Повторяемость и автономность

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

10. Экспертная оценка

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

При написании тест-кейса следует включать в него следующую информацию:

  • Описание того, какое требование тестируется.
  • Объяснение того, как система будет протестирована.
  • Настройка тестового окружения, которая включает в себя установку программного и аппаратного обеспечения, создание тестовых данных и настройку сети для выполнения тест-кейсов.
  • Входные, выходные данные и ожидаемые результаты.
  • Любые подтверждения шагов и результатов, приложенных во вложениях.
  • Последовательность шагов/действий с использованием активной формы глагола, которые должен выполнить тестировщик. Например, вместо “Проверка должна быть выполнена” следует использовать “Выполнить проверку”.
  • Тест-кейс не должен содержать более 15 шагов.
  • Автоматизированный тестовый сценарий должен содержать комментарии, в которых указаны входные данные, цель и ожидаемые результаты.

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

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

  • Документирование тест-кейсов: с помощью шаблонов можно ускорить создание тест-кейсов.
  • Выполнение тест-кейса и запись результатов: тест-кейс может быть выполнен с помощью инструмента, и полученные результаты могут быть легко записаны.
  • Автоматизация отслеживания дефектов: неудачные тесты автоматически связываются с баг-трекером, который в свою очередь могут быть назначены разработчикам и отслеживаться по электронной почте.
  • Трассируемость: возможность отслеживать связи между различными элементами проекта, такими как требования, тест-кейсы и выполнение тест-кейсов. Инструменты управления тест-кейсами позволяют связать все эти элементы между собой, что обеспечивает полное покрытие тестами и упрощает процесс тестирования.
  • Защита тест-кейсов: тест-кейсы должны быть многоразовыми и защищены от потери или повреждения из-за плохого контроля версий. Инструменты управления тест-кейсами предлагают такие функции, как
    • Названия и нумерация
    • Версионность
    • Хранение только для чтения
    • Контролируемый доступ
    • Резервное копирование на удаленном сервере

К популярным инструментам управления тестирования относятся: JIRA, HP Quality Center, Azure DevOps.

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

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

Скачать шаблон тест-кейса

Перевод статьи «How to Write Test Cases in Software Testing with Examples».

7 комментариев к “Как правильно писать тест-кейсы для тестирования ПО”

  1. Пингбэк: Тест-кейс и тестовый сценарий

  2. Пингбэк: Что такое тестирование ПО? Виды, методы и инструменты тестирования

  3. Пингбэк: Как мы создали автономный фреймворк автоматизации тестирования

  4. Пингбэк: Как тестировать мессенджеры?

  5. Пингбэк: Большой учебник по написанию тест-кейсов

  6. Пингбэк: Что такое автоматизированное тестирование?

  7. Пингбэк: Тест-кейсы для мобильных приложений

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

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