Тестирование

игр и приложений

Тестирование

игр и приложений

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

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

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


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


Чек-лист (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. Поле “Комментарий” тоже достаточно полезное, например можно сразу прикрепить ссылку на баг или написать почему пропущен пункт.


Заключение


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

Kallipoleos 3, office 102, 1055 Nicosia, Cyprus
Sun Strike Gaming Ltd.

© «SunStrike Studios» 2016-2024 

Kallipoleos 3, office 102, 1055 Nicosia, Cyprus
Sun Strike Gaming Ltd.

«SunStrike Studios» © 2016-2024

Kallipoleos 3, office 102, 1055 Nicosia, Cyprus
Sun Strike Gaming Ltd.

© «SunStrike Studios» 2016-2024