Итак, деловой список тестировщика: чек-лист в тестировании

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

Уже два раза поиск в 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