Когда будете тестировать?

последовательность проведения работ: подготовка (Test Preparation), тестирование (Testing), анализ результатов (Test Result Analisys) в разрезе запланированных фаз разработки

Критерии начала тестирования:

готовность тестовой платформы (тестового стенда) o законченность разработки требуемого функционала o наличие всей необходимой документации o ...

Критерии окончания тестирования:

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

требования к количеству открытых багов выполнены

выдержка определенного периода без изменения исходного кода приложения Code Freeze (CF)

выдержка определенного периода без открытия новых багов Zero

Bug Bounce (ZBB)

...

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

Окружение тестируемой системы (описание программно-аппаратных средств)

Необходимое для тестирования оборудование и программные средства (тестовый стенд и его конфигурация, программы для автоматизированного тестирования и т.д.)

Риски и пути их разрешения

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

Ведущий тестировщик

Тест менеджер (менеджер по качеству)

Руководитель разработки

Менеджер Проекта

Процесс тестирования объединяет различные способы тестирования в спланированную последовательность шагов, которые приводят к успешному построению программной системы (ПС). Методика тестирования ПС может быть представлена в виде разворачивающейся спирали (рис. 1).

В начале осуществляется тестирование элементов (модулей), проверяющее результаты этапа кодирования ПС. На втором шаге выполняется тестирование интеграции, ориентированное на выявление ошибок этапа проектирования ПС. На третьем обороте спирали производится тестирование

правильности, проверяющее Рис. 3. Спираль процесса тестирования ПСкорректность этапа анализа требований к ПС. На заключительном витке спирали проводится системное тестирование, выявляющее дефекты этапа системного анализа ПС.

Охарактеризуем каждый шаг процесса тестирования.

Тестирование элементов. Цель — индивидуальная проверка каждого модуля. Используются способы тестирования «белого ящика».

Тестирование интеграции. Цель — тестирование сборки модулей в программную систему. В основном применяют способы тестирования «черного ящика». 3. Тестирование правильности. Цель — проверить реализацию в программной системе всех функциональных и поведенческих требований, а также требования эффективности. Используются исключительно способы тестирования «черного ящика».

4. Системное тестирование. Цель — проверка правильности объединения и взаимодействия всех элементов компьютерной системы, реализации всех системных функций.

Организация процесса тестирования в виде эволюционной разворачивающейся спирали обеспечивает максимальную эффективность поиска ошибок. Однако возникает вопрос — когда заканчивать тестирование?

Ответ практика обычно основан на статистическом критерии: «Можно с 95%-ной уверенностью сказать, что провели достаточное тестирование, если вероятность безотказной работы ЦП с программным изделием в течение 1000 часов составляет по меньшей мере 0,995».

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

_λ(t)₌^λ⁰, (1) λ₀×p×t+1

где _λ(t)— текущая интенсивность программных отказов (количество отказов в единицу времени); λ₀— начальная интенсивность отказов (в начале тестирования); р — экспоненциальное уменьшение интенсивности отказов за счет обнаруживаемых и устраняемых ошибок; t —время тестирования.

С помощью уравнения (1) можно предсказать снижение ошибок в ходе тестирования, а также время, требующееся для достижения допустимо низкой интенсивности отказов.

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

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

оценка объёма и сложности работ;

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

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

Как и любой другой документ, тест-план может быть качественным или обла-дать недостатками. Качественный тест-план обладает большинством свойств каче-ственных требований{40}, а также расширяет их набор следующими пунктами:

Реалистичность (запланированный подход реально выполним).

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

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

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

Ответственным за создание тест-плана, как правило, является ведущий тестировщик («тест-лид»)

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

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

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

В некоторых случаях здесь также приводится приоритет соответствующей области. Области, не подвергаемые тестированию(features not to be tested). Пере-чень функций и/или нефункциональных особенностей приложения, которые не будут подвергнуты тестированию. Причины исключения той или иной об-

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

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

Приёмочные критерии, критерии качества(acceptance criteria327) — любые объективные показатели качества, которым разрабатываемый продукт должен соответствовать с точки зрения заказчика или пользо-вателя, чтобы считаться готовым к эксплуатации. o Критерии начала тестирования(entry criteria328) — перечень условий, при выполнении которых команда приступает к тестированию. Нали-чие этого критерия страхует команду от бессмысленной траты усилий в условиях, когда тестирование не принесёт ожидаемой пользы. o Критерии приостановки тестирования(suspension criteria329) — пе-речень условий, при выполнении которых тестирование приостанав-ливается. Наличие этого критерия также страхует команду от бессмыс-ленной траты усилий в условиях, когда тестирование не принесёт ожи-даемой пользы. o Критерии возобновления тестирования(resumption criteria330) — пе-речень условий, при выполнении которых тестирование возобновля-ется (как правило, после приостановки). o Критерии завершения тестирования(exit criteria331) — перечень условий, при выполнении которых тестирование завершается. Нали-чие этого критерия страхует команду как от преждевременного прекра-щения тестирования, так и от продолжения тестирования в

тестирования в условиях, когда оно уже перестаёт приносить ощутимый эффект. Ресурсы(resources). В данном разделе тест-плана перечисляются все необ-ходимые для успешной реализации стратегии тестирования ресурсы, кото-рые в общем случае можно разделить на: o программные ресурсы (какое ПО необходимо команде тестировщиков, сколько копий и с какими лицензиями (если речь идёт о коммерческом ПО));

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

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

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

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

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

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

Документация(documentation). Перечень используемой тестовой докумен-тации с указанием, кто и когда должен её готовить и кому передавать.

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

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

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

Рекомендации по написанию Тест Плана

Каждая методология или процесс пытаются навязать нам свои форматы оформления планов тестирования. Предлагаю вам, как пример, шаблоны тест планов от RUP (Rational Unified Process) и стандарт IEEE 829:

Test Plan Template RUP

Test Plan Template IEEE 829

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

Что надо тестировать? o описание объекта тестирования: системы, приложения, оборудования

Что будете тестировать?

список функций и описание тестируемой системы и её компонент в отдельности

Как будете тестировать?

стратегия тестирования, а именно: виды тестирования и их применение по отношению к объекту тестирования