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

Перевод статьи «How to write and Test Cases to improve software Quality».

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

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

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

Друзья, поддержите нас вступлением в наш телеграм канал QaRocks. Там много туториалов, задач по автоматизации и книг по QA.

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

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

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

Поле “Описание” (Description) в тест-кейсе описывает конкретную часть приложения, которую вы тестируете, либо поведение пользователя в определенных условиях. Например:

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

Шаги воспроизведения описывают, что необходимо сделать для проведения тестирования, например:

• Новый пользователь открывает главную страницу
• Нажимает на поле поиска
• Вводит в поисковую строку название конкретного продукта, например “браслет”
• Нажимает клавишу Enter
• Пользователь попадает на страницу результатов поиска

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

Пользователь должен иметь возможность осуществить поиск продукта, а приложение должно отображать страницу релевантного продукта или категории.

Дополнительные поля в тест-кейсе

• ID тест-кейса
• Предварительные условия
• Постусловия
• Окружение
• Добавление скриншотов или видео
• Прошел / Не прошел

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

Давайте посмотрим, как выглядит тест-кейс в простом формате Excel.

Пример проекта

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

• Возьмем сайт электронной коммерции www.artsyjewels.com. Пользователь или клиент ожидает, что сайт будет соответствовать стандартам, с которыми он знаком. Например таким, как удобство использования на мобильных устройствах, функциональность поиска, ввод данных, взаимодействие с кнопками и т. д.
• Пользователь хочет приобрести товар, а сайт должен позволять пользователю легко найти товар и купить его!
• Пользователи могут искать конкретный товар через поиск или переходить к определенной категории в меню. Они ожидают, что им придется пройти весь процесс оформления заказа. Им следует создать учетную запись, добавив личную и платежную информацию, после чего они будут уверены в том, что заказ оформлен с помощью веб-сайта.

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

Мы можем проанализировать приведенный выше пример и разбить функционал на более мелкие задачи:

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

Перечисленные выше сценарии называются позитивными тест-кейсами. Они обычны и просты для выполнения и понимания. Но как тестировщики мы должны думать обо всех способах, которыми пользователь может потенциально “сломать” приложение. Ведь, столкнувшись с сообщением об ошибке или таймаутом страницы, пользователь может уйти с сайта, а это проиведет к потере продажи, что, с точки зрения бизнеса, очень плохо!

Поэтому давайте рассмотрим и некоторые негативные сценарии тест-кейсов:

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

Когда мы начинаем изучать мышление пользователя, мы можем постепенно начать обнаруживать различные “что если”, а это приводит к нахождению дефектов или ошибок!

Почему для поиска дефектов нужны тест-кейсы?

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

• Что делать, если дом построен наполовину?
• Стали бы вы наугад проверять все двери, чтобы убедиться, что они открываются и закрываются?
• Стали бы вы в один день проверять электричество, а в другой – воду? Или начали бы с измерения всех комнат и проверки покраски?

Нет, вы бы создали длинный список вещей, которые нужно проверить!

Когда стены построены, вы проверяете размеры или покраску, когда электричество подведено, вы проверяете все розетки и выключатели, и так далее по списку!

Составив список, вы получите пошаговые инструкции и сценарии, чтобы все аспекты строительства дома были выполнены в соответствии с ожиданиями.

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

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

Кто пишет тест-кейсы и документацию приложения?

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

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

Основная роль QA заключается в поиске ошибок и дефектов. Чем лучше мы организованы, тем больше шансов находить проблемы более эффективно!