Всем привет! Меня зовут Елена Поплоухина. Я — один из авторов Youtube‑канала по тестированию «Багаж тестировщика». На канале выходило несколько выпусков с примерами проектирования чек-листов. В этой статье я хочу дать несколько практических рекомендаций по формулированию проверок в чек-листах.

Введение

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

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

Я выработала определенный подход к описанию проверок в чек-листе и хочу поделиться им на простом примере. Цель данной статьи - познакомить вас с правилами создания структуры чек-листа и основными способами описания проверок в чек-листе.

О чем поговорим

Где создавать чек‑листы?
Что такое проверка?
Пример чек-листа
Структура чек-листа
Приоритеты проверок
Способы описания проверок
- Что проверяем?
- Какое действие проверяем?
- Какие тестовые данные?
- Более сложные формулировки
- Перечисление проверяемых свойств объекта
Описание ожидаемого результата
Заключение

Где создавать чек-листы

Примером тест-менеджмент системы с поддержкой чек-листов является “Ситечко”. Также для создания чек-листов можно использовать любой табличный редактор, например, Google.Таблицы.

Что такое проверка?

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

А что же такое - проверка в чек-листе? Предлагаю следующее определение термина:

Проверка - это описание тест-кейса или его отдельного шага с низкой детализацией.

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

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

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

Примеры не связанных друг с другом проверок:
- Добавить товар в корзину
- Удаление события из календаря
- Построить маршрут на карте при медленном интернет-соединении
- Пользователю установлен 2 уровень привилегий. Отображение условий кэшбэка.
- Пустые обязательные поля при редактировании профиля.
- Начать ввод номера с цифры 8
и т.д.

Далее разберем способы описания проверок на примере готового чек-листа.

Пример чек-листа

Представим, что мы тестируем образовательную онлайн-платформу. На странице курса есть блок со списком отзывов.

Требования к отображению одного отзыва в списке звучат следующим образом:

Макет блока со списком отзывов выглядит так:

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

Примечание. В задачи данной статьи не входит продемонстрировать полный исчерпывающий тест-дизайн по требованиям.

Структура чек-листа

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

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

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

Все проверки объединяются в группы - аналогично тому, как тест-кейсы объединяются в тестовые наборы. Для функциональности работы со списком отзывов можно выделить 3 основных группы:
- Список отзывов
- Отображение одного отзыва в списке
- Сортировка отзывов

Можно группировать проверки и в более мелкие логические группы.

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

Рассмотрим, как определить приоритет для проверок.

Приоритеты проверок

При установке приоритета проверкам можно ориентироваться на следующие правила. 

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

• Средний.
  Подавляющая часть проверок. Проверяется важная часть логики работы приложения.

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

Способы описания проверок

Я предлагаю 3 основных способа для описания проверок. В каждом из них мы отвечаем на соответствующий вопрос:

• Что проверяем?

• Какое действие проверяем?

• Какие тестовые данные у тестируемого объекта?

Разберем подробнее каждый из способов.

Что проверяем?

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

Задаем себе вопрос:
- Что мы проверяем?
Ответ коротко можно сформулировать как:
- Отображение отзыва в списке.

Это и есть наша проверка.

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

В ожидаемом результате перечисляем отображаемые поля. 

Еще один пример проверки, сформулированной таким же образом:

Рассмотрим дополнительно несколько не связанных друг с другом примеров проверок с формулировкой “Что проверяем?”:
- Создание нового бронирования путевки
- Фильтрация списка товаров по категории
- Поиск товара по наименованию
- Просмотр новости
- Воспроизведение трека в плейлисте
и т.д.

Какое действие проверяем?

Фактически, это та же самая формулировка “Что проверяем”, описанная при помощи глагола. Выбирайте, какой из способов удобнее.

Посмотрим еще раз на требования для отображения длинного отзыва в списке:

Предположим, мы хотим проверить работу кнопок “Читать далее” и “Свернуть”.
Для того, чтобы описать проверки, задаем себе вопрос:
- Какое действие пользователя мы проверяем?
Ответ коротко можно сформулировать как:
- Развернуть отзыв при помощи кнопки "Читать далее".
- Свернуть отзыв при помощи кнопки "Свернуть"

Получаем 2 проверки.

Рассмотрим дополнительно несколько не связанных друг с другом примеров проверок с формулировкой “Какое действие проверяем?”:
- Создать новое бронирование путевки
- Отфильтровать список товаров по категории
- Найти товар по наименованию
- Посмотреть новость из списка
- Воспроизвести трек в плейлисте
и т.д.

Какие тестовые данные?

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

Посмотрим еще раз на требования для отображения длинного отзыва в списке:

Предположим, мы хотим проверить логику отображения кнопки “Читать далее” в зависимости от длины отзыва.
Для того, чтобы описать проверки, задаем себе вопрос:
- Какие тестовые данные? Если подробнее -  Отзывы какой длины и на каком языке мы должны отобрать для проверки логики отображения кнопки?
Ответ можно сформулировать как:
- Длина отзыва 299 символов на русском языке.
- Длина отзыва 300 символов на русском языке.
- Длина отзыва 301 символов на русском языке.

Получаем 3 проверки.

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

Более сложные формулировки

Некоторые ситуации нельзя описать при помощи трех простых формулировок. Поэтому можно использовать более сложные, которые являются комбинацией ответов на вопросы:
- Что проверяем?
- Какое действие проверяем?
- С какими тестовыми данными?

Рассмотрим несколько примеров.

Часть требований к отображению списка отзывов для курса звучит так:

Например, мы хотим проверить, что если для курса добавлено более 10 отзывов, в списке отображается только первые 10 отзывов и кнопка “Больше отзывов".

Вопрос: Что проверяем?
- Отображение отзывов о курсе.
Вопрос: С какими тестовыми данными?
- Для курса добавлено 11 отзывов.

Эту проверку можно сформулировать 2 способами
- Отображение отзывов о курсе, когда для курса добавлено 11 отзывов
- Для курса добавлено 11 отзывов. Отображение отзывов о курсе при загрузке страницы.

Другой пример. Мы хотим проверить работу кнопки “Больше отзывов”. Если нажать на нее, отобразятся следующие 10 отзывов.

Вопрос: Какое действие проверяем?
- Нажать на кнопку подгрузки отзывов..
Вопрос: С какими тестовыми данными?
- Для курса добавлено 20 отзывов. 

Получаем формулировку:
- Для курса добавлено 20 отзывов. Нажать на кнопку подгрузки отзывов.

Примечание. При формулировках в первую очередь обращайте внимание на простоту и легкость понимания.

Перечисление проверяемых свойств объекта

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

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

В качестве примера возьмем отображение в отзыве аватара пользователя. Будет ли проверена ситуация, когда аватар не установлен у пользователя ? Неясно. Также необязательно в каждой проверке писать само слово “Проверить” - оно избыточно.

Когда такой подход может применяться?

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

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

А после этой группы будет идти другая группа, со следующими проверками полей:

Еще один пример. Вместо проверки:

Получаем группу проверок

Описание ожидаемого результата проверок

Ниже приводятся общие рекомендации по описанию ожидаемого результата для всех типов проверок.

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

Указание, где искать ожидаемый результат.
Например, указать короткую формулировку “В соответствии с макетом”. 

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

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

Заключение

Мы рассмотрели основные способы формулирования проверок в чек-листе. Тренируйтесь и находите наиболее удобный для вас подход.