Использование чек-листов в тестировании: практическое руководство

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

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

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

Зачем нужны чек-листы в тестировании: 4 ключевые задачи QA

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

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

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

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

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

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

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

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

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

Чек-лист и тест-кейс: ключевые отличия, преимущества и недостатки

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

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

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

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

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

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

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

Недостатки:

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

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

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

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

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

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

Рассмотрим другие важные детали в чек-листе:

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

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

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

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

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

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

Заключение: чек-лист как основной инструмент QA-тестировщика

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