Жизненный цикл дефекта. Системы документирования дефектов (bug-tracking systems). Классификация и принципы описания дефекта (bug report).

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

ЖЦ дефекта

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

Обнаружен (Submitted) – тестировщик нашел баг. Состоялось «рождение» дефекта в QA-мире.

Новый (New) – дефект успешно занесен в систему.

После этого, в зависимости от решения менеджера проекта, баг может быть:

Отклонен (Declined). По разным причинам дефект может и не считаться дефектом или считаться неактуальным дефектом, что вынуждает отклонить его.

Отложен (Deferred). Исправление этого бага не несет ценности на данном этапе разработки или по другим, отсрочивающим его исправление причинам.

Открыт (Opened). Ответственное лицо признало дефект дефектом, при чем таким, который нужно исправить.

Когда наличие дефекта неопровержимо, его путь может привести к следующим статусам:

Назначен (Assigned). Исправление текущего бага возложено на плечи определенного разработчика.

Исправлен (Fixed). Ответственный за исправление бага разработчик заявляет, что устранил дефект.

В зависимости от того, исправил ли разработчик дефект, дефект может быть:

Проверен (Verified). Тестировщик проверяет, действительно ли ответственный разработчик исправил дефект, или все-таки разработчик безответственный. Если бага больше нет, он получает данный статус.

Повторно открыт (Reopened). Если опасения тестировщика оправданы и баг в новом билде не исправлен – он все так же потребует исправления, поэтому заново открывается.

Закрытый (Fixed). В результате определенного количества циклов баг все-таки окончательно устранен и больше не потребует внимания команды – он объявляется закрытым.

Классификация дефектов

Классификация дефектов, с точки зрения степени влияния (Severity) на работоспособность ПО:

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

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

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

Trivial. Баг, не имеющий влияние на функционал или работу программы, но который может быть обнаружен визуально. Например, ошибка в тексте.

Градация дефектов, с точки зрения приоритетности исправления (Priority):High. Баг должен быть исправлен как можно быстрее, т.к. он критически влияет на работоспособность программы.

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

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

Принципы описания дефектов

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

В общем случае, баг репорт состоит из:

Шапка.

Короткое описание (короткое описание проблемы).

Проект (название текущего проекта).

Компонент приложения (в котором возник дефект).

Версия (версия билда, в котором найден баг).

Серьезность (градация степени влияния на приложение бага).

Приоритет (очередь исправления бага).

Статус (отображает статус бага в своем жизненном цикле).

Автор (автор баг репорта).

Назначение (кто должен исправить дефект).

Окружение.

Операционная система, разрядность, Сервис Пак, браузер, его версия и т.д.

Описание.

Шаги воспроизведения (описание пути, который приводит к возникновению дефекта).

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

Ожидаемый результат (результат, который быть в соответствии с требованиями).

Дополнения.

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

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

Краткое описание. Поле, в котором нужно поместить весь смысл всего баг репорта. Чаще всего, в коротком описании лаконично отвечают на 3 вопроса: «Где?», «Что?», «Когда?» (именно в такой последовательности, как бы не хотелось изменить ее по примеру всем известной игры).

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

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

Фактический результат.

Ожидаемый результат.

46. Состав, назначение и принципы организации тест-плана.

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

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

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

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

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

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

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

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

последовательность проведения работ: подготовка (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)₌ ^λ0 , (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 описание объекта тестирования: системы, приложения, оборудования

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

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

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

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

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

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

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

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

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

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

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

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

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

...

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

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

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

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

Виды тест планов

Чаще всего на практике приходится сталкиваться со следующими видами тест планов:

Мастер Тест План (Master Plan or Master Test Plan)

Тест План (Test Plan), назовем его детальный тест план)

План Приемочных Испытаний (Product Acceptance Plan) - документ, описывающий набор действий, связанных с приемочным тестированием (стратегия, дата проведения, ответственные работники и т.д.) (Шаблон плана приемо-сдаточных испытаний от RUP)

Явное отличие Мастер Тест Плана от просто Тест Плана в том, что мастер тест план является более статичным в силу того, что содержит в себе высокоуровневую (High Level) информацию, которая не подвержена частому изменению в процессе тестирования и пересмотра требований. Сам же детальный тест план, который содержит более конкретную информацию по стратегии, видам тестировании, расписанию выполнения работ, является "живым" документом, который постоянно претерпевает изменения, отражающие реальное положение дел на проекте.

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

Рецензия и Утверждение

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

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

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

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

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

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

47.Тестовые примеры (тест-кейсы): структура, принципы разработки.

Еще одной обязательной сущностью, с которой столкнется каждый тестировщик, является Test Case(Тестовый случай).

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

Структура данного артефакта заключается в «троице»:

Выполняемое действие (Action) – Ожидаемый результат (Expected result) – Фактический результат (Test result).

Непосредственно сам тестовый случай состоит из 3 частей:

PreConditions(Предусловия) – либо список шагов, которые приводят проверяемую систему в состояние, пригодное для тестирования, либо список проверок условий того, что система уже находиться в необходимом состоянии.

Test Case Description(Описание тестового случая) – список действий, с помощью которых осуществляется основная проверка функционала (после которой и сверяется фактический результат с ожидаемым).

PostConditions(Постусловия) –список действий, которые возвращают систему в исходное состояние.

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