Итак, деловой список. Чек-лист тестировщика

Деловой гость блога из деловой социальной сети

Уже два раза гости рубрики «Итак, деловой список» находились в Telegram. На этот раз всё будет немного иначе. Некоторые из вас могли слышать, что компания HeadHunter развивает с начала этого года новую социальную сеть для профессионального общения — «Сетку».

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

Речь сегодня пойдёт о канале «Тестируй, душни, наслаждайся | QA TSP», а точнее об одном интересном посте из него. Создатель канала Александр Олейников — один из наиболее активных авторов «Сетки». Как можно понять из названия его сообщества, оно посвящено тестированию в разработке программного обеспечения. А автор этого блога имеет к разработке ПО прямое отношение.

Недавно в канале Александра появился пост, посвящённый чек-листам (просмотр на момент публикации поста доступен только пользователям социальной сети). С первых букв поста стало понятно, что нашёлся материал для совместной статьи.

QA в IT — это целый мир

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

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

Наблюдения о терминологии

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

С другой стороны в некоторых материалах содержится информация настолько противоречащая материалам блога, что хочется сказать отдельно. Вот пример [1]:

Чек-лист (checklist *) — набор идей [тест-кейсов]. Последнее слово не зря взято в скобки, т.к. в общем случае чек-лист — это просто набор идей: идей по тестированию, идей по разработке, идей по планированию и управлению — любых идей.

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

С таким определением в этом блоге совершенно не согласны. Чек-лист — это чек-лист, а список — это список. Список дел — это так вообще что-то среднее между предыдущими двумя.

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

Александр использует в своём посте следующее определение:

Чек-лист (checklist или check-list) — это список проверок, которые помогают специалисту протестировать приложение или отдельные функции.

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

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

Основная цель чек-листа состоит в том, чтобы вы не забыли проверить всё, что планировали.

Немного про тест-кейсы (тестовые сценарии)

Чек-листы в QA часто взаимодействуют с тем, что называется «тест-кейс». Международная комиссия по аттестации специалистов в области тестирования программного обеспечения определяет тест-кейс или тестовый сценарий следующим образом [2]:

Набор предусловий, входных данных, действий (где применимо), ожидаемых результатов и постусловий, разработанных на основе тестовых условий.

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

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

Два типа чек-листов тестировщика

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

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

Чек-листы как план тестирования

В своём классическом виде такие чек-листы представляют таблицу из трёх столбцов:

1. Заголовки тест-кейсов, структурированные по разделам/функционалу, или любые определенные составителем пункты;
2. Отметка pass/fail (успех/провал);
3. Заметка, если требуются.

Вот как может выглядеть эта таблица:

В примере выше в первом столбце «СТ01» — это идентификатор тест-кейса. То есть такая строка, по которой можно быстро его обнаружить в других местах и получить дополнительную информацию о нём. «Открытие страницы товара» — это название. Оно позволяет быстро понять, о чём речь в конкретном тест-кейсе. Значок ✅ или ❌ показывает, успешно ли тестировщик прогнал тест. «Заметка» говорит сама за себя. Если что-то важное замечено в ходе проверки, это можно записать на будущее.

Кстати, статус необязательно должен быть либо ✅ или ❌. Если требуется, то можно и расширить этот привычно двоичный элемент контроля в списке.

Вот как может расшириться знакомая коробочка для галочки:

• Ещё не проверялось.
• Успех (✅).
• Провал (❌).
• Пропущено.
• Заблокировано.

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

Статус «Заблокировано» удобно использовать, чтобы показать невозможность выполнить определённые пункты. Например, не сработало «СТ01: Открытие страницы товара». Остальные шаги проверить не получится, все они зависят от первого.

Чек-лист как облегчённый тест-кейс

В одном из своих форматов сценарий тестирования содержит следующую информацию [3]:

1. Идентификатор набора тестов,
2. Идентификатор тестового кейса,
3. Заголовок кейса,
4. Связанное требование,
5. Предварительные условия,
6. Шаги выполнения,
7. Тестовые данные,
8. Ожидаемый результат,
9. Статус пройден или не пройден,
10. Заметки,
11. Создано,
12. Дата создания,
13. Выполнено,
14. Дата выполнения,
15. Тестовое окружение.

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

Сценарий тестирования, который выше обозначен как «СТ04: Добавление товара в корзину» может описываться следующим чек-листом:

☐ Открыть страницу товара.
☐ Нажать на кнопку «Добавить в корзину».
☐ Ожидать увеличения количества товаров в корзине на 1.

Такие чек-листы — это хорошая основа для развития автоматизированного тестирования. Например, на языке Gherkin фреймворка Cucumber этот контрольный список может выглядеть так:

Сценарий: Увеличение счётчика корзины при добавлении товара
  Когда Пользователь заходит на Страницу товара
  И Пользователь нажимает на кнопку «Добавить в корзину»
  Тогда Счётчик товаров в корзине увеличивается на 1

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

Как ещё применяются чек-листы в QA

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

Помимо тестирования функциональности, Александр приводит примеры ещё нескольких применений:

1. Проверка критериев начала и окончания тестирования.
2. Проведение проверок готовности каждого предстоящего этапа, правильности завершения каждого проведённого.
3. Основа для проведения исследовательского тестирования.
4. Документирование прочих процессов для распространения знаний в команде.

Заключение

Чек-лист — это хорошее подспорье тестировщика. Он помогает тестировать отдельные функции приложения. А достаточно большим набором чек-листов можно попытаться основательно покрыть не слишком большое приложение.

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

Спасибо Александру Олейникову за этот совместный материал. Если и вы хотите поблагодарить его, подписывайтесь на сообщество «Тестируй, душни, наслаждайся | QA TSP» в «Сетке».

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

Список ссылок

[1] Святослав Куликов, «Тестирование программного обеспечения базовый курс 3-е издание»
[2] «Тестовый сценарий» с сайта ISTQB Glossary
[3] «Тест-кейс (Test case)» с сайта QA_Bible