Чек-лист – это список, содержащий ряд необходимых проверок во время тестирования программного продукта. Отмечая пункты списка, команда или один тестировщик могут узнать о текущем состоянии выполненной работы и о качестве продукта. Работая над проектом по чек-листу, исключена вероятность повторной проверки по тем же кейсам, а также повышается качество тестирования, так как вероятность оставить без внимания какой-то функционал существенно снижается. Поэтому очень важно знать из каких элементов состоит чек-лист и уметь им эффективно пользоваться. Как правило, чек-листы делают в Google-таблице для обеспечения общего доступа всем QA-специалистам.
Чек-листы устроены предельно просто. Любой из них содержит перечень блоков, секций, страниц, других элементов, которые следует протестировать, например:
Пункты могут содержать как линейную структуру, так и древовидную, с разделами/подразделами или без них. Они должны быть максимально краткие и в то же время понятные тестировщику, который еще не знаком с приложением. Пункты должны быть однозначными, чтобы их нельзя было понять как-то иначе. Все пункты должны быть оформлены на одном языке: русском или английском.
Как правило, каждый чек-лист имеет несколько столбцов. Каждый столбец предназначен для тестирования на отдельной платформе. Следует всегда указывать название устройства, браузера и его версии.
Тестировать приложение может несколько человек одновременно. В этом случае каждый тестировщик берет по одной-две платформы и тестирует только на них. При этом следует напротив каждой платформы указать тестировщика, который выполняет указанный объем работ.
При прохождении чек-листов тестировщик отмечает статус напротив каждого тестируемого пункта. Возможны следующие варианты статусов:
- «Passed» – проверка пройдена успешно, багов не найдено;
- «Failed» – найден один или более багов;
- «Blocked» – невозможно проверить, т.к. один из багов блокирует текущую проверку;
- «In Progress» – текущий пункт, над которым работает тестировщик;
- «Not run» – еще не проверено;
- «Skipped» – проверяться не будет по какой-либо причине. Например, текущий функционал еще не реализован.
Для большей наглядности, как правило, каждый из статусов имеет свой цвет.
После завершения тестирования не должно быть ячеек, отмеченных как «Not run».
Все заведенные по чек-листу баг-репорты должны быть добавлены в примечания к ячейке со статусом «Failed».
Вполне допустимо добавлять примечания и в некоторые ячейки с другими статусами, если это необходимо.
Для ячеек со статусом «Blocked» примечания со ссылками на баг-репорты также обязательны. Однако, как правило, примечание в ячейке со статусом «Blocked» ссылается на ранее заведенный баг-репорт, который в одном из предыдущих пунктов уже отмечен как «Failed». Другими словами: пункт, однажды отмеченный как «Failed» может быть блокером для нескольких или всех последующих пунктов чек-листа. Рассмотрим пример:
Здесь видно, что есть два различных бага. Допустим, первый баг в браузере Chrome – функционал не работает. В этом случае мы заводим баг-репорт и отмечаем текущий пункт как «Failed». Все остальные пункты будут отмечены как «Blocked», т.к. их невозможно будет протестировать.
Примерно то же самое и с браузером Firefox. Письмо невозможно отправить, на это заводится баг-репорт, а все остальные пункты, связанные с отправкой, проверить невозможно, поэтому отмечаем их как «Blocked», указывая ссылку на тот же баг-репорт.
Отметим несколько основных моментов, которые стоит учитывать при работе с чек-листами:
- По завершении прохождения чек-листа не должно остаться ячеек со статусом «Not run».
- Все ячейки со статусом «Failed» и «Blocked» обязательно должны иметь примечания со ссылками на баг-репорты.
- Статус «Passed» устанавливается только для пунктов, которые проверены и не содержат ошибок.
Рекомендации для составления эффективного чек-листа.
- Один пункт – одна операция.
Пункты чек-листа – это однозначные атомарные и полные операции. Например, добавление товара в корзину сайта и оплата заказа – две разные задачи. В списке проверок подобные операции оформлены отдельными пунктами: добавлен товар в корзину, оплата отправлена. - Пункты начинаются с существительного.
Цель чек-листа – учесть все действия для наиболее полного покрытия тестами ПО, поэтому составляя пункты следует придерживаться унифицированной формы. Для понятного и однозначного представления пункты лучше начинать с существительного – «Проверка», «Добавление», «Отправка» или глагола неопределенной формы – «Проверить», «Добавить», «Отправить». - Составление чек-листа по уровням детализации.
Для удобства прохождения чек-листа лучше всего составлять тесты в том виде, который будет последовательным исходя из логики использования функционала. В рамках раздела «Регистрация и Личный профиль»: регистрация на сайте, редактирование профиля. Раздел «Форма обратной связи»: валидация полей, отправка письма, доставка письма.
- Использование чек-листов способствует структурированию информации у сотрудника.
- При правильной записи необходимых действий у сотрудника появляется однозначное понимание задач. Это способствует повышению скорости обучения новых сотрудников.
- Чек-листы помогают избежать неопределенности и ошибок связанных с человеческим фактором. Увеличивается покрытие тестами программного продукта.
- Повышается степень взаимозаменяемости сотрудников.
- Экономия рабочего времени. Написав чек-лист единожды его можно использовать повторно, учитывая актуальность информации.
Использование чек-листов – один из приёмов повышения бас фактора. В области разработки программного обеспечения бас фактор («bus factor» – фактор автобуса) проекта – это мера сосредоточения информации среди отдельных членов проекта.
Хороший чек-лист – это документ, описывающий что должно быть протестировано. При этом чек-лист может быть абсолютно разного уровня детализации. Насколько детальным будет чек-лист зависит от требований к отчётности, уровня знания продукта сотрудниками и сложности продукта.
Чек-лист нужен чтобы:
- Не забыть требуемые тесты.
- Делить задачи по уровню квалификации.
- Сохранять отчетности и результаты тестирования.
Чек-лист содержит:
- Список проверок (с требуемой степенью детализации).
- Окружение проверки:
- сборка, на которой проводилось тестирование;
- тестовое окружение (если применимо);
- информация о тестировщике.
- Результат проверки.