Тестирование программного обеспечения — это процесс проверки и подтверждения того, что приложение или система работает корректно. Оно позволяет убедится в том, что функциональность ПО соответствует требованиям, работает без ошибок, багов и других проблем, и выдает пользователю ожидаемый результат.
Для тестирования предусмотрен специальный формат, называемый тест-кейсом.
В этой статье рассматривается понятие тест-кейса, его структура, назначение и роль в тестировании. Описываются ключевые параметры, типы тест-кейсов, отличия от тестовых сценариев, а также приводятся примеры, лучшие практики и инструменты для управления ими.
Содержание:
- Что такое тест-кейс?
- Параметры тест-кейса
- Разница между тест-кейсом и тестовым сценарием
- Когда пишутся тест-кейсы?
- Зачем писать тест-кейсы?
- Шаблон тест-кейса
- Лучшие практики написания тест-кейсов
- Инструменты управления тест-кейсами
- Формальные и неформальные тест-кейсы
- Типы тест-кейсов
- Преимущества написания качественных тест-кейсов
- Примеры тест-кейсов для страницы входа
- Заключение
🔥 Важное для QA-специалистов! 🔥
В QaRocks ты найдешь туториалы, задачи и полезные книги, которых нет в открытом доступе. Уже более 15.000 подписчиков – будь среди нас! Заходи к нам в телеграм канал QaRocks
Что такое тест-кейс?
Тест-кейс — это набор шагов или действий, которые выполняются для проверки того, соответствует ли система требованиям и работает ли она должным образом. Он помогает убедиться, что ПО правильно функционирует в разных условиях и отвечает ожиданиям. Тест-кейсы играют важную роль в выявлении ошибок и обеспечении качества продукта.
Параметры тест-кейса
Ниже перечислены важные параметры тест-кейса, которые помогают в процессе разработки:
- Название модуля: Название или тема, определяющая функциональность, которую тестируют.
- ID тест-кейса: Уникальный идентификатор, присваиваемый каждому тест-кейсу.
- Имя тестировщика: Имя человека, который выполняет тестирование.
- Тестовый сценарий: Краткое описание для тестировщика, дающее общее представление о том, что нужно выполнить, включая основные функции и компоненты теста.
- Описание тест-кейса: Условие, которое необходимо проверить, например, проверка валидации числового ввода в поле возраста.
- Шаги тестирования: Последовательность действий для проверки условия.
- Предусловия: Условия, которые должны быть выполнены перед началом теста.
- Приоритет теста: Уровень важности теста, который определяет, какие тесты нужно выполнять в первую очередь, а какие могут быть выполнены позже.
- Тестовые данные: Входные данные, используемые для проверки условий.
- Ожидаемый результат: Результат, который должен быть получен по окончании теста.
- Параметры теста: Дополнительные параметры, назначенные конкретному тест-кейсу.
- Фактический результат: Реальный результат, полученный после выполнения теста.
- Информация об окружении: Описание среды тестирования — операционная система, версия ПО, настройки безопасности и т.д.
- Статус: Статус теста — пройден (Pass), провален (Fail) и др.
- Комментарии: Замечания по тесту, направленные на улучшение качества ПО.
Разница между тест-кейсом и тестовым сценарием
Ниже приведены некоторые различия между тест-кейсом и тестовым сценарием:
| Параметры | Тест-кейс | Тестовый сценарий |
|---|---|---|
| Определение | Структурированный формат, используемый для проверки, работает ли конкретное приложение/модуль в различных условиях. | Краткое описание того, что нужно протестировать на основе сценария использования. |
| Уровень детализации | Высокий уровень детализации, включающий несколько параметров. | Низкий уровень детализации — чаще всего однострочное описание. |
| Уровень действий | Низкоуровневые действия (конкретные шаги). | Высокоуровневые действия (общие проверки функциональности). |
| Происхождение | Тест-кейсы обычно разрабатываются на основе тестовых сценариев. | Сценарии разрабатываются на основе документации, такой как BRS (бизнес-требования), SRS (системные требования) и др. |
| Цель | Ориентирован на “что тестировать” и “как тестировать“. | Больше ориентирован на “что тестировать“. |
| Требуемые ресурсы | Требует больше ресурсов на написание и выполнение. | Для написания тестовых сценариев требуется меньше ресурсов. |
| Входные данные | Включает положительные и отрицательные входные данные, ожидаемые результаты, шаги навигации и пр. | Они более обобщённые и описательные. |
| Требуемое время | Написание требует больше времени по сравнению с тестовыми сценариями. | Требует меньше времени на составление. |
| Поддержка | Труднее в сопровождении. | Легче поддерживать и адаптировать. |
Когда пишутся тест-кейсы?
Тест-кейсы составляются в разных ситуациях:
➤ До начала разработки: Тест-кейсы могут быть написаны до того, как начнётся фактическое программирование. Это помогает заранее понять требования к продукту или ПО, а также подготовиться к последующему тестированию, когда разработка будет завершена.
➤ После разработки: Тест-кейсы также составляются после разработки продукта или отдельной функции — но до запуска. Это необходимо, чтобы протестировать работоспособность конкретной функциональности.
➤ Во время разработки: Иногда тест-кейсы пишутся параллельно с разработкой. Это позволяет тестировать части модуля/ПО по мере их готовности.
Зачем писать тест-кейсы?
Тест-кейсы — один из важнейших аспектов разработки, поскольку именно они определяют, как будет проводиться тестирование. Основная причина написания тест-кейсов — проверить, работает ПО или нет.
У написания тест-кейсов есть много преимуществ:
🔹 Проверка соответствия ожиданиям заказчика: Тест-кейсы позволяют убедиться, соответствует ли конкретный модуль или ПО заданным требованиям.
🔹 Проверка соответствия ПО заданным условиям: Тест-кейсы помогают определить, правильно ли работает ПО при заданном наборе условий.
🔹 Уточнение необходимых обновлений ПО: Тест-кейсы помогают точнее определить, какие доработки и обновления необходимы.
🔹 Лучшее покрытие тестами: Тест-кейсы помогают убедиться, что все возможные сценарии протестированы и задокументированы.
🔹 Последовательность выполнения тестов: Тест-кейсы помогают поддерживать последовательность в выполнении тестов. Хорошо задокументированный тест-кейс позволяет тестировщику просто ознакомиться с ним и приступить к тестированию приложения.
🔹 Полезны при сопровождении: Благодаря своей детализации, тест-кейсы способствуют эффективному сопровождению и поддержке ПО.
Шаблон тест-кейса
Шаблон тест-кейса — это простой и структурированный формат, который используется для создания тест-кейсов в тестировании. Он помогает писать тесты понятно и последовательно.
- Шаблон тест-кейса включает шапку, в которой указываются параметры, предоставляющие информацию о тест-кейсе, такие как имя тестировщика, описание тест-кейса, предварительные условия и др.
- Основная часть содержит непосредственное содержание тест-кейса: ID тест-кейса, шаги выполнения, входные данные, ожидаемый результат и прочее.
Ниже приведена таблица с базовым шаблоном тест-кейса:
| Поля | Описание |
|---|---|
| ID тест-кейса (Test Case ID) | Уникальный идентификатор для каждого тест-кейса. |
| Описание тест-кейса (Test Case Description) | Краткое и понятное описание, чтобы тестировщики понимали, что именно проверяется. |
| Предусловия (Pre-Conditions) | Условия, которые должны быть выполнены перед началом тестирования. |
| Шаги тестирования (Test Steps) | Подробное описание всех шагов, которые выполняются с точки зрения конечного пользователя. |
| Тестовые данные (Test Data) | Данные, используемые в качестве входных при выполнении теста. |
| Ожидаемый результат (Expected Result) | Результат, который должен быть получен после выполнения теста. |
| Постусловия (Post Condition) | Условия, которые должны быть выполнены после успешного завершения теста. |
| Фактический результат (Actual Result) | Результат, который система выдала после выполнения теста. |
| Статус (Status) | Установите статус прошёл тест (Pass) или нет (Fail), на основе сравнения ожидаемого и фактического результата. |
| Название проекта (Project Name) | Название проекта, к которому относится тест-кейс. |
| Название модуля (Module Name) | Название модуля, к которому относится тест-кейс. |
| Ссылка на документ (Reference Document) | Путь к документу, который использовался в качестве источника для тест-кейса. |
| Создано (Created By) | Имя тестировщика, создавшего тест-кейс. |
| Дата создания (Date of Creation) | Дата создания тест-кейса. |
| Проверено (Reviewed By) | Имя тестировщика, который проверил тест-кейс. |
| Дата проверки (Date of Review) | Дата, когда был проведён обзор тест-кейса. |
| Выполнено (Executed By) | Имя тестировщика, который выполнял тест. |
| Дата выполнения (Date of Execution) | Дата проведения тестирования. |
| Комментарии (Comments) | Комментарии, которые помогут команде лучше понять тест-кейс. |
Рассмотрим пример шаблона тест-кейса для проверки функционала входа в систему (Login) с его параметрами и значениями:
В приведённом примере видно, что раздел от Название модуля до Тестового сценария составляет шапку тест-кейса, а таблица ниже, начиная от ID тест-кейса и до Комментариев — это основная часть тест-кейса.
Лучшие практики написания тест-кейсов
Существуют определенные практики, которых стоит придерживаться при написании тест-кейсов, чтобы сделать их максимально эффективными.
- Простота и ясность: Тест-кейсы должны быть краткими, понятными и прозрачными. Они должны легко восприниматься не только самим автором, но и другими участниками команды.
- Требования клиента/заказчика/конечного пользователя должны быть уникальными: При написании тест-кейсов важно следить за тем, чтобы они не дублировались и каждый тест-кейс отличался от остальных.
- Отсутствие предположений: Тест-кейсы не должны содержать предполагаемые данные и включать функции или модули, которых на самом деле нет.
- Прослеживаемость: Тест-кейсы должны быть легко прослеживаемыми для будущих ссылок, поэтому при их написании важно учитывать этот момент.
- Различные входные данные: При написании тест-кейсов необходимо учитывать все типы данных.
- Чёткое название модуля: Название модуля при написании тест-кейса должно быть понятным и однозначным.
- Краткое описание: Описание тест-кейса должно быть небольшим — обычно достаточно одной-двух строк, но при этом оно должно чётко передавать суть и давать общее представление о проверяемом функционале.
- Максимальное количество условий: При написании теста следует учитывать все возможные условия, что повысит его эффективность.
- Соответствие требованиям: При написании тест-кейса необходимо учитывать и выполнять требования клиента, заказчика или конечного пользователя.
- Повторяемость результатов: Тест-кейс должен быть написан так, чтобы при повторном выполнении выдавать тот же результат.
- Разные техники: Иногда невозможно протестировать все условия, но использование различных техник тестирования и разнообразных тест-кейсов помогает охватить все аспекты работы ПО.
- Создание тест-кейсов с точки зрения конечного пользователя: Тест-кейсы должны разрабатываться с позиции конечного пользователя и соответствовать требованиям заказчика.
- Используйте уникальный ID тест-кейса: Хорошей практикой считается использование уникального ID для каждого тест-кейса с соблюдением принятой схемы наименования для лучшего понимания.
- Указывайте корректные предусловия и постусловия: Предусловия и постусловия для тест-кейсов должны быть описаны четко и ясно.
- Тест-кейсы должны быть повторно используемыми: При изменениях в коде, внесённых разработчиками, тестировщикам необходимо обновлять тест-кейсы в соответствии с новыми требованиями
- Указывайте точный ожидаемый результат: Необходимо явно прописывать, какой результат должен быть получен на каждом шаге теста.
Инструменты управления тест-кейсами
Инструменты управления тест-кейсами играют важную роль в эффективной организации тестирования, позволяя сократить затраты времени и ускорить процесс по сравнению с традиционными подходами.
Они предоставляют такие возможности, как расширенные дашборды, отслеживание багов и прогресса, настраиваемые шаблоны, а также интеграцию с другими средствами тестирования.
Ниже приведены некоторые инструменты управления тест-кейсами:
🔸 TestLink — обеспечивает простую интеграцию с системами баг-трекинга и имеет удобный интерфейс для работы с тест-кейсами, тест-планами и тестовыми прогонами.
🔸 TestRail — предоставляет данные о ходе тестирования в режиме реального времени и улучшает сотрудничество между QA-командами, помогая оптимизировать процесс управления тест-кейсами.
🔸 PractiTest — инструмент для организации тест-кейсов, создания тест-планов и генерации подробных отчетов. Поддерживает интеграцию с системами баг-трекинга и другими инструментами тестирования.
🔸 TestCollab — инструмент для управления тест-кейсами, тест-планами и ходом тестирования. Он предоставляет мощные функции отчетности и аналитики, позволяя командам получать ценные данные о процессе тестирования.
🔸 Kualitee — это комплексная платформа для управления тест-кейсами, поддерживающая как ручное, так и автоматизированное тестирование. Она предлагает функции создания, выполнения и отслеживания тест-кейсов, а также обеспечивает надежную интеграцию с системами баг-трекинга.
🔸 Qase — интуитивно понятный инструмент управления тестированием, поддерживает выполнение ручных тестов, интегрируется с CI/CD-пайплайнами и предоставляет расширенные функции отчетности.
🔸 Testiny — лёгкий инструмент для управления тестированием с интуитивно понятным интерфейсом для работы с тест-кейсами. Он обеспечивает простой контроль за выполнением тестов и способствует эффективному взаимодействию внутри команды.
🔸 TestMonitor — платформа для управления тест-кейсами, созданная для улучшения командного взаимодействия. Она предлагает широкий набор функций, включая управление тест-кейсами, создание тест-планов, отслеживание багов и подробную отчетность.
🔸 SpiraTest — позволяет пользователям управлять тест-кейсами, багами и требованиями в одной платформе.
Формальные и неформальные тест-кейсы
➤ Формальные тест-кейсы — это тест-кейсы, которые строго следуют установленному формату. Они содержат параметры теста, такие как условия, уникальный идентификатор, название модуля и другие. В формальных тест-кейсах заранее задаются входные данные и ожидаемые результаты, а выполнение происходит строго по заданной последовательности шагов.
➤ Неформальные тест-кейсы — это тест-кейсы, которые не придерживаются стандартного формата. Они пишутся в процессе проведения тестирования, то есть в реальном времени. Кроме того, входные данные и ожидаемые результаты не задаются заранее.
Типы тест-кейсов
- Функциональный тест-кейс: Предназначен для проверки, насколько интерфейс ПО корректно взаимодействует с остальной системой и её пользователями. При проведении такого теста обычно применяется метод «чёрного ящика», то есть тестирование происходит снаружи, без анализа внутренней структуры.
- Юнит тест-кейс: Проверяет отдельную часть или отдельный модуль ПО. Каждый отдельный компонент тестируется отдельно, и для него создаётся свой тест-кейс.
- Тест-кейс пользовательского интерфейса (UI): Проверяется каждый элемент UI, с которым взаимодействует пользователь. Цель — убедиться, что все требования к UI, предъявленные пользователем, выполнены.
- Тест-кейс интеграционного тестирования: Проводится после объединения всех модулей ПО. Оно направлено на проверку того, как компоненты взаимодействуют между собой и работают ли они корректно в связке, без сбоев.
- Тест-кейс производительности: Помогает определить время отклика и общую эффективность системы или ПО. Его цель — проверить, справляется ли приложение с нагрузкой при реальных условиях эксплуатации.
- Тест-кейс базы данных: Также известен как бэкенд-тестирование или тестирование данных. Проверяется корректность работы с базой данных — тестируются таблицы, схемы, триггеры и другие элементы, чтобы убедиться, что всё функционирует правильно.
- Тест-кейс безопасности: Помогает определить, правильно ли приложение ограничивает действия и доступы там, где это необходимо. Основными задачами являются проверка шифрования и аутентификации. Такие тест-кейсы проводятся для защиты и обеспечения безопасности данных ПО.
- Тест-кейс юзабилити: Проверяет, насколько программное обеспечение удобно для пользователя и легко ли им пользоваться.
- Тест-кейс приёмочного тестирования: Создаётся командой тестировщиков, но тестирование и проверку его выполнения проводит пользователь или клиент в реальных условиях эксплуатации.
Преимущества написания качественных тест-кейсов
Написание качественных тест-кейсов имеет множество преимуществ, которые повышают эффективность и результативность процесса тестирования.
Вот некоторые из них:
✅ Улучшенное покрытие тестами
✅ Повышение качества коммуникации
✅ Согласованность и повторяемость
✅ Эффективное выявление дефектов
✅ Улучшение автоматизации тестирования
✅ Повышение уверенности в качестве ПО
Примеры тест-кейсов для страницы входа
Ниже приведён пример подготовки различных тест-кейсов для страницы входа с полями для имени пользователя и пароля.
- Юнит тест-кейс: Проверяется, принимает ли поле «имя пользователя» ввод длиной не менее восьми символов.
| ID тест-кейса | Условие теста | Шаги | Входные данные | Ожидаемый результат | Фактический результат | Статус | Примечания |
|---|---|---|---|---|---|---|---|
| 1. | Проверить, принимает ли поле имени пользователя ввод из 13 символов | Ввести данные | geeksforgeeks | Принимает 13 символов. | Принимает ввод из 13 символов | Pass | Нет |
В данном случае проверяется только, принимается ли ввод из 13 символов. Так как в поле было введено слово «geeksforgeeks» (13 символов), тест считается успешным.
- Функциональный тест-кейс: Проверяется, корректно ли обрабатываются имя пользователя и пароль при попытке входа.
| ID тест-кейса | Условие теста | Шаги | Входные данные | Ожидаемый результат | Фактический результат | Статус | Примечания |
|---|---|---|---|---|---|---|---|
| 1. | Проверить, что с помощью правильного имени пользователя и пароля можно войти в систему. | 1. Ввести имя пользователя 2. Ввести пароль 3. Нажать кнопку входа | имя пользователя: geeks пароль: geeksforever | Вход выполнен успешно | Вход выполнен успешно | Pass | Нет |
| 2. | Проверить, что при неправильном имени пользователя и пароле невозможно войти в систему. | 1. Ввести имя пользователя 2. Ввести пароль 3. Нажать кнопку входа | имя пользователя: geeksforgeeks пароль: geekstogether | Вход не выполнен | Вход не выполнен | Pass | Нет |
Здесь проверяется, как система реагирует на правильные и неправильные данные: работает ли функциональность входа. В случае правильных учетных данных отображается сообщение об успешном входе, а при неправильных — об ошибке. Таким образом, оба теста пройдены успешно.
Тест-кейс приёмочного тестирования: Учитывается обратная связь от пользователя — загружается ли страница входа корректно.
| ID тест-кейса | Условие теста | Шаги | Входные данные | Ожидаемый результат | Фактический результат | Статус | Примечания |
|---|---|---|---|---|---|---|---|
| 1. | Проверить, корректно ли загружается страница для клиента. | Нажать на кнопку входа | Нет | Появляется сообщение «Добро пожаловать на страницу входа» | Сообщение отсутствует | Fail | Страница входа в систему не загружается из-за проблемы совместимости браузера на стороне пользователя. |
Здесь проверяется, загружается ли страница входа при нажатии на кнопку «Войти» и отображается ли сообщение «Добро пожаловать на страницу входа». Тест завершился неудачно, так как страница не загрузилась из-за проблемы с совместимостью браузера.
Заключение
Написание эффективных тест-кейсов — важная часть процесса тестирования. Это помогает обеспечить всестороннюю проверку системы и своевременное выявление и устранение ошибок ещё на ранних этапах разработки.
Хорошие тест-кейсы должны быть понятными, простыми для восприятия и охватывать все возможные сценарии. Это гарантирует, что ПО работает корректно, обладает необходимой производительностью и является надёжным.
Следуя структурированному подходу к созданию тест-кейсов, тестировщики могут повысить качество продукта, сократить количество дефектов и убедиться в том, что ПО соответствует требованиям и ожиданиям пользователей и заинтересованных сторон.
Перевод статьи «How to write Test Cases – Software Testing».