Plan_testirovania_Trebovania_k_dokumentatsii

План тестирования

Тест-план — документ, описывающий и регламентирующий перечень работ по тестированию, а также соответствующие техники и подходы, стратегию, области ответственности, ресурсы, расписание и ключевые даты [1].

По сути, тест-план — это документ, который отвечает, как минимум, на следующие вопросы:

Что именно нужно тестировать? Т.е. тест-план должен однозначно определять объект тестирования.

Что будет тестироваться? Для ответа на этот вопрос тест-план должен содержать полный перечень функциональностей и характеристик объекта тестирования.

Как именно будет происходить тестирование? На него отвечает стратегия тестирования, описывающая типы и методы тестирования и то, как они будут применены к объекту тестирования.

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

Каковы критерии начала и окончания тестирования?

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

Если руководствоваться IEEE 829 — отраслевым стандартом для документации тестирования программ и систем, структура тест-плана будет включать в себя следующие разделы:

Идентификатор тест плана. В этом разделе указываются название и логотип компании, проводящей тестирование, название документа, его версию и год создания. Это титульная страница тест-плана.

Ссылки. Этот раздел содержит таблицу изменений со следующими столбцами: дата, версия, описание, автор. С её помощью становится возможным фиксировать и отслеживать как в самом документе, так и в процессе, который он описывает.

Введение. Содержит предельно краткое описание цели разработки приложения. Информация здесь подаётся в сжатом виде и в контексте того, на что следует обращать первостепенное внимание при организации тестирования и повышения качества.

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

объектов будет описан отдельно. Список может быть расширен или сокращен в зависимости от задач или типа тестирования.

Области, подвергаемые тестированию. Перечень функций и/или не-

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

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

— такой подход позволяет исключить появление ложных ожиданий и неприятных сюрпризов.

Подходы. Описание процесса тестирования с точки зрения применяемых методов, подходов, видов тестирования, технологий, инструментальных средств и т. д. Для данного раздела так же применим термин

тестовая стратегия.

Критерии. Этот раздел включает следующие подразделы:

oПриёмочные критерии, критерии качества — любые объектив-

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

теля, чтобы считаться готовым к эксплуатации.

oКритерии начала тестирования — перечень условий, при вы-

полнении которых команда приступает к тестированию. Наличие этого критерия страхует команду от бессмысленной траты уси-

лий в условиях, когда тестирование не принесёт ожидаемой пользы.

oКритерии приостановки тестирования — перечень условий,

при выполнении которых тестирование приостанавливается. Наличие этого критерия также страхует команду от бессмыслен-

ной траты усилий в условиях, когда тестирование не принесёт ожидаемой пользы.

oКритерии возобновления тестирования — перечень условий,

при выполнении которых тестирование возобновляется (как пра-

вило, после приостановки).

oКритерии завершения тестирования — перечень условий, при выполнении которых тестирование завершается. Наличие этого

критерия страхует команду как от преждевременного прекращения тестирования, так и от продолжения тестирования в условиях, когда оно уже перестаёт приносить ощутимый эффект.

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

o программные ресурсы: какое ПО необходимо команде тестировщиков, сколько копий и с какими лицензиями (если речь идёт о коммерческом ПО);

o аппаратные ресурсы: какое аппаратное обеспечение, в каком количестве и к какому моменту необходимо команде тестировщиков;

o человеческие ресурсы: сколько специалистов какого уровня и со знаниями в каких областях должно подключиться к команде тестировщиков в тот или иной момент времени;

o временные ресурсы: сколько по времени займёт выполнение тех или иных работ;

o финансовые ресурсы: в какую сумму обойдётся использование имеющихся или получение недостающих ресурсов, перечисленных в предыдущих пунктах этого списка.

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

Расписание. Фактически это календарь, в котором указано, что и к какому моменту должно быть сделано. Особое внимание уделяется т.н. «ключевым точкам», к моменту наступления которых должен быть получен некий значимый ощутимый результат.

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

Роли и ответственность. Перечень необходимых ролей (например, «ведущий тестировщик», «эксперт по оптимизации производительности») и область ответственности специалистов, выполняющих эти роли.

Требования к документации

Рассмотрим некоторые общепринятые свойства, которыми обладает хорошая документация:

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

Актуальность. Любая документация должна содержать описание именно той функциональности, которая присутствует в приложении.

Структурированность документации. Все документы должны нахо-

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

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

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

oПоследовательность изложения. В некоторых сценариях важна последовательность выполнения действий.

oУказание на необратимость действий. Если какое-то действие в инструкции влечёт за собой необратимые последствия для пользователя, то об этом стоит указать.

oПодтверждение ожидаемого. После описания последовательности некоторых действий стоит указать ожидаемый результат.

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

oНаличие описания настроек по умолчанию. Если есть какие-либо настройки, и в них есть значения по умолчанию, то было бы хорошо, чтоб это было описано.

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

Доступность пользователю. Документация должна быть максимально понятной для любой целевой аудитории.

Орфография, синтаксис, пунктуация.

Список источников

1.International Software Testing Qualifications Board Glossary [Электронный ресурс]: – Режим доступа: http://www.istqb.org/downloads/glossary.html

2.Тестирование программного обеспечения. Базовый курс / С. С. Куликов. — Минск: Четыре четверти, 2017. — 312 с.

3.IEEE 829-2008 Standard for Software Test Documentation