Функциональные тест-кейсы: примеры

Перевод статьи «Best Examples of Functional Test Cases»

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

Стандарт IEEE 610 (1990) определяет понятие тест-кейса следующим образом:

  • “(1) Набор тестовых входных данных, условий выполнения и ожидаемых результатов, разработанный для конкретной цели, например, для отработки определенного пути программы или проверки соответствия определенному требованию”.
  • “(2) (IEEE Std 829-1983) Документация, определяющая входные данные, прогнозируемые результаты и набор условий выполнения для элемента тестирования”.

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

Кроме того, тест-кейсы можно разделить на различные категории, такие как графический интерфейс, функциональные и т.д.

БЕСПЛАТНО СКАЧАТЬ КНИГИ в телеграм канале "Библиотека тестировщика"

Что такое функциональный тест-кейс?

Тест-кейс, который охватывает конкретную функциональность приложения, можно назвать “функциональным”. Он привязывается к определенной функции или возможности приложения и проверяет, работает ли она в соответствии с ожидаемым результатом, указанным в документе функциональной или бизнес-спецификации.

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

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

Что должен содержать функциональный тест-кейс?

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

  • Порядковый номер.
  • Заголовок – описание сути проверки.
  • Предварительные условия в соответствии с требованиями.
  • Шаги, необходимые для выполнения теста.
  • Ожидаемый результат.
  • Фактический результат.
  • Примечания – в случае необходимости предоставления дополнительной информации.

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

  • Выведенное сообщение об ошибке.
  • Логи ошибок.
  • Снимок экрана с изображением проблемы.
  • Точные шаги для воспроизведения проблемы.

Как написать функциональный тест-кейс?

Рассмотрим пример функциональности входа в систему и напишем несколько тест-кейсов.

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

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

Приведем несколько примеров тест-кейсов, которые можно использовать для проверки функциональности входа в систему:

примеры тест-кейсов, которые можно использовать для проверки функциональности входа в систему

Как написать хороший тест-кейс для качественного продукта?

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

Всегда указывайте шаги в тест-кейсе, это облегчает работу разработчикам.

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

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

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

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

Репозиторий Github

Этот репозиторий GitHub содержит общие тест-кейсы для проведения ручного тестирования Web/Mobile приложения. В нем также имеются примеры, связанные с тестированием API, и шаблоны, связанные с тест-планом и BugBash.

Заключение

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

Надеемся, вы получили более полное представление и полезные знания об этой теме.

Удачного тестирования!

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

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