Роль чек-листов в эффективном тестировании приложений

Что такое чек-лист и для чего он нужен?

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

Почему нельзя быть уверенным в качестве продукта, не имея чек-листа?

  • Можно бесконечно долго тестировать приложение, но так и не убедиться в том, что проверено действительно все. Чтобы этого не произошло, нужно придерживаться фиксированного набора тестов, охватывающих весь функционал.
  • Нельзя сделать вывод о степени готовности продукта к выпуску. Только на основе чек-листа можно увидеть в процентах, какая часть общего функционала работает корректно.
  • В силу ограниченности человеческой памяти и внимания без чек-листа практически невозможно сказать со 100% уверенностью, какие именно компоненты продукта уже проверялись, а какие все еще нуждаются в проверке.
  • Без фиксированного набора тестов нельзя оценить затраты времени, необходимые для проведения тестирования.

Чек-лист создается на основе Спецификации требований программного обеспечения. Определяя набор необходимых тестов, следует руководствоваться тремя основными правилами:

  1. Чек-лист должен охватывать весь функционал разрабатываемого продукта. Ни одно заявленное в спецификации требование не должно остаться без внимания.
  2. Число тестов нужно минимизировать. Чем больше требований проверяется одним тестом – тем лучше.
  3. Набор тестов должен не повторять требования, а проверять их.

Когда следует приступать к созданию чек-листа?

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

Как мы создаем и ведем чек-листы в Magora Systems?

  1. Когда готов документ с первичными спецификациями, к проекту подключают QA специалиста. Он знакомится с документом, вносит предложения, задаёт уточняющие вопросы.
  2. После утверждения спецификации клиентом, тестировщик приступает к определению набора тестов, необходимых для проверки разрабатываемого продукта. Существует несколько способов записи тестов. Наиболее удобная форма – таблица, содержащая 3 столбца: ID теста – Шаги теста – Ожидаемый результат.
  3. Запись результатов тестирования
  4. Кто-то использует для ведения чек-листов Excel, кто-то таблицы Google Drive (более удобный вариант, документ динамически обновляется, у всех участников проекта есть доступ к актуальной версии). Мы используем Sitechko – специальный инструмент для создания и ведения чек-листов. Он позволяет всем членам команды не только видеть актуальное состояние чек-листа в любой момент, но и генерировать разные типы отчетов о результатах прохождения чек-листа в разных конфигурациях.
  5. Чек-листы и результаты
  6. Как только разрабатываемый продукт передан на тестирование, специалист приступает к прохождению чек-листа последовательно во всех поддерживаемых конфигурациях. В результате экспертизы иногда возникает потребность в дополнении чек-листа тестами, тогда тестировщик расширяет его.
  7. Добавление тестов в чек-лист
  8. После выполнения всех тестов подготавливается баг-репорт и отчет о статусе продукта.
  9. Результаты тестирования
  10. После устранения/исправления обнаруженных в ходе тестирования проблем, специалист приступает к верификации и регрессионному тестированию, также фиксируя результаты в чек-листе.
  11. Пройденные чек-листы хранятся в сервисе Sitechko. В любой момент времени можно просмотреть историю, которая включает все итерации тестирования и  отчеты о результатах на каждом этапе.
Отчеты о тестировании