Автор: Клэр Рэклесс (Claire Reckless)

Оригинал статьи

Перевод: Ольга Алифанова

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

Очень раздражает, когда тратишь кучу времени на длинную подробную тест-документацию, которую в результате никто не читает и не использует. Проблема в том, что у менеджмента зачастую нет времени на чтение гигантских документов – менеджмент хочет знать только самое важное.

Джеймс Уиттакер писал о "Десятиминутном тест-плане" несколько лет назад, описывая задачу, которую он ставил перед своей командой. Цель задания состояла в том, чтобы добиться полезной тест-документации как  можно быстрее. Давайте посмотрим на это с другой точки зрения, но с похожей целью. В этот раз минимизируем не время, а масштаб. Как же сократить тест-план до одной странички?

А зачем вообще писать тест-план?

Фиксировать письменно можно любой документ, описывающий или передающий информацию – в этом случае это информация о том, как планируется тестировать программный продукт. Это можно сделать самыми разнообразными способами. Мы хотим, чтобы читатель нашего тест-плана узнал и (мы надеемся) понимал о проекте намного больше, и осознавал, как именно будет тестироваться фича/релиз – а также узнал о рисках и выяснил другие полезные ему сведения.

Тест-план можно также использовать в качестве "щита", защиты. Если что-то пошло не так – возможно, нужно вернуться к тест-плану и посмотреть, что упущено, что не покрыто, или о каких объемах тестирования изначально договаривались. В регулируемом окружении, или окружении с высокой степенью контроля план  может быть неотъемлемой частью цикла тестирования, законодательным требованием, или обязательной документацией проекта.

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

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

Манифест Agile гласит, что рабочий софт важнее полной документации. В результате перехода на Agile множество компаний понизили количество создаваемой в процессе разработки документации. Очень важно понимать, какую ценность дает вам тест-план. Иногда писать его необходимо, и зачастую это наименее сложный способ сообщить о прогрессе тестирования людям, не вовлеченным в разработку напрямую.

Почему одностраничный план может вам пригодиться?

Дайте очень занятому менеджеру огромный перенасыщенный информацией талмуд, на чтение которого требуется час или больше – и у него, возможно, никогда не найдется времени взглянуть на него. Предоставьте ему краткий документ с обзором планируемого тестирования – и он с куда большей вероятностью изучит его.

Что касается времени – написать одну страничку, возможно (это верно не всегда), будет быстрее, чем что-то более объемное. Это высвободит вам время на другую относящуюся к тестированию деятельность.

Ограниченный объем означает, что вы можете включать в тест-план информацию только до определенной степени. Вам придется решать, какая информация наиболее важна и ценна для читателя. Возможности перегружать план ненужными деталями, до которых никому нет дела, у вас не будет. Если обычно вы пишете более объемную тест-документацию и хотите попробовать себя в создании одностраничного плана – поговорите с теми, кто будет его читать, и узнайте, какая информация им необходима. Если список получился очень длинным, выберите две-три наиболее важных задачи, и добавьте еще, если остается место. Как вариант, попробуйте создать план в различных форматах – это может помочь вместить больше информации.

Важно также понимать, в каких случаях одностраничник не сработает для вашего проекта. Если по бизнес-причинам необходимо включить какую-либо информацию – сделайте это. Если план должен включать список всех планируемых тестов – попробуйте сэкономить место, ссылаясь на другие документы или приложения, используемые для управления тест-кейсами. Цель плана – подытожить задачи тестирования. Если заинтересованным лицам нужно больше информации, то линковка с другими документами внутри тест-плана может дать такую возможность, и плане не будет перегружен мусором.

Даже если уместить все на одну страницу совершенно невозможно, это может быть отличным способом взглянуть на ваши тест-планы свежим взглядом и спросить себя, можно ли сделать что-то иначе, дабы повысить их ценность.

Идеи для презентации вашего плана

Если вы ограничены по объему для представления всей нужной информации, креативно подойдите к вопросу, как именно она будет представлена. Тут можно следовать подходящему для ваших целей шаблону – просто убедитесь, что все его секции действительно нужны и релевантны для вашего проекта. Не тратьте время на описание чего-то только потому, что так сказано в шаблоне. Рассмотрите форматы, описанные ниже – возможно, они вам подойдут.

В классической книге "Agile Testing" (Лиза Криспин, Джанет Грегори) есть хороший образец одностраничного плана. Если вкратце, план включает информацию о том, что находится в рамках тестирования и за их пределами, ресурсах, фичах, производительности и нагрузке, UAT, инфраструктуре, предположениях и рисках. Вы можете менять или править эти блоки соответственно своему проекту. Каждая секция состоит из пары-тройки строк – верхнеуровневого описания того, что предстоит сделать.

Панель

Такое представление информации – неплохой способ быстро познакомить читателя с тест-планом визуально. Используйте цвета и стили, чтобы привлечь внимание читателя к каждой из описанных областей. Майк Токс (@TestSheepNZ) разработал свою собственную панель тест-плана для тестирования отдельных фич. Панель тестирования юзабилити – тоже неплохой вариант для старта.

Ментальные карты

Это еще один отличный визуальный способ создания тест-плана, и можно не ограничиваться страничкой А4. Начните с создания нод для каждой области вашего плана. Очень заманчиво, конечно, разбушеваться и создать много-много нод, но учтите, что это повлияет на читабельность вашего плана. Тут можно увидеть отличный пример из статьи Элизабет. Если вы создаете план со списком тестов, которые нужно провести – этот подход также может сработать. Карту также можно использовать как предварительный набросок текстового плана, чтобы проанализировать, из чего он будет состоять. Попробуйте XMind, Mindmup, MindMeister или Coggle.it в качестве инструментария.

Excel (или другой инструмент для таблиц)

Если у вас нет инструмента для управления тестированием, а в тест-план нужно включить список планируемых тестов или сценариев – можно использовать таблицы, а для отображения нужной информации – сводные таблицы.

Wiki-страничка

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

Доска

Считается ли этот метод "одностраничным"? Я думаю, да. Если ваш план будет использоваться только вашей командой – доски может быть достаточно, нет необходимости создавать формальный документ! Использование маркерной доски – один из простейших способов создания тест-плана. К тому же его можно будет быстро и дешево обновить. Сфотографируйте его, чтобы иметь к нему доступ, если вы не находитесь рядом с доской (или если есть риск, что его сотрут).

Доска Trello

Trello – отличный онлайн-инструмент управления проектами, позволяющий создавать доски со всеми планируемыми задачами, а также колонки для каждого статуса задачи. Для управления agile-проектами тоже можно использовать что-то похожее. Создайте доску для проекта или тестируемой фичи, и карточку для каждого элемента тест-плана. Можно также добавить даты завершения каждой задачи, а также подробности, ссылки на внешние источники и комментарии. Назначьте эти задачи кому следует, и двигайте их по доске по мере прогресса.

Как бы вы ни форматировали ваш план, думайте о том, что будет наиболее полезным вам, вашей команде и тем, для кого вы этот план создаете.

О чем нужно упомянуть

Включайте в ваш одностраничный план только наиболее важную для читателя информацию. Вот с чего можно начать:

• Продукт или тестируемая фича
• Что входит и не входит в рамки тестирования
• Риски
• Допущения
• Инструменты
• Окружения
• Ресурсы
• Оценки затрат

Решая, включать что-то в документ или не включать, спросите себя, нужно ли читателю это знать, важна ли эта информация? К тому же, как уже упоминалось выше, стоит спросить об этом читателя? Что он хочет узнать, прочитав ваш план? Не совершайте ошибок, включая что-то только потому, что "так вы делали всегда".

Если что-то не поместилось, подумайте, можно ли сослаться на внешний документ или ресурс, который даст недостающую информацию – например, на такие:

• Инструмент управления тестированием
• Тест-чартеры
• Дизайн-документация
• Перечень рисков
• Список допущений
• Гантт-графики с расписанием и ресурсами
• Ссылки на исследования и прототипы
• UAT-документация
• Документация по инфраструктуре
• Тест-планы для специфических видов тестирования – к примеру, производительности и безопасности.

Сделайте план легко читаемым

Изучите аудиторию вашего плана и то, как они будут его использовать – это поможет вам понять, что должно обязательно в него войти. Разные группы людей будут использовать план по-разному.

• Команда тестирования/тест-менеджер – они могут использовать его, как точку отсчета для создания тест-чартеров и окружений, а также для понимания, как распределять ресурсы.
• Бизнес – план может уйти в такие отделы, как, например, маркетинг, для планирования рекламных кампаний. Его может также использовать техподдержка или команда DevOps, готовясь к релизу.
• Топ-менеджмент – им, скорее всего, не требуются подробные перечни всех планируемых тестов. Обзор того, что предстоит сделать, информация о рисках и сроках тестирования поможет им понять, соответствуют ли планы разработки бизнес-планам на продукт.
• Контролирующие органы – им нужно убедиться, что тестирование соответствует определенным стандартам или законодательству.
• Заказчик или клиенты – возможно, вам необходимо передать им тест-план, потому что так указано в вашем договоре.

Общаясь с заказчиком или клиентами, обобщайте ваш план, и избавьтесь от технической терминологии, если они не очень хорошо в ней разбираются. Уделите внимание вопросам о тестировании, которые могут у них возникнуть. Возможно, необходимо указать контекст или контактную информацию, чтобы заказчик мог узнать больше или прояснить непонятное напрямую у автора.

Учтите, что у заказчиков и клиентов может и не быть доступа к вашей внутренней документации, и это ограничивает вашу способность линковать план к внешним ресурсам. Тут может потребоваться разрешение для доступа в режиме чтения, или ссылки на общедоступные документы.

Источники и ссылки:

Sources / References

• Software Testing Club - The Two Page Test Plan
  
• Developsense - What should a test plan contain
  
• Ministry of Testing - Planning Testing Mindmap
  
• Google Testing Blog - The 10 Minute Test Plan
  
• Usability Focus - Usability Test Plan Dashboard
  
• Agile Testing - Lisa Crispin and Janet Gregory
  
• Theory behind Mind Maps