Перевод статьи «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 заключается в поиске ошибок и дефектов. Чем лучше мы организованы, тем больше шансов находить проблемы более эффективно!