К чек-листам в компаниях относятся по-разному. Для одних важно красиво и правильно оформить, чтобы пользоваться таким документом долгое время. Для других чек-лист это набросок из последовательности тестов, составленный на скорую руку, чтобы не забыть, какие тесты надо провести, что-то вроде шпаргалки-напоминания. Обычно такой список очень краткий и представляет собой список идей тест-кейсов. Но бывает и другая ситуация, когда мы составляем вроде бы чек-лист, но при этом он делается максимально подробным, чтобы его можно было дать новичку.
Как же составить чек-лист правильно?
Существует ряд правил, которые нужно соблюдать:
- Чек-лист помогает достичь какой-то цели. Этой цели должна быть подчинена логика последовательности тестов. Список тестов не должен представлять собой хаотичный набор, он должен вести к цели проведения тестирования.
- Чек-лист должен быть структурированным, многоуровневым списком. Тесты должны быть сгруппированы, чтобы список легко читался.
- Чек-лист должен быть последовательным. Переходы между сгруппированными идеями должны быть логичны и понятны.
- Полнота описания идей должна дополняться краткостью, не должно быть избыточности, дублирования. Дублирование возможно из-за разных формулировок одной и той же идеи, поэтому нужно быть внимательными.
Несмотря на структурированность чек-листов и многоуровневую вложенность, трудно создать чек-лист, которым тестировали бы сразу все приложение. Поэтому создаются отдельные чек-листы для пользовательских сценариев, т.н. Happy Path, который был рассмотрен ранее, при составлении тест-кейсов по сценарию:
Для тестирования функциональности также создают отдельные сценарии, которые позже включают в автотесты. Перед тестированием каждой новой функции необходимо протестировать весь ранее написанный функционал, т.к. новая функция может случайно сделать этот функционал неработоспособным.
Отдельные чек-листы составляются также для дымового тестирования, с помощью которого проверяют запуск приложения и работу его основных модулей, и для расширенного тестирования, когда проверяется редко используемый функционал.
Отдельный чек-лист также может быть составлен для краш-тестов, когда проверяется поведение системы при отключении электричества и повторном запуске приложения, при замедлении скорости интернета, при недостаточном разрешении экрана для отображения основных элементов, и других смоделированных ситуациях.
Надеюсь, что все перечислила. Если что-то не учла, просьба дополнить в комментариях. Конечно, повторения теории недостаточно для совершенствования навыка составления чек-листов. Поэтому рассмотрим примеры составления чек-листов очень подробно в других публикациях.
