Пиши, сокращай: как создавать сильные чек-листы

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

Введение

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

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

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

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

Пример

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

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

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

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

Формируем структуру чек-листа

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

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

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

• Приоритет -  с градацией из трех уровней: высокий, средний, низкий.

• Проверка - описание самой проверки.

• Ожидаемый результат - поле опционально для заполнения.

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

• Список отзывов

• Отображение одного отзыва в списке

• Сортировка отзывов

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

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

Структура готова.

Разберем общие правила описания проверок. И посмотрим их применение на простом примере.

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

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

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

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

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

• не описываем предусловия, если они хорошо известны;

• можем не указывать тестовые данные, чтобы разнообразить выполнение проверок; 

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

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

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

Примеры не связанных друг с другом формулировок проверок:

• Добавить товар в корзину.

• Удаление события из календаря.

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

• Пользователю установлен 2 уровень привилегий. Отображение условий кэшбэка.

• Пустые обязательные поля при редактировании профиля.

• Начать ввод номера с цифры 8.

• и т.д.

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

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

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

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

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

Формулировки проверок

Можно выделить 3 простых способа описания проверок при помощи вопросов:

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

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

• С какими тестовыми данными?

Разберем эти типы формулировок на примере создания чек-листа для следующих требований из примера:

При проектировании проверок выполняем 3 основных шага:

1. Выбираем проверяемую сущность/блок. Она должна быть небольшой и атомарной. Например, не весь блок отзывов, а только список отзывов. Или только сортировка. Или только отдельный отзыв. Или какое-то поле отзыва.

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

3. Придумываем тестовые данные для проверяемого объекта.

Проверка вида - Что проверяем?

Формулировка проверки отвечает на вопрос “Что проверяем?”

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

• Создание нового бронирования путевки.

• Фильтрация списка товаров по категории.

• Поиск товара по наименованию.

• Просмотр новости.

• Воспроизведение трека в плейлисте.

• и т.д.

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

Описание такой проверки отвечает на вопрос “Что проверяем?”. Проверку можно коротко сформулировать как “Отображение отзыва в списке”.

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

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

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

Формулировка проверки отвечает на вопрос “Какое действие проверяем?”

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

Несколько не связанных друг с другом примеров:

• Создать новое бронирование путевки.

• Отфильтровать список товаров по категории.

• Найти товар по наименованию.

• Посмотреть новость из списка.

• Воспроизвести трек в плейлисте.

• и т.д.

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

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

Проверка вида - Описание тестовых данных/предусловий

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

Вернемся к примеру.

Проверки для отображения кнопки "Читать далее" в зависимости от длины отзыва можно описать следующим образом:

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

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

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

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

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

• С какими тестовыми данными?

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

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

Что проверяем + Описание тестовых данных/предусловий.

Описание тестовых данных/предусловий + Какое действие проверяем?

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

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

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

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

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

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

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

Стоит ли в проверках просто перечислять проверяемые свойства объекта?

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

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

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

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

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

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

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

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

Заключение

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