Разработка тест - плана

Тест-план

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

К низкоуровневым задачам планирования в тестировании относятся:

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

Чтобы тест – план был качественным необходимо, чтобы он обладал следующими свойствами:

• Реалистичность (запланированный подход реально выполним).
• Гибкость (качественный тест-план не только является модифицируемым с точки зрения работы с документом, но и построен таким образом, чтобы при

возникновении непредвиденных обстоятельств допускать быстрое изменение любой из своих частей без нарушения взаимосвязи с другими частями).

• Согласованность с общим проектным планом и иными отдельными планами (например, планом разработки).

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

В общем случае тест-план включает следующие разделы

• Цель . Краткое описание цели разработки приложения (частично это напоминает бизнес - требования, но здесь информация даётся в ещё более сжатом виде и в контексте того, на что следует обращать первостепенное внимание при организации тестирования и повышения качества).
• Области, подвергаемые тестированию. Перечень

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

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

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

• Тестовая стратегия и подходы. Описание процесса тестирования с точки зрения применяемых методов, подходов, видов тестирования, технологий, инструментальных средств и т.д.
• Критерии. Этот раздел включает следующие подразделы:

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

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

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

4. Критерии возобновления тестирования — перечень условий, при выполнении которых тестирование возобновляется после приостановки.

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

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

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

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

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

• Документация . Перечень используемой тестовой документации с указанием, кто и когда должен её готовить и кому передавать.
• Метрики . Числовые характеристики показателей качества, способы их оценки, формулы и т.д. На этот раздел, как правило, формируется множество ссылок из других разделов тест-плана.

Метрики могут быть как прямыми (не требуют вычислений), так и расчётными (вычисляются по формуле). Типичные примеры прямых метрик — количество разработанных тест-кейсов, количество найденных дефектов и т.д. В расчётных метриках могут использоваться формулы.

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

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

При формировании отчётности важное значение имеют не только текущее значение метрики, но и её динамика во времени.

Некоторые метрики могут вычисляться на основе данных о расписании, например метрика «сдвига расписания»:

Ss=(DDline/ ND) – 1, где

Ss - значение сдвига расписания,

DDline – количество дней до запланированного

завершения работы,

ND – количество дней, необходимое для завершения

работы.

Значение сдвига расписания не должно быть

отрицательным числом

Важными метриками является метрики покрытия.

Покрытие — процентное выражение степени, в которой

исследуемый элемент затронут соответствующим

набором тест-кейсов . К метрикам покрытия относят

• Метрика покрытия требований (требование считается «покрытым», если на него ссылается хотя бы один тест-кейс):

Rck = Rc/Rt *100% , где

Rck – метрика покрытия требований,

Rc – количество требований, покрытых хотя бы одним тест-кейсом,

Rt - общее количество требований.

• Метрика плотности покрытия требований (учитывается, сколько тест-кейсов ссылается на несколько требований):

RDk = (T1+T2+…+Tn)/(Tt*Rt) *100% , где

RDk – плотность покрытия требований,

T1+T2+…+Tn – количество тест-кейсов, покрывающих 1,

2, …, n требование,

Tt – общее количество тест-кейсов ,

Rt - общее количество требований.

• Метрика покрытия классов эквивалентности (анализируется, сколько классов эквивалентности затронуто тест-кейсами).

• Метрики покрытия кода модульными тест-кейсами .

Пример тест - плана для приложения «Конвертер файлов»

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

Цель

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

Области, подвергаемые тестированию

(См. соответствующие разделы требований.)

• ПТ-1.*: дымовой тест.
• ПТ-2.*: дымовой тест, тест критического пути.
• ПТ-3.*: тест критического пути.
• БП-1.*: дымовой тест, тест критического пути.
• АК-2.*: дымовой тест, тест критического пути.
• О-4: дымовой тест.
• О-5: дымовой тест.
• ДС-*: дымовой тест, тест критического пути.

Области, не подвергаемые тестированию

• СХ-1: приложение разрабатывается как консольное.
• СХ-2, О-1, О-2: приложение разрабатывается на PHP указанной версии.
• АК-1.1: заявленная характеристика находится вблизи нижней границы производительности операций, характерных для разрабатываемого приложения.
• О-3: не требует реализации.
• О-6: не требует реализации.

Тестовая стратегия и подходы

Общий подход

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

Уровни функционального тестирования:

• Дымовой тест: автоматизированный с использованием командных файлов ОС Windows и Linux.
• Тест критического пути: выполняется вручную.
• Расширенный тест не производится, т.к. для данного приложения вероят-ность обнаружения дефектов на этом уровне пренебрежимо мала.

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

методу белого ящика. Автоматизация тестирования кода не будет применяться в силу крайне ограниченного времени.

Критерии

• Приёмочные критерии: успешное прохождение 100 % тест-кейсов уровня дымового тестирования и 90 % тест-кейсов уровня критического пути при условии устранения 100 %дефектов критической и высокой важности Итоговое покрытие требований тест-кейсами (см. метрику «Покрытие требований тест-кейсами») должно составлять не менее 80 %.
• Критерии начала тестирования: выход билда.
• Критерии приостановки тестирования: переход к тесту критического пути допустим только при успешном прохождении 100 % тест-кейсов дымового теста

(см. метрику «Успешное прохождение тест-кейсов»); тестирование может быть приостановлено в случае, если при выполнении не менее 25 % запланированных тест-кейсов более 50 % из них завершились обнаружением дефекта (метрика «Стоп-фактор»).

• Критерии возобновления тестирования: исправление более 50 % обнаруженных на предыдущей итерации дефектов
• Критерии завершения тестирования: выполнение более 80 % запланированных на итерацию тест-кейсов

Ресурсы

• Программные ресурсы: четыре виртуальных машины (две с ОС Windows 7 Ent x64, две с ОС Linux Ubuntu 14 LTS x64), две копии PHP Storm 8.
• Аппаратные ресурсы: две стандартных рабочих станции (8GB RAM, i7 3GHz).
• Человеческие ресурсы:

- Старший разработчик с опытом тестирования (100%-я занятость на всём протяжении проекта). Роли на проекте: лидер команды, старший разработчик.

- Тестировщик со знанием PHP (100%-я занятость на

всём протяжении проекта). Роль на проекте:

тестировщик.

• Временные ресурсы: одна рабочая неделя (40 часов).
• Финансовые ресурсы: согласно утверждённому бюджету.
• Дополнительные

- финансовые ресурсы не требуются.

• Расписание

25.05 — формирование требований.

26.05 — разработка тест-кейсов и скриптов для автоматизированного тестирования.

27.05–28.05 — основная фаза тестирования (выполнение тест-кейсов, написание отчётов о дефектах).

29.05 — завершение тестирования и подведение итогов.

Роли и ответственность

• Старший разработчик: участие в формировании требований, участие в аудите кода.
• Тестировщик: формирование тестовой документации, реализация тестирования, участие в аудите кода.

Оценка рисков

• Персонал (вероятность низкая): в случае нетрудоспособности какого-либо из участников команды можно обратиться к представителям проекта для предоставления временной замены (договорённость с менеджером достигнута).
• Время (вероятность высокая): заказчиком обозначен крайний срок сдачи 01.06, потому время является критическим ресурсом. Рекомендуется приложить максимум усилий к тому, чтобы фактически завершить проект 28.05 с тем, чтобы один день (29.05) остался в запасе.
• Иные риски: иных специфических рисков не выявлено.

Документация

• Требования. Ответственный — тестировщик, дата готовности 25.05.
• Тест-кейсы и отчёты о дефектах. Ответственный — тестировщик, период создания 26.05–28.05.
• Отчёт о результатах тестирования. Ответственный — тестировщик, дата готовности 29.05.