- Что такое тест-кейс и зачем он нужен
- Чем отличается от чек-листа
- Типы тест-кейсов
- Атрибуты тест-кейса ручного тестирования
- Характеристики хорошего тест-кейса
- Лучшие практики
- Написание тест-кейсов
- Примеры тест-кейсов ручного тестирования
- Часто задаваемые вопросы по тест-кейсам
Во время тестирования QA-инженер работает с большим количеством документации. Чеклисты, наборы тестов, тестовые сценарии, планы тестирования, отчеты о тестировании, анализ тестирования — это лишь часть списка документов, которые должны уметь создавать тестировщики. Здесь речь пойдет о тест-кейсах.
Что такое тест-кейс и зачем он нужен
Тест-кейс — это четкое описание действий, которые нужно выполнить для проверки отдельной функции вашего приложения.
Тестировщик создает тест-кейс, чтобы проверить, работает ли определенная фича должным образом, и чтобы подтвердить, что функционал, UI/UX и другие параметры системы удовлетворяют всем соответствующим стандартам, руководствам и требованиям клиентов.
Чем отличаются тест-кейс и чеклист
Тест-кейсы используются для сложных проектов. Например, когда от поведения системы зависит человеческая жизнь. Это могут быть проекты, связанные с пожарной безопасностью, здравоохранением, финансами и т. д. В таких случаях все нужно тестировать очень тщательно.
Чеклист QA — это список того, что нужно протестировать. Благодаря ему процесс тестирования проходит более четко и аккуратно.
Обычно при работе с простыми системами — сайтами, мобильными приложениями и т. д. — нет необходимости в тест-кейсах. Часто в команде бывает только один-два тестировщика, которые хорошо знают свой продукт. В таком случае время, потраченное на создание и поддержку тест-кейсов, никогда не окупится. Лучше создать чеклист со списком функций, которые нужно проверить — это будет более рационально.
Позитивные, негативные и деструктивные тест-кейсы
В позитивных тест-кейсах используются корректные входные данные и сценарии ожидаемой работы системы. Цель здесь — убедиться, что программный продукт выполняет то, что должен делать, и что система не выдаст ошибку, если это не предусмотрено.
В целом позитивное тестирование гарантирует, что система соответствует требованиям при позитивных сценариях нормального использования.
Например, если поле пароля принимает десять символов, пользователь должен иметь возможность создать такой пароль.
Негативные тест-кейсы используют некорректные входные данные и проверяют, не делает ли программа того, чего не должна делать. Негативное тестирование призвано гарантировать, что при получении некорректных входных данных система не будет работать по нормальному сценарию (например, выбросит ошибку).
Если вернуться к нашему примеру, пользователь не должен иметь возможность создать пароль, состоящий из 11 символов.
Деструктивные тест-кейсы создаются, чтобы узнать предел прочности системы. Нагрузочное тестирование — распространенный вариант деструктивного тестирования.
Для деструктивного тестирования QA-специалисты могут применять следующие методы:
- создание большой нагрузки на систему, чтобы это привело к ее отказу;
- злонамеренное внедрение JavaScript в веб-форму;
- фаст-кликинг в попытках взломать веб-страницу и т. д.
Атрибуты тест-кейса для ручного тестирования
Как и все тестировочные документы, тест-кейс имеет определенный формат. Он содержит следующие атрибуты:
- ID — уникальное сочетание букв и цифр.
- Заголовок — основная идея тест-кейса, краткое описание его сути. Например, заголовок тест-кейса для ручного тестирования страницы входа может выглядеть следующим образом: «Проверить вход пользователя с корректными данными».
- Предусловия — список действий, которые необходимо выполнить перед выполнением тест-кейса. При необходимости здесь могут указываться учетные данные.
- Шаги — описание действий, необходимых для проверки.
- Постусловия — список действий, возвращающих систему в исходное состояние (указывается при необходимости).
- Ожидаемый результат — то, что мы ожидаем получить после успешного выполнения тест-кейса.
- Фактический результат — то, что мы получаем после выполнения тест-кейса (указывается при необходимости).
- Статус — Success (успех), Failed (провал), Blocked (блокировка) (указывается при необходимости).
Кроме того, для некоторых тест-кейсов могут потребоваться дополнительные атрибуты:
- Требования к среде — специальное оборудование, программное обеспечение и т. п. вещи, необходимые для выполнения тест-кейса и не перечисленные в соответствующей спецификации проекта тестирования.
- Специальные процедурные требования — особые процедуры настройки, выполнения или очистки, уникальные для этого тест-кейса.
- Межкейсовые зависимости — тест-кейсы, которые нужно выполнить перед этим тест-кейсом.
Характеристики хорошего тест-кейса
Прежде всего, тест-кейс не должен быть зависимым или связанным с другими тест-кейсами. Он должен быть полным и самодостаточным. Следует избегать расплывчатых описаний шагов или ожидаемых результатов. Любые ограничения, отсутствие необходимой информации или чрезмерное количество деталей делают тест-кейсы менее эффективными.
Короче говоря, хороший тест-кейс:
- понятен любому члену команды;
- аккуратно и точно написан;
- соответствует требованиям;
- воспроизводим;
- пригоден для многократного использования.
Best practices в написании тест-кейсов
Под best practices мы подразумеваем правила, которые помогают создавать простые, понятные и полезные тест-кейсы:
- Перед созданием нового тест-кейса убедитесь, что он не дублирует ни один из уже существующих в системе.
- Убедитесь, что тест-кейс покрывает 100% требований, которые вы должны проверить.
- Помните о теории методов тестирования, таких как анализ граничных значений, разделение эквивалентности, техника перехода состояния, угадывание ошибок.
- Помимо требований к системе, всегда помните о конечном пользователе, который будет взаимодействовать с системой.
- Не забудьте указать учетные данные, если они необходимы для выполнения теста.
- Позаботьтесь о тестировщиках, которые будут работать с этим тест-кейсом в будущем. В частности, убедитесь, что все ссылки верны и кликабельны. Пожалуйста, не используйте ссылки на продакшен.
- Используйте повелительное наклонение, например: «Перейдите на главную страницу», «Введите данные», «Кликните» и т. д. Такая формулировка упрощает понимание этапов тестирования и ускоряет их выполнение.
Формирование тест-кейсов
Обычно при написании тест-кейсов тестировщики пользуются таблицами Excel. Но вы также можете использовать инструменты управления тестированием, такие как TestRail.
Примеры тест-кейсов для ручного тестирования
Позитивный тест-кейс
Давайте попробуем создать наш собственный тест-кейс для ручного тестирования функции поиска на e-commerce сайте компании FootWear. Начнем с позитивного теста.
ID: FWSF-1. (Лучше использовать числа в возрастающем порядке. FWSF = FootWear Search Functionality. Попробуйте придумать комбинацию букв, имеющую отношение к проекту или функции, которую вы собираетесь тестировать).
Заголовок: Проверить результаты поиска с корректными входными данными. (Узнать, какие значения допустимы, мы можем в требованиях).
Предусловия: Нужно иметь предварительно настроенные продукты из разных категорий, отображаемые на сайте. (Для проверки функциональности нам необходимо иметь элементы, доступные для поиска. Вы можете настроить это в панели администратора или в базе данных).
Шаги:
- Откройте домашнюю страницу. (Ссылка не обязательна, ее наличие может затруднить поддержку тест-кейса в будущем).
- Введите в поле поиска ключевое слово, связанное с названием доступного продукта.
- Выполните поиск, кликнув значок поиска или нажав Enter.
- Проверьте результаты.
Ожидаемый результат: На странице результатов поиска отображаются все релевантные результаты.
Деструктивный тест-кейс
Еще один пример — деструктивный тест-кейс.
ID: FWSF-2.
Заголовок: Проверить устойчивость поиска к SQL-инъекциям.
Предусловия: Подготовьте SQL-запрос, который вы собираетесь вставить в поиск.
Шаги:
- Откройте домашнюю страницу.
- Введите SQL-запрос в поле поиска.
- Выполните поиск, кликнув значок поиска или нажав Enter.
- Проверьте, правильно ли отображаются результаты, нет ли сообщений об ошибках на странице результатов поиска.
Ожидаемый результат: Для защиты от SQL-инъекций отображение предупреждающих сообщений должно быть отключено.
Негативный тест-кейс
Наконец, вот вам негативный тест-кейс.
ID: FWSF-3.
Заголовок: Проверить ввод на недопустимые значения.
Предусловия: Выпишите недопустимые значения для поля ввода поиска из системных требований.
Шаги:
- Откройте домашнюю страницу.
- Введите комбинацию недопустимых значений в поле поиска.
- Выполните поиск, кликнув значок поиска или нажав Enter.
- Проверьте, отображается ли предупреждающее сообщение «Пожалуйста, используйте только допустимые символы».
Ожидаемый результат: Отображается предупреждающее сообщение «Пожалуйста, используйте только допустимые символы». Поиск можно продолжить.
Итоги
Итак, мы разобрали основы написания тест-кейсов. Совет напоследок: чтобы проверить, насколько хорош ваш тест-кейс, покажите его человеку, который ничего не знает о проекте, над которым вы работаете. Вопросы, которые вы услышите, помогут определить слабые места вашего тест-кейса. Обратите внимание на эти моменты и постарайтесь внести изменения как можно скорее, иначе в будущем для поддержки тест-кейсов потребуется гораздо больше времени и усилий.
Контрольные вопросы и часто задаваемые вопросы по тест-кейсам
Что такое тест-кейс?
Одна из форм проверки, которую проводит QA-инженер. По сути алгоритм действий при проверке и результаты в четкой строгой форме.
Что такое тест-кейс простыми словами?
Совсем простыми словами: Выписанные в столбик действия, которые проверяют программу, и что получилось.
Пример тест-кейса?
1. Название или номер
2. Предусловие
3. Действие
4. Ожидаемый результат
Что должно быть в тест-кейсе?
Стандартные составляющие тест-кейса:
- Уникальный номер, по которому на него будут ссылаться другие тестовые артефакты
- Краткое описание, из которого понятно предназначение
- Входные данные
- Пошаговые действия
- Ожидаемый результат
- Полученный результат
- Статус
Что такое хороший тест-кейс?
Полный, точный и понятный. Четко описаны все шаги и результаты. Легко воспроизводимый другим тестировщиком.
Когда писать тест-кейсы?
Зависит от проекта и от задач. Тест-кейсы пишут в процессе разработки, до старта тестирования, иногда во время и даже после этапа тестирования.
Как должен выглядеть тест-кейс?
Имеется в виду оформление. Тест-кейс должен быть с четкими формулировками, содержать детальную, но не избыточную информацию.
Как описать тест-кейс?
То есть что должно быть в его секции заголовка: краткое, но ёмкое описание конкретной цели тест-кейса — что он будет проверять.
Как правильно называть тест-кейсы?
То есть, каким должно быть идеальное название тест-кейса. Помимо того что название («тема») должно быть кратким, ёмким и понятным не только вам, название может зависеть от того, высокоуровневым (дымовым, интеграционным или системным) или низкоуровневым является этот тест-кейс. Высокоуровневый, без конкретных входных данных и ожидаемых результатов, походящий на тестовый сценарий, может быть назван более широко и удобочитаемо. А в целом, название должно как можно чётче обозначать предназначение.
В чем разница между тест-кейсом и чек-листом?
Самая важная разница: в чек-листе не будет детализации. Чеклист не описывает подробно все шаги, а просто их перечисляет.
Кто пишет тест-кейсы?
Тестировщик. В зависимости от сложности задачи, джуниору и даже стажёру могут доверить написание простых тест-кейсов.
Сколько шагов должно быть в тест-кейсе?
В общем и целом, в стандартном тест-кейсе лучше не делать больше 3-4 шагов.
Если же речь идет о например комплексных/сквозных/системных тест-кейсах, то там может быть их больше.
Сколько тест-кейсов может быть на проекте?
Зависит от проекта. Бывают сотни, тысячи и даже десятки тысяч тест-кейсов в очень крупных и многолетних корпоративных проектах.
Чего не должно быть в тест-кейсе?
- (в идеале) Зависимости от других
- Нечетких формулировок шагов
- Нечетких формулировок ожидаемых результатов
- Излишней детализации
Какие виды тест-кейсов бывают?
Например позитивные (проверяющие ситуации «когда всё ОК») и негативные («когда что-то пользователь делает не ОК»).
По предназначению можно разделить на функциональные, приемочного тестирования, нагрузочного и стрессового, дымового и санитарного — много видов со своими особенностями.
В чем разница между баг-репортом и тест-кейсом?
Тест-кейс описывает конкретный тест для выполнения, а баг-репорт представляет собой структурированное сообщение («доклад») о найденном баге.
Где создать тест-кейс?
Чаще всего в обычной таблице в Экселе ). Но давно существуют удобные инструменты для создания тест-кейсов, а также их упорядочивания, запуска, контроля, и генерации и хранения отчетов по результатам. Например, есть инструменты TestLink и TestRail.
Что проверяет тест-кейс?
Чаще всего («статистически») предметом проверки тест-кейсов являются кнопки, поля ввода и т.п.
Где применяются тест-кейсы?
Видимо спрашивают, в каких проектах/сферах необходимо применение именно тест-кейсов (а не других тестовых артефактов подобного предназначения). Это, в первую очередь, медицинские системы, навигационные системы, системы управления АЭС, заводское ПО и подобные важные сферы. Такому ПО нужно очень тщательное тестирование «до последней точки», и для этого нужны тестовые артефакты именно этого типа.
А почему в тест-кейсах нужны четкие шаги? Нельзя как-то более плавно и human-friendly?
Само предназначение тест-кейса приводит к необходимости его четкой структуризации. Шаги (этапы) нужны, чтобы получить предусловия, выполнить действия, привести тестировщика к фактическому результату и четко видеть результат.
Как писать шаги в тест-кейсе?
По возможности кратко. Не стОит описывать этапы (шаги) уж слишком подробно. Например, лучше писать «Введите свой мейл», а не «Введите свой адрес электронной почты не забыв о @»
Как определить приоритет в тест-кейсе?
Приоритет, показывающий важность тест-кейса, в разных инструментах может выражаться обозначениями A-B-C-D-E в порядке уменьшения приоритета, или цифрами 1…5, или словесно (от «крайне высокого» до «низкого»).
При присвоении приоритета тест-кейсу следует учитывать: важность требования/пользовательского сценария/ функции, с которыми связан этот тест-кейс; потенциальную важность дефекта, на поиск которого ориентирован тест-кейс; степень риска.
Когда нужно выбирать тест-кейс, а когда чек-лист?
Чек-лист лучше подходит, когда система не очень сложная, а тестирование проводят люди, хорошо знакомые с продуктом.
Тест-кейсы лучше, когда система сложная, комплексная, многокомпонентная или очень важная, а тестировать будут обычные тестировщики из QA-отдела, менее вовлечённые в продукт чем его создатели.
Каким может быть исход тест-кейса?
Результатом может быть или его (успешное) прохождение/выполнение (pass), или неуспешное/»провал»/fail.
Сколько времени нужно на написание тест-кейса?
Зависит от проекта и от опыта, простой несколько минут, сложный 10-20 минут и более.
А когда не нужно писать тест-кейсы?
Когда тестируется простая система. Например, веб-сайт «одностраничник», или очень простое мобильное приложение. Или в проекте, в котором всего один или два тестировщика, хорошо знакомые с продуктом, им проще чеклисты.
На каком этапе составляют тест-кейсы?
«Классический» ответ: на этапе тест-дизайна. То есть на этапе, когда тест-кейсы проектируются и создаются.
Есть ли разница между тест-кейсом и тестовым случаем?
Вообще нет, не должно, это просто разные названия одного и того же тестового артефакта. В некоторых русскоязычных источниках, впрочем, «случаем» называют низкоуровневый тест-кейс.
Готовые тест-кейсы — есть где-то?
Разумеется есть, ищите «шаблоны тест-кейсов».
Например примеры и шаблоны тест-кейсов для интернет-магазина, или тест-кейсы для сайта, или для формы регистрации/авторизации?
Да, все это есть в интернете.
Ответы на ВСЕ вопросы ищите здесь в Телеграме (через поиск в канале). Найдется всё!
