Как составить кейсы для тестирования

В тестировании, чтобы проверить, корректно ли работает программное обеспечение (ПО), делают определенные действия и сверяют полученный результат с ожидаемым. Другими словами — моделируют ситуацию работы ПО. Чтобы описать шаги, создают тест-кейсы.

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

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

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

Отличия

🚀 От чек-листа

В чек-листе перечисляют аспекты ПО, которые нужно проверить. Когда составляют тест-кейс, описывают состояние программного обеспечения и то, как его изменяют. То есть чек-листом определяют, что тестировать. А тест-кейсом — как тестировать. Чек-лист подойдет в качестве исходного документа, чтобы составить тест-кейсы.

🚀 От баг-репорта

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

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

Классификация зависит от типа входных данных, действий и ожидаемого поведения ПО.

1️⃣ Положительные. Подтверждают, что ПО соответствует требованиям. Показывают, что при корректных входных данных и действиях пользователя ПО выполняет функции.

2️⃣ Отрицательные. Показывают, что ПО способно обрабатывать некорректные входные данные или неверные действия пользователя. Например, выводить соответствующие сообщения, подсказывать, как исправить ситуацию.

3️⃣ Деструктивные. Демонстрируют, что никакие внешние воздействия или высокие нагрузки не приводят к потере данных пользователя, ПО можно использовать. Условие: нагрузки не разрушают аппаратную часть.

Пример 

У вас есть требование к программной системе расписания занятий: «В систему нужно добавлять новые уроки».

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

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

Деструктивные покажут, сохранится ли расписание при сбоях. Например, если внезапно завершат программу или введут огромное количество данных за короткое время.

Жизненный цикл

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

1️⃣ Не запускался. Тест-кейс создали, но тестирование по нему не проводили.

2️⃣ Пройден успешно. Ожидаемые и фактические результаты работы ПО совпадают.

3️⃣ Провален. Обнаружили дефект: ожидаемый результат минимум по одному шагу тест-кейса не совпадает с фактическим.

4️⃣ Пропущен. Тест-кейс отменили. Например, потому что изменили требования к ПО.

Обязательные атрибуты

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

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

✅ Краткое описание — лаконичное описание сути тест-кейса. Может содержать ссылку на требование к ПО.

✅ Входные данные — сведения о первоначальном состоянии системы, которое важно для тест-кейса. А еще значения для ввода или передачи ПО.

✅ Шаги — полная последовательность действий. Ее выполняют, чтобы провести описываемую тест-кейсом проверку.

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

✅ Фактический результат — описание итогового поведения или результата ПО. Если они совпадают, это указывают. Когда не совпадают, подробно описывают расхождения. Пометка «не совпадает», «отличается» — это грубая ошибка.

✅ Статус — текущее состояние тест-кейса.

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

👉 Создавайте простые тест-кейсы. То есть лаконичные и понятные не только вам. Используйте повелительное наклонение, например: «перейдите на домашнюю страницу», «введите данные», «нажмите здесь». Шаги должны быть четкие, без лишних деталей. Так проще понять шаги теста и ускорить работу.

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

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

👉 Не предполагайте. Не додумывайте функциональность и возможности ПО. Строго придерживайтесь спецификации.

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

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

👉 Внедряйте методы тестирования. Эти техники помогают спланировать несколько тест-кейсов и находить ошибки:

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

👉 Внедряйте самоочистку. Тест-кейс должен возвращать среду в предтестовое состояние. Особенно это касается тестирования конфигураций.

👉 Создавайте повторяемые и самостоятельные текст-кейсы. Они должны всегда генерировать одинаковые результаты: независимо от того, кто их тестирует.

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

Учитесь создавать тест-кейсы и системы управления ими на курсе «Инженер по тестированию» Skypro. Кроме этого узнаете, как писать чек-листы и тест-планы, составлять отчеты в системах отслеживания ошибок. Проведете функциональное, UX/UI- и регрессионное тестирование — и это только в одном модуле. На курсе рассмотрим еще и тестирование мобильных приложений и API, инструменты тестировщика.

На курсе больше 330 часов теории и практики, пройдете 7 мастер-классов, создадите 4 проекта для портфолио. Доступ к материалам останется навсегда.

Шаблон и пример тест-кейса

Идентификатор	Описание	Шаги	Входные данные	Ожидаемые результаты	Фактические результаты	Статус
TU01	Проверка входа пользователя с существующими логином и паролем	Откройте сайт http://blahblahblah.ru ↓ Введите логин ↓ Введите пароль ↓ Нажмите кнопку «Войти»	Логин = user99 Пароль = pass99	Пользователь должен попасть на главную страницу	Как ожидали	Пройден успешно
TU02	Проверка входа пользователя с несуществующими логином и паролем	Откройте сайт http://blahblahblah.ru ↓ Введите логин ↓ Введите пароль ↓ Нажмите кнопку «Войти»	Логин = user99 Пароль = badlass99	Пользователь должен остаться на странице логина. Появится сообщение «Неверные логин или пароль»	Как ожидали	Пройден успешно

Главное о тест-кейсах

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

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

Для начинающих поясним, что такое тест-кейс озвучив определение из глоссария терминов ISTQB: 

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

Определение тест-кейса языком обывателя: 

Тест-кейс — это чёткое описание действий, которые необходимо выполнить, для того чтобы проверить работу программы (поля для ввода, кнопки и т.д.). Данное описание содержит: действия, которые надо выполнить до начала проверки — предусловия; действия, которые надо выполнить для проверки — шаги; описание того, что должно произойти, после выполнения действий для проверки — ожидаемый результат. 

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

Обязательные атрибуты для заполнения 

• Номер тест-кейса — уникальный идентификатор тест-кейса (такие системы как TestRail, TestLink и подобные автоматически присваивают тест-кейсам уникальные номера). Если у вас тысячи тест-кейсов, то при общении с коллегами, вам будет удобнее сообщить номер тест-кейса ссылаясь на него, а не пытаться словами рассказать, где и как найти определённый тест-кейс. 
• Заголовок — краткое, понятное и ёмкое описание сути проверки. 
• Предусловия — описание действий, которые необходимо предварительно выполнить или учесть, и которые не имеют прямого отношения к проверке. 
• Шаги проверки — описание последовательности действий, которые необходимо выполнить для проверки. 
• Ожидаемый результат — проверка, которая устанавливает, что мы ожидаем получить, после выполнения определённых действий в соответствующем шаге. 

В зависимости от специфики компании могут присутствовать дополнительные атрибуты для заполнения: приоритет, функциональный блок, программа, ссылка на требование, номер требования и т.д. 

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

1. Заголовок:
   • должен быть чётким, кратким, понятным и однозначно характеризующим суть тест-кейса;
   • не может содержать выполняемые шаги и ожидаемый результат.
2. Предусловие:
   • может содержать полную информацию о состоянии системы или объекта, необходимом для начала выполнения шагов тест-кейса; 
   • может содержать ссылки на информационные источники, которые необходимо изучить перед прохождением тест-кейса (инструкции, описание систем…); 
   • не может содержать ссылки на тестируемый ресурс, если у информационной системы более одной среды (прод, тест, препрод…), данная информация должна быть вынесена в инструкцию, и ссылка приложена в предусловии; 
   • не может содержать данные для авторизации, данная информация должна быть вынесена в инструкцию, и ссылка приложена в предусловии; 
   • не может содержать выполняемые шаги и ожидаемый результат, если нам нужно, чтобы до выполнения шагов проверки у нас была открыта главная страница, то мы в предусловии указываем «открыта главная страница сайта»; 
   • не может содержать ожидаемый результат. 
3. Шаги проверки: 
   • должны быть чёткими, понятными и последовательными; 
   • следует избегать излишней детализации шагов. Правильно: «ввести в поле число 12».
     Неправильно: «нажать на клавиатуре на цифру ‘1’, следующим шагом нажать на клавиатуре на цифру ‘2’»; 
   • должны использоваться безличные глаголы.
     Правильно: нажать, ввести, перейти.
     Неправильно: нажмите, введите, идите; 
   • не должно быть комментариев и пояснений, если есть необходимость привести мини-инструкцию, то оформляем инструкции в базе-знаний и в предусловии ссылаемся на неё; 
   • не должно быть жёстко прописанных статических данных (логины, пароли, имена файлов) и примеров, для исключения эффекта пестицида. 
4. Ожидаемый результат: 
   • должен быть у каждого шага проверки; 
   • должно быть кратко и понятно описано состояние системы или объекта, наступающее после выполнения соответствующего шага; 
   • не должно быть избыточного описания. 
5. Общие требования к тест-кейсам: 
   • язык описания тест-кейсов должен быть понятен широкому кругу пользователей, а не узкой группе лиц; 
   • тест-кейс должен быть максимально независим от других тест-кейсов и не ссылаться на другие тест-кейсы (лучшая практика, когда зависимостей нет вообще); 
   • тест-кейсы группируются в функциональные блоки по их назначению; 
   • в тест-кейсах проверяющих работу функционала скриншотов быть не должно, иначе вы будете посвящать сотни часов на изменение всех скриншотов в тысячах тест-кейсах при изменении интерфейса тестируемой программы. Скриншоты могут быть добавлены только в тест-кейсы проверяющие отображение страниц и форм. 

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

Примеры 

Для наглядности приведу пару примеров. Рассмотрим на примере сайта, на котором вы сейчас находитесь. 

Тест-кейс №1. Корректный

Номер	1
Заголовок	Отправка сообщения через форму обратной связи на странице “Контакты”
Предусловие	Открыта главная страница сайта victorz.ru. Есть доступ к почте администратора сайта victorz.ru
Шаг	Ожидаемый результат
В верхнем меню сайта нажать на ссылку “Контакты”	Открылась страница “Контакты”
Ввести значение в поле “Ваше имя” состоящее из латинских букв, кириллицы	В поле “Ваше имя” отображается введённое имя
Ввести корректный email в поле “Ваш e-mail”	В поле “Ваш e-mail” отображается введённый email
Ввести в поле “Тема” значение состоящее из латинских букв, кириллицы, спецсимволов и чисел	В поле “Тема” отображается введённый текст
Ввести в поле “Сообщение” значение состоящее из латинских букв, кириллицы, спецсимволов и чисел	В поле “Сообщение” отображается введённый текст
Ввести в поле капчи требуемое капчей значение	В поле капчи отображается введённое значение
Нажать под заполняемой формой на кнопку “Отправить”	Под кнопкой «Отправить» появился текст “Спасибо. Ваше сообщение было отправлено.” Все заполненные поля очищены.
Проверить почту администратора сайта	На почту пришло сообщение, отправленное с сайта через форму обратной связи и содержащее в теле сообщения данные введённые на шагах 1-5.

Тест-кейс №2. Некорректный 

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

Номер	1
Заголовок	Отправить сообщение через форму обратной связи (Указываем, что проверяем или что делаем?)
Предусловие	Перейти на главную страницу сайта victorz.ru (Это не предусловие, а описание шага)
Шаг	Ожидаемый результат
Нажать на ссылку “Контакты” (Где она находится?)	Открылась страница (Какая?)
Ввести имя в поле “Ваше имя” (Какие символы вводить?)	(Ничего не указано в ожидаемом результате, что должно произойти?)
Ввести email в поле “Ваш e-mail” (корректный или некорректный?)	В поле отображается email (Какой? Введённый? В каком поле отображается?)
Ввести в поле значение, состоящее из латинских букв, кириллицы, спецсимволов и чисел (В какое поле?)	В поле “Тема” отображается текст (Какой?)
Ввести в поле “Сообщение” текст (Какие символы вводить?)	Видим в поле “Сообщение” введённый текст (Видим или отображается?)
Вводим в поле капчи требуемое капчей значение (Помните только безличные глаголы — Ввести).	В поле капчи будет введённое значение (Что будет делать? Танцевать?)
Нажать под заполняемой формой на кнопку (На какую?)	Появился текст “Спасибо. Ваше сообщение было отправлено.” (Где появится?)
(Последний шаг не заполнен, а это неправильно, так как мы не проверим действительно ли работает отправка писем через форму обратной связи)

Во второй части видео (с 8-й минуты) разбираю на примерах создание тест-кейсов:

Главное в нашем деле практика. Практикуйтесь в написании тест-кейсов. 

Если вы будете вести тест-кейсы в таблице (к примеру в Excel), то можете скачать шаблон тест-кейсов. В файле две вкладки. На одной шаблон единичного тест-кейса, а на второй пример порядка размещения группы тест-кейсов.

Пишем максимально эффективный тест-кейс

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

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

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

Зачем нужны тест-кейсы?

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

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

Любой тест-кейс обязательно включает в себя:

• Уникальный идентификатор тест-кейса — необходим для удобной организации хранения и навигации по нашим тест-наборам.
• Название — основная тема, или идея тест-кейса. Кратное описание его сути.
• Предусловия — описание условий, которые не имеют прямого отношения к проверяемому функционалу, но должны быть выполнены.
  Например, оставить комментарий на вашем портале может только зарегистрированный пользователь. Значит для тест-кейса «Создание комментария» будет необходимо выполнение предусловия «пользователь зарегистрирован», и «пользователь авторизован»
• Шаги — описание последовательности действий, которая должна привести нас к ожидаемому результату
• Ожидаемый результат — результат: что мы ожидаем увидеть после выполнения шагов.

Не обязательно, но желательно добавить в тест-кейс атрибут история редактирования — это сильно облегчит вам жизнь. Лаконичный журнал изменений, где отраженно: кем, как, и когда был изменен тест-кейс.

Что еще необходимо знать, перед созданием тест-кейса?

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

1.Положительный результат, если фактический результат равен ожидаемому результату,
2.Отрицательный результат, если фактический результат не равен ожидаемому результату. В этом случае, найдена ошибка.
3.Выполнение теста блокировано, если после одного из шагов продолжение теста невозможно. В этом случае так же, найдена ошибка.

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

Чего не должно быть в тест-кейсе

1. Зависимостей от других тест-кейсов;
2. Нечеткой формулировки шагов или ожидаемого результата;
3. Отсутствия необходимой для прохождения тест-кейса информации;
4. Излишней детализации.

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

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

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

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

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

В этом материале о тест кейсах вы узнаете:

1. Что такое тест кейс
2. Из чего состоит тест кейс и какая у тест кейсов форма
3. Правила написания хорошего тест кейса
4. Типичные ошибки в тест кейсах

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

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

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

Хотите научиться писать правильные тест кейсы? Научиться писать тест кейсы вам помогут наши менторы-тестировщики!

Форма тест кейса: из чего состоит тест кейс и поля в тест кейсах

У стандартного тест кейса есть 5 частей, то есть 5 атрибутов тест кейса:

1. Порядковый номер тест кейса
2. Название тест кейса. Из него должно быть понятно, в чем суть тест кейса
3. Предусловия тест кейса. Это условия, которые необходимы для проведения тест кейса. Они должны быть выполнены еще до запуска тест кейса.
   Допустим: компания сдает самокаты в поминутную аренду. Нужно провести тест кейс функции, которая уведомляет пользователя о том, что заряд аккумулятора самоката. Предусловием тест кейса будет то, что самокат должен находиться в состоянии аренды
4. Порядок действий в тест кейсе и описания действий в тест кейсе
5. Ожидаемый результат тест кейса.

Вот пример тест кейса:

Как написать хороший тест кейс: правила и форма хороших тест кейсов

У тест кейса может быть 3 вида результатов:

1. Положительный результат тест кейса. Фактический результат тест кейса совпадает с ожидаемым.
2. Отрицательный результат тест кейса. Фактический результат тест кейса отличается от ожидаемого.
3. Тест кейс не завершен. В процессе проверки тест кейса происходит ошибка.

Существуют 6 правил проведения тест кейсов:

1. Один тест кейс должен проверять только одну конкретную вещь.
2. Тест кейс не должен зависеть от других тест кейсов.
3. Шаги и ожидаемый результат тест кейса должны быть сформулированы четко и однозначно.
4. В тест кейсе должна быть вся информация. необходимая для его проведения.
5. В тест кейсе не должно быть лишних деталей.
6. Для каждого шага тест кейса нужно указывать тип вводимых данных: валидный или невалидный.

Прочитайте статью Что такое правильный баг репорт и по какому шаблону его оформить: базовые правила!

Типичные ошибки при написании тест кейсов

Абстрактное название тест кейса
Тест кейсы на одном проекте часто похожи друг на друга. Чтобы в них не было путаницы, названия должны быть конкретными и однозначными.

Плохо: Уведомление пользователя о заряде
Хорошо: Уведомление пользователя о снижении заряда аккумулятора вручную

Повелительное наклонение в тест кейсе
Это правило этикета тестировщиков.

Плохо: зайди на сайт; нажми на кнопку
Хорошо: зайти на сайт, нажать на кнопку

Не кликабельные ссылки
Не важно, это гиперссылки внутри вашей площадки или ссылки на какие-то внешние ресурсы. Вставили ссылку — нажмите «Ctrl + K». Добавьте тексту кликабельности.

Плохо: yandex.ru
Хорошо: yandex.ru

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

Плохо: нажмите на красную кнопку с надписью «Войти» в верхнем правом углу экрана, под меню.
Хорошо: нажмите на кнопку «Войти»

Недостаток деталей для проведения тест кейса
Ошибка, обратная предыдущей. Хороший тест кейс — это тест кейс, все действия которого можно выполнить, основываясь только на тексте самого тест кейса.

Плохо: перейти в режим разработчика
Хорошо:
1) Открыть меню
2) Перейти во вкладку «Дополнительные возможности»
3) Нажать на кнопку «Включить режим разработчика»

Хотите избежать типичных ошибок в тест кейсах? Вам помогут наши менторы-тестировщики!

• Что такое тест-кейс и зачем он нужен
• Чем отличаются тест-кейс и чеклист
• Типы тест-кейсов
• Атрибуты тест-кейса ручного тестирования
• Характеристики хорошего тест-кейса
• Лучшие практики в написании тест-кейсов
• Формирование тест-кейсов
• Примеры тест-кейсов ручного тестирования
  • Позитивный
  • Деструктивный
  • Негативный
• Итоги: тестирование тест-кейса

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

Что такое тест-кейс и зачем он нужен

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

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

Чем отличаются тест-кейс и чеклист

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

Чеклист QA — это список того, что нужно протестировать. Благодаря ему процесс тестирования проходит более четко и аккуратно.

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

Позитивные, негативные и деструктивные тест-кейсы

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

В целом позитивное тестирование гарантирует, что система соответствует требованиям при позитивных сценариях нормального использования. 

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

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

Если вернуться к нашему примеру, пользователь не должен иметь возможность создать пароль, состоящий из 11 символов.

Деструктивные тест-кейсы создаются, чтобы узнать предел прочности системы. Нагрузочное тестирование — распространенный вариант деструктивного тестирования. 

Для деструктивного тестирования QA-специалисты могут применять следующие методы:

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

Атрибуты тест-кейса для ручного тестирования

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

1. ID — уникальное сочетание букв и цифр.
2. Заголовок — основная идея тест-кейса, краткое описание его сути. Например, заголовок тест-кейса для ручного тестирования страницы входа может выглядеть следующим образом: «Проверить вход пользователя с корректными данными».
3. Предусловия — список действий, которые необходимо выполнить перед выполнением тест-кейса. При необходимости здесь могут указываться учетные данные.
4. Шаги — описание действий, необходимых для проверки.
5. Постусловия — список действий, возвращающих систему в исходное состояние (указывается при необходимости).
6. Ожидаемый результат — то, что мы ожидаем получить после успешного выполнения тест-кейса.
7. Фактический результат — то, что мы получаем после выполнения тест-кейса (указывается при необходимости).
8. Статус — Success (успех), Failed (провал), Blocked (блокировка) (указывается при необходимости).

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

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

Характеристики хорошего тест-кейса

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

Короче говоря, хороший тест-кейс:

• понятен любому члену команды;
• аккуратно и точно написан;
• соответствует требованиям;
• воспроизводим;
• пригоден для многократного использования.

Best practices в написании тест-кейсов

Под  best practices мы подразумеваем правила, которые помогают создавать простые, понятные и полезные тест-кейсы:

• Перед созданием нового тест-кейса убедитесь, что он не дублирует ни один из уже существующих в системе.
• Убедитесь, что тест-кейс покрывает 100% требований, которые вы должны проверить.
• Помните о теории методов тестирования, таких как анализ граничных значений, разделение эквивалентности, техника перехода состояния, угадывание ошибок.
• Помимо требований к системе, всегда помните о конечном пользователе, который будет взаимодействовать с системой.
• Не забудьте указать учетные данные, если они необходимы для выполнения теста.
• Позаботьтесь о тестировщиках, которые будут работать с этим тест-кейсом в будущем. В частности, убедитесь, что все ссылки верны и кликабельны. Пожалуйста, не используйте ссылки на продакшен.
• Используйте повелительное наклонение, например: «Перейдите на главную страницу», «Введите данные», «Кликните» и т. д. Такая формулировка упрощает понимание этапов тестирования и ускоряет их выполнение.

Формирование тест-кейсов

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

Примеры тест-кейсов для ручного тестирования

Позитивный тест-кейс

Давайте попробуем создать наш собственный тест-кейс для ручного тестирования функции поиска на e-commerce сайте компании FootWear. Начнем с позитивного теста.

ID: FWSF-1. (Лучше использовать числа в возрастающем порядке. FWSF = FootWear Search Functionality. Попробуйте придумать комбинацию букв, имеющую отношение к проекту или функции, которую вы собираетесь тестировать).

Заголовок: Проверить результаты поиска с корректными входными данными. (Узнать, какие значения допустимы, мы можем в требованиях).

Предусловия: Нужно иметь предварительно настроенные продукты из разных категорий, отображаемые на сайте. (Для проверки функциональности нам необходимо иметь элементы, доступные для поиска. Вы можете настроить это в панели администратора или в базе данных).

Шаги:

1. Откройте домашнюю страницу. (Ссылка не обязательна, ее наличие может затруднить поддержку тест-кейса в будущем).
2. Введите в поле поиска ключевое слово, связанное с названием доступного продукта.
3. Выполните поиск, кликнув значок поиска или нажав Enter.
4. Проверьте результаты.

Ожидаемый результат: На странице результатов поиска отображаются все релевантные результаты.

Деструктивный тест-кейс

Еще один пример — деструктивный тест-кейс.

ID: FWSF-2.

Заголовок: Проверить устойчивость поиска к SQL-инъекциям.

Предусловия: Подготовьте SQL-запрос, который вы собираетесь вставить в поиск.

Шаги:

1. Откройте домашнюю страницу.
2. Введите SQL-запрос в поле поиска.
3. Выполните поиск, кликнув значок поиска или нажав Enter.
4. Проверьте, правильно ли отображаются результаты, нет ли сообщений об ошибках на странице результатов поиска.

Ожидаемый результат: Для защиты от SQL-инъекций отображение предупреждающих сообщений должно быть отключено.

Негативный тест-кейс

Наконец, вот вам негативный тест-кейс.

ID: FWSF-3.

Заголовок: Проверить ввод на недопустимые значения.

Предусловия: Выпишите недопустимые значения для поля ввода поиска из системных требований.

Шаги:

1. Откройте домашнюю страницу.
2. Введите комбинацию недопустимых значений в поле поиска.
3. Выполните поиск, кликнув значок поиска или нажав Enter.
4. Проверьте, отображается ли предупреждающее сообщение «Пожалуйста, используйте только допустимые символы».

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

Итоги: тестирование тест-кейса

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