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

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

1. Виды тест-кейсов

Тест-кейсы классифицируют по разным критериям.

1. По цели тестирования

• Функциональные — проверяют соответствие работы системы функциональным требованиям.
• Нефункциональные — тестируют производительность, безопасность, удобство использования и другие аспекты.

2. По уровню тестирования

Не оформляются в виде отдельных тест-кейсов, но часто создаются — модульные проверки (или Unit-тесты) — проверяют отдельные компоненты системы, такие как отдельные функции или классы, предполагают «метод белого ящика» (доступ к исходному коду) и всегда автоматизированы. Чаще всего пишутся разработчиками, ошибки, найденные во время прогонов таких тестов как правило не фиксируются в виде баг-репортов, а сразу исправляются.

• Интеграционные — проверяют взаимодействие между различными модулями или компонентами системы, чтобы убедиться, что они корректно работают вместе. Проверить корректность передачи данных между модулями. Обнаружить проблемы совместимости API, форматов данных, структуры БД. Выявить ошибки в логике взаимодействия. Проверить обработку ошибок и отказоустойчивость. Оценить производительность обмена данными и так далее.
• Системные — оценивают работу всей системы в целом, выявляют проблемы, связанные с некорректным использованием системных ресурсов, неожиданными комбинациями пользовательских данных, несовместимостью с окружением, нестандартными сценариями эксплуатации, отсутствующей или некорректной функциональностью, а также неудобством в использовании и другими проблемами. В этих кейсах используется метод «Черного ящика» (без доступа к исходному коду).
• Приёмочные — как правило это «end to end» проверки, используются для финального тестирования перед релизом, когда необходимо протестировать бизнес-процессы от начала до конца. Эти тесты моделируют реальные сценарии использования и помогают убедиться, что система работает корректно в полном цикле.

3. По статусу тестирования

• Позитивные — проверяют, как система работает при корректных данных и ожидаемых сценариях использования, что функциональность работает по назначению без сбоев.
• Негативные — проверяют обработку ошибок и некорректных данных. Позволяют убедиться, что система адекватно обрабатывает ошибки и не допускает неожиданных сбоев, система не должна ломаться, должна выдавать понятное сообщение об ошибке.

Наборы тест-кейсов (тест - сьюты) различают по полноте покрытия:

• Смоук — для быстрого контроля работоспособности системы после сборки. Обычно представляет собой набор наиболее критичных системных тест-кейсов. Эти проверки выполняются в первую очередь, если смоук-тестирование прошло успешно, можно переходить к более детальному тестированию всей системы. В условиях ограниченного времени допускается комбинирование смоук-тестирования с проверкой исправленных дефектов после их устранения в рамках регрессионного тестирования и тестирования нового функционала.
• Регрессионные — проверяют, что исправления дефектов и добавление нового функционала не сломали существующий. Автоматизация регрессионных тест-кейсов значительно ускоряет процесс разработки.

2. Жизненный цикл тест-кейса

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

1. Анализ требований и планирование
   На этом этапе тестировщики изучают технические требования, спецификации, пользовательские сценарии и разрабатывают стратегию тестирования. Определяют, какие тест-кейсы необходимы и на что они будут направлены.
2. Проектирование (разработка) тест-кейсов
   После определения требований тестировщики разрабатывают тест-кейсы, которые описывают, как будет проводиться тестирование. На этом этапе важно учитывать различные сценарии использования, предусловия, шаги выполнения и ожидаемые результаты. Тест-кейсы должны быть четкими, понятными и легко воспроизводимыми. При разработке тест-кейсов применяются техники тест-дизайна.
3. Рецензирование тест-кейсов
   На этом этапе тест-кейсы проходят рецензирование другими членами команды, чтобы убедиться в их полноте и корректности. Рецензирование помогает выявить возможные ошибки или недочеты, а также улучшить качество тест-кейсов перед их выполнением.
4. Подготовка к тестированию
   Перед началом тестирования необходимо подготовить тестовые данные и тестовую среду, включая настройку оборудования, программного обеспечения. Также важно убедиться, что все необходимые инструменты для тестирования доступны и готовы к использованию. Для ручных тестов, в TMS-системе, формируются тестовые прогоны и распределяются на команду тестирования.
5. Выполнение тест-кейсов
   На этом этапе тестировщики запускают автоматизированные тест-кейсы или выполняют тест-кейсы вручную. Проходят по шагам и сравнивают ожидаемый результат с фактическим, после чего обновляют статус шага.
   • passed (пройден) — результат соответствует ожидаемому.
   • failed (провален) — найден дефект, результат не соответствует ожидаемому.
   • blocked (заблокирован) — шаг невозможно выполнить из-за каких-либо проблем, например, из-за дефекта на предыдущем этапе.
   
   Тест-кейсу присваивается статус failed, если есть хотя-бы один проваленный шаг. Тест-кейсу присваивается статус blocked, если есть хотя-бы один заблокированный и нет проваленных шагов. В процессе выполнения тестов фиксируются результаты любые обнаруженные дефекты и замечания.
6. Документирование результатов
   После выполнения тестов результаты должны быть задокументированы. Это включает в себя фиксацию успешности прохождения тестов, а также описание найденных дефектов, определение их критичности и приоритетов. Документация помогает в дальнейшем анализе и отчетности.
7. Анализ и оценка
   Оценка успешности тестирования и обсуждение найденных проблем с командой разработки. Это позволяет выявить области, требующие улучшения, определить, были ли достигнуты цели тестирования и какие дефекты необходимо исправить перед релизом.
8. Поддержка и актуализация тест-кейсов
   Тест-кейсы должны обновляться в связи с изменениями в системе или требованиях. Это может включать в себя добавление новых тестов, изменение существующих или удаление устаревших. Поддержка актуальности тест-кейсов важна для обеспечения их эффективности в будущем.

3. Атрибуты тест-кейса

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

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

Эти атрибуты помогают тестировщикам четко понимать, что именно необходимо проверить и как интерпретировать результаты.

4. Правила составления тест-кейсов

Составление тест-кейсов требует соблюдения определенных правил, чтобы обеспечить их эффективность:

• Ясность и простота — используйте простой и понятный язык. Тест-кейсы должны быть легко читаемыми и понятными для всех членов команды, даже для тех, кто не знаком с проектом.
• Структурированность — следуйте заранее определенному шаблону или формату для всех тест-кейсов. Это поможет поддерживать единообразие и облегчить поиск нужной информации.
• Конкретность — избегайте неопределенности. Каждый тест-кейс должен быть конкретным и четким, чтобы не оставлять места для интерпретаций.
• Полнота — убедитесь, что тест-кейс охватывает все необходимые аспекты. Включайте все шаги, предусловия и ожидаемые результаты.
• Независимость — каждый тест-кейс должен быть независимым от других. Это позволяет выполнять тесты в любом порядке и упрощает отладку.
• Актуальность — тест-кейсы должны обновляться в соответствии с изменениями в требованиях.

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

5. Пример тест-кейса

Пример простого тест-кейса может выглядеть следующим образом:

Идентификатор: TC001

Название: Проверка успешного входа в систему.

Описание: проверить, что пользователь может успешно войти в систему с правильными учетными данными.

Ссылки на документацию: ссылка на требование в документе (например, в матрице трассировки), ссылка на макет, ссылка на Swagger.

Предусловия:

1. Пользователь зарегистрирован в системе.
2. Учетные данные: user@example.com / Password123!.
3. Веб-приложение открыто.

Шаги выполнения:

• Шаг 1: Открыть страницу авторизации.
  Тестовые данные: ссылка
  Ожидаемый результат: Форма входа отображается корректно. Поля ввода E-mail и «Пароль» активны, кнопка "Войти" не активна.
• Шаг 2: Ввести корректный email в поле «Email».
  Тестовые данные: user@example.com
  Ожидаемый результат: Поле "Email" принимает корректные данные, кнопка "Войти" не активна.
• Шаг 3: Ввести корректный пароль в поле «Пароль».
  Тестовые данные: Password123!
  Ожидаемый результат: Поле "Пароль" принимает корректные данные, кнопка "Войти" активна.
• Шаг 4: Удалить данные из поля «Email».
  Тестовые данные: -
  Ожидаемый результат: Кнопка "Войти» стала не активной.
• Шаг 5: Ввести корректный email в поле «Email».
  Тестовые данные: user@example.com
  Ожидаемый результат: Поле "Email" принимает корректные данные, кнопка "Войти" активна.
• Шаг 6: Навести курсор на кнопку «Войти».
  Тестовые данные: -
  Ожидаемый результат: Кнопка поменяла стиль по ховеру в соответствии с макетом ссылка на конкретное место в макете
• Шаг 7: Нажать кнопку «Войти».
  Тестовые данные: -
  Ожидаемый результат: Авторизация успешна: сформирован и отправлен корректный HTTP-запрос (ссылка на метод в Swagger), создана сессия. После обработки запроса пользователь перенаправляется на главную страницу. Отправлен запрос на получение данных о главной странице с токеном в заголовке (ссылка на метод в Swagger), и после успешного ответа загружается главная страница. В правом верхнем углу отображается логин вошедшего пользователя.

Действия после выполнения теста: не требуются.

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

Приоритет: Высокий

Пометка об автоматизации: подлежит автоматизации.

Тип: Функциональный, Позитивный.

Дата создания: 01.01.2025

Дата последнего обновления: 15.01.2025

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

6. Отличия от чек-листа и баг-репорта

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

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

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

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

7. Заключение

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

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

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

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