Чек-лист (Check List)

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

  • 1-й столбец: заголовки тест-кейсов, структурированные по разделам/функционалу, или любые определенные составителем пункты;

  • 2-й столбец для отметки: pass/fail;

  • 3-й столбец опционально под заметки.

Если чек-лист используется еще и для наглядного отображения хода тестирования (а-ля test run), 2-й столбец может иметь опции: пусто (еще не проверялось)/успех/ошибка/пропущено или заблокировано (например, другим дефектом).

Примеры простых чек-листов из обычной жизни:

  • Список проверок при покупке б/у ноутбука;

  • Список вещей/дел во время сборов в путешествие;

  • Список покупок в магазине.

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

Разница между тест-кейсом и чек-листом

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

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

Доп. материал:

Last updated