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

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

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

Друзья, поддержите нас вступлением в наш телеграм канал 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».

Большой учебник по тестированию