Тест-кейс – это один из артефактов тестирования. Он позволяет тестировщикам проверить, работают ли функции приложения так, как задумано. Тест-кейсы – это наборы положительных и отрицательных действий, которые выполняются в рамках тестового сценария. Они содержат предварительные условия, тестовые данные, ожидаемые и фактические результаты, а также постусловия.
Большинство компаний используют инструменты управления тест-кейсами, такие как Quality Center (HP QC), JIRA и т. д., но некоторые все еще пользуются таблицами excel для написания тест-кейсов.
Друзья, поддержите нас вступлением в наш телеграм канал QaRocks. Там много туториалов, задач по автоматизации и книг по QA.
Видео о том, как писать тест-кейсы вручную:
В чем разница между тестовым сценарием и тест-кейсом?
Тестовый сценарий дает представление о том, что мы должны тестировать. Тестовый сценарий – это как высокоуровневый тест-кейс.
Например, нам нужно написать тест-кейсы для сценария проверки входа в учетную запись Gmail.
Вот несколько тест-кейсов:
- Введите валидное имя пользователя и валидный пароль
- Введите валидное имя пользователя и невалидный пароль
- Введите невалидное имя пользователя и валидный пароль
- Введите невалидное имя пользователя и невалидный пароль
Кто пишет тест-кейсы?
В разных компаниях по-разному. Чаще всего это что-то вроде совместной работы разработчиков и тестировщиков.
- Разработчики пишут модульные тесты.
- Разработчики и тестировщики пишут интеграционные тесты.
- Тестировщики пишут приемочные тесты.
Шаблон тест-кейса
Ниже приведен скриншот шаблона тест-кейса:
Написание тест-кейсов при ручном тестировании
1. ID тест-кейса
Каждый тест-кейс должен иметь уникальный идентификатор. Рекомендуется следовать соглашению об именовании.
2. Описание тес-кейса
Правильно подбирайте тест-кейсы на основе тестовых сценариев.
Пример:
Сценарий тестирования: проверка входа в Gmail
Тест-кейс: введите правильное имя пользователя и правильный пароль
3. Предварительные условия
Условия, которые должны быть выполнены перед запуском тест-кейса.
Пример: для входа в систему необходима действующая учетная запись Gmail.
4. Шаги тестирования
Укажите все шаги тестирования подробно и в том порядке, в котором они могут быть выполнены с точки зрения конечного пользователя.
Пример:
- Введите имя пользователя
- Введите пароль
- Нажмите кнопку “Войти”
5. Тестовые данные
Для выполнения шагов тестирования вам нужны соответствующие тестовые данные.
Пример:
- Имя пользователя: rajkumar@softwaretestingmaterial.com
- Пароль: STM
6. Ожидаемый результат
Результат, который мы ожидаем после выполнения тест-кейсов. Это может быть что угодно: главная страница, соответствующий экран, сообщение об ошибке и т. д,
Пример: успешный вход в систему.
7. Постусловия
Условия, которые ожидаются в случае, если тест-кейс успешно выполнен.
Пример: отображается почтовый ящик Gmail.
8. Фактический результат
Результат, который система показывает после выполнения тест-кейса. Зафиксируйте результат после выполнения. На основании этого результата и ожидаемого мы устанавливаем статус тест-кейса.
Пример: перенаправление на почтовый ящик Gmail.
9. Статус
Наконец, установите статус “Пройден” или “Не пройден” на основе ожидаемого и фактического результатов. Если фактический и ожидаемый результаты совпадают, укажите статус тест-кейса как “Пройден”. В противном случае запишите его как “Не пройден”.
Пример:
Статус: пройден
Другие важные поля тест-кейса
- Название проекта: проект, к которому относятся тест-кейсы
- Название модуля: модуль, к которому относятся тест-кейсы
- Ссылочный документ: укажите путь к ссылочным документам (если таковые имеются, например, спецификация требований, тест-план, тестовые сценарии и т.д.).
- Создал: имя тестировщика, создавшего тест-кейсы
- Дата создания: когда были созданы тест-кейсы
- Дата рассмотрения: когда были рассмотрены тест-кейсы
- Выполнил: имя тестировщика, выполнившего тест-кейс
- Дата выполнения: когда был выполнен тест-кейс
- Комментарии: включите ценную информацию, которая в дальнейшем поможет QA-команде
Написание хороших тест-кейсов: best practices
Тест-кейсы должны обладать следующими характеристиками:
- Их легко понять и выполнить.
- Создаются с точки зрения конечного пользователя.
- Имеют уникальные идентификаторы. Это позволяет нам легко их отслеживать.
- Необходимые предусловия четко перечислены. Это поможет выполнить тест-кейс без проблем.
- Для оценки каждой функциональной области должны быть определены тестовые данные.
- Описание тест-кейса должно быть кратким.
- Шаги тестирования должны быть подробными и понятными.
- Указан точный ожидаемый результат.
- Тест-кейсы не должны быть ни слишком простыми, ни слишком сложными.
- Тест-кейсы должны быть уникальными. Не должно быть повторяющихся тест-кейсов.
- Тест-кейсы должны быть понятными. Так, чтобы любой тестировщик мог понять их, прочитав один раз.
- Содержат четкие детали тестовой среды, в которой мы должны их выполнить.
- Тест-кейсы должны быть многоразовыми.
Если вы будете следовать перечисленным лучшим практикам, то любой член команды сможет легко понять и выполнить любой ваш тест-кейс. Хорошо написанный тест-кейс должен быть легко читаемым и понятным не только для того, кто его написал, но и для других тестировщиков.
Пишите их просто и понятно
Чтобы тест-кейсы были понятны и выполнялись быстрее, нужно использовать простой и понятный язык, например “перейти на страницу входа”, “ввести имя пользователя”, “ввести пароль”, “нажать на кнопку входа” и так далее.
Создавайте тест-кейсы с точки зрения конечного пользователя
Создавайте тест-кейсы, думая о конечном пользователе. Создаваемые тест-кейсы должны соответствовать требованиям заказчика.
Используйте уникальные идентификаторы тест-кейсов
Рекомендуется использовать уникальный идентификатор для каждого тест-кейса с некоторым соглашением об именовании.
Напишите четкое описание
Описание тест-кейса должно быть достаточно ясным, чтобы понять, на какую функциональность приложения он направлен.
Добавьте соответствующие пред- и постусловия
В некоторых случаях для выполнения тест-кейсов нужно сперва обеспечить выполнение некоторых условий. Также какие-то условия могут быть обязательны после выполнения. Эти условия мы должны упомянуть в качестве пред- и постусловий.
Укажите точный ожидаемый результат
Ожидаемый результат говорит нам о том, каким будет результат теста. На основе ожидаемого результата тестировщики определяют критерии прохождения или сбоя теста.
Пишите многоразовые тест-кейсы
Хорошо написанный тест-кейс пригоден для многократного использования и сопровождения. Бывают случаи, когда разработчики меняют код, и тестировщикам приходится обновлять тест-кейсы. Если наши тест-кейсы легко читать и понимать, то их будет легко обновлять не только тому, кто их написал, но и другим тестировщикам.
Популярные инструменты управления тест-кейсами
Некоторые из популярных инструментов для управления процессом тестирования:
Перевод статьи «How to Write Test Cases: Test Case Template With Examples».
Пингбэк: Большой учебник по написанию тест-кейсов
Пингбэк: Основы работы с мокингом в Python