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

Что такое чек-лист в тестировании?

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

Для чего нужны чек-листы?

1. Подготовка к тестированию функционала до его реализации.

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

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

2. Сведение к минимуму пропущенных проверок.

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

3. Для отчётности. 

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

4. Для регрессионного тестирования.

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

Какие преимущества и недостатки у чек-листов по сравнению с тест-кейсами?

Преимущества:

- Быстрота составления.

Чек-листы гораздо проще и быстрее составить, чем тест-кейсы. Например, если в чек-листе элемент проверки формулируется как "Авторизация с помощью Google", то в тест-кейсе он будет описан более подробно: "1. Открыть главную страницу, 2. Нажать кнопку 'Войти', 3. Выбрать вход через Google" и так далее. Благодаря более обобщенной форме записи, чек-листы позволяют быстрее приступить к тестированию функционала и переходить к следующим задачам.

- Легче поддерживать.

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

- Гибкость в использовании на различных платформах.

Чек-листы удобно составляются и выполняются в таких инструментах, как Google Sheets, которые предоставляются бесплатно и обладают удобными функциями настройки доступа, работы с формулами и так далее. Тест-кейсы конечно тоже можно писать и проходить в таблицах, но это очень не удобно. Для удобного написания и прохождения тест-кейсов нужны специальные Test Case Management (TCM) приложения, по типу TestRail. И они обычно не бесплатные.

Недостатки:

- Сложность использования для новых сотрудников.

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

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

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

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

В данной статье мы не будем рассматривать техники тест-дизайна, так как готовим отдельную статью на эту тему. Подпишитесь на нашу группу https://vk.com/sunstrikeqa чтобы не пропустить её. А пока обратим внимание на другие детали в чек-листе, а именно:

- Глубина покрытия.

Вот пример чек листа не глубокого уровня покрытия на проверку функционала "Прикрепление файла к сообщению":

С таким чек-листом у тестировщика сразу возникает множество тестовых сценариев, которые также требуют проверки. Давайте распишем их в примере с более глубоким уровнем покрытия:

Когда мы тестируем фичу в первый раз, мы используем глубокое (оно же полное) покрытие. А, например, для регрессионного тестирования подойдёт средняя или минимальная глубина покрытия.

- Дополнительные поля.

Удобно, когда напротив каждой проверки есть поле “Статус”. Чаще всего мы используем следующие статусы: Not Tested, Passed, Failed, Skipped. Поле “Комментарий” тоже достаточно полезное, например можно сразу прикрепить ссылку на баг или написать почему пропущен пункт.

Заключение

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