Типичный жизненный цикл дефекта

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

Состав информации о дефекте[править | править код]

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

• номер (идентификатор) дефекта;
• короткое описание дефекта;
• кто сообщил о дефекте;
• дата и время, когда был обнаружен дефект;
• версия продукта, в которой обнаружен дефект;
• серьёзность (критичность) дефекта и приоритет решения[1];
• описание шагов для выявления дефекта (воспроизведения непреднамеренного поведения программы);
• ожидаемый результат и фактический результат;
• кто ответственен за устранение дефекта;
• обсуждение возможных решений и их последствий;
• текущее состояние (статус) дефекта;
• версия продукта, в которой дефект исправлен.

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

Жизненный цикл дефекта[править | править код]

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

Типичный жизненный цикл дефекта:

1. новый – дефект зарегистрирован тестировщиком
2. назначен – назначен ответственный за исправление дефекта
3. разрешён – дефект переходит обратно в сферу ответственности тестировщика. Как правило, сопровождается резолюцией, например:
   • исправлено (исправления включены в версию такую-то)
   • дубль (повторяет дефект, уже находящийся в работе).
   • не исправлено (работает в соответствии со спецификацией, имеет слишком низкий приоритет, исправление отложено до следующей версии и т. п.)
   • невоспроизводимо (запрос дополнительной информации об условиях, в которых дефект проявляется).
4. далее тестировщик проводит проверку исправления, в зависимости от чего дефект либо снова переходит в статус назначен (если он описан как исправленный, но не исправлен), либо в статус закрыт.
5. открыт повторно – дефект вновь найден в другой версии.

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

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

Примеры систем отслеживания ошибок[править | править код]

Свободно распространяемые

• Redmine – не относится к системам отслеживания ошибок, но многие компании его используют.
• BUGS – the Bug Genie https://www.thebuggenie.com/
• Bugzilla https://www.bugzilla.org/features/
• eTraxis https://www.etraxis.com/
• GNATS
• Launchpad
• Mantis bug tracking system
• Trac
• EmForge
• Picket
• Flyspray (сайт)
• DEVPROM

Проприетарные

• Atlassian JIRA
• Bontq
• PVCS Tracker
• Project Kaiser
• TrackStudio Enterprise
• YouTrack
• Яндекс.Трекер (есть пробный период)

Разное

• BugTracker.NET
• BugNet
• ClearQuest
• Intland CodeBeamer
• LifeTask.ru
• FlySpray
• StarTeam

Примечания[править | править код]

1. ↑ «Бейзер, например, предлагает шкалу от 1 (незначительная ошибка, например, грамматическая) до 10 (фатальная, вызывающая сбои в других системах, войны, убийства и т. д.)». «Тестирование программного обеспечения», Канер, Фолк, Нгуен. Гл. 5, с. 105. ISBN 9667393879

См. также[править | править код]

• Сравнение систем отслеживания ошибок
• Багтрак
• Баг
• Книга жалоб и предложений

Ссылки[править | править код]

Источник

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

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

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

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

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

Статус дефекта

Статусы в жизненном цикле дефекта и их обозначение

«New» (новый) – описание дефекта записывается в систему управления впервые.

«Ased» (назначен) – отчет об ошибке назначен на определенного пользователя.

«Open» (открыт) – пользователь начинает работу с отчетом (анализ и редактирование).

«Fixed» (исправлен) – пользователь внес нужные исправления в код и протестировал их самостоятельно. Отчет со статусом «Исправлен» снова возвращается тестировщику.

«Pending retest» (Тестирование в режиме ожидания) – разработчик исправил баг, предоставил новый код для тестирования.

«Retesting» (повторное тестирование) – тестировщик повторно проверяет код, измененный разработчиком, с целью посмотреть, исправлена ли ошибка.

«Verified» (проверен) – если дефект исправлен, тестировщик ставит данный статус.

«Reopened» (переоткрыт) – если ошибка снова появляется, тестировщик опять перенаправляет ее на разработчика. Дефект проходит те же стадии.

«Closed» (закрыт) – такой статус ставится тестировщиком, если тот уверен, что дефект исправлен и он больше не появляется.

«Duplicate» (дубликат) – когда дефект встречается дважды или есть два дефекта, появившихся вследствие одной проблемы, один из них получает этот статус.

«Rejected» (отклонен) – если с точки зрения разработчика, ошибка не является весомой и она не требует рассмотрения и исправления, он ее отклоняет.

«Deferred» (отсрочен) – в режиме ожидания, что ошибку с таким статусом исправят в других версиях. В основном, дефект получает такой статус по нескольким причинам: низкий приоритет ошибки, недостаток времени, дефект не приведет к значительным сбоям в программе.

«Not a bug» (не является багом) – назначается в том случае, когда функциональные возможности программы меняться не будут. К примеру, заказчик хочет сменить габариты клавиш или цвет продукта – это не ошибка, а просто необходимость внесения поправок в дизайн программы.

Стадии жизненного цикла ошибки

1. Тестировщик обнаруживает дефект.

2. Тестировщик пишет отчет об ошибке в систему управления дефектами (статус New (новый)) и перенаправляет его на разработчика (статус Ased (назначен)).

3. Разработчик изучает ошибку, ее возможности воспроизведения и по полученным результатам соотносит ее к одному из статусов:

• Duplicate (дубликат) – подобный дефект уже существует в системе по отслеживанию ошибок;
• Rejected (отклонен) – ошибка не требует внесения корректив, поскольку ее влияние на продукт незначительное;
• Deferred (отсрочен) – корректировку данной ошибки можно осуществить в другой версии программы;
• Not a bug (не баг) – дефект не есть ошибкой, поэтому вносит коррективы не требуется;
• Open (открыт) – дефект в процессе исправления;
• Fixed (исправлен) – код изменен и протестирован разработчиком.

4.Тестировщик повторно проверяет ошибку (статус «Retesting» (повторное тестирование)).

5. Если дефект исправлен, тестировщик его закрывает (статусы «Verified» (проверен), затем «Closed» (закрыт)).

6. Если дефект проявляется и дальше, он опять передается на редактирование разработчику (статусы «Reopened» (переоткрыт), «Ased» (назначен)) и вновь проходит через каждую стадию цикла.

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

Источник

Что такое жизненный цикл дефекта?

DEFECT LIFE CYCLE или Bug Life Cycle – это особый набор состояний, через которые проходит ошибка в течение всей своей жизни. Цель жизненного цикла Дефекта состоит в том, чтобы легко координировать изменения состояния ошибок для различных сотрудников и систематизировать процесс устранения ошибок.

Состояние жизненного цикла ошибки

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

• Новый: когда новый дефект регистрируется и публикуется впервые. Ему присвоен статус НОВЫЙ.
• Назначено: как только тестер публикует сообщение об ошибке, ведущий тестировщика утверждает ошибку и назначает ее команде разработчиков.
• Открыто : разработчик начинает анализ и работает над исправлением дефекта
• Исправлено : Когда разработчик вносит необходимые изменения в код и проверяет это изменение, он может сделать статус ошибки «Исправлено».
• Ожидание повторного тестирования : после устранения дефекта разработчик предоставляет конкретный код для повторного тестирования кода тестировщику. Поскольку тестирование программного обеспечения остается в ожидании со стороны тестировщиков, присваивается статус «ожидает повторного тестирования».
• Повторное тестирование: тестер выполняет повторное тестирование кода на этом этапе, чтобы проверить, исправлен ли дефект разработчиком или нет, и изменяет статус на «Повторное тестирование».

• Проверено : тестер повторно тестирует ошибку после ее исправления разработчиком. Если в программном обеспечении не обнаружено ошибок, то ошибка устранена, и присвоенный статус «проверен».
• Повторное открытие : если ошибка сохраняется даже после того, как разработчик исправил ошибку, тестер изменяет статус на «вновь открыт». Еще раз ошибка проходит через жизненный цикл.
• Закрыто : если ошибка больше не существует, то тестер присваивает статус «Закрыто».
• Дублировать : если дефект повторяется дважды или дефект соответствует одной и той же концепции ошибки, статус меняется на «дубликат».
• Отклонено : если разработчик считает, что дефект не является подлинным, он заменяет дефект на «отклоненный».
• Отложено : если текущая ошибка не имеет основного приоритета и ожидается, что она будет исправлена ​​в следующем выпуске, то статус «Отложено» присваивается таким ошибкам
• Не ошибка : если это не влияет на функциональность приложения, то статус, присвоенный ошибке – «Не ошибка».

Объяснение жизненного цикла дефекта

1. Тестер находит дефект
2. Статус присвоен дефекту – Новый
3. Дефект передается руководителю проекта для анализа
4. Руководитель проекта решает, является ли дефект действительным
5. Здесь дефект недействителен – статус присвоен «Отклонено».
6. Итак, менеджер проекта присваивает статус отклонен . Если дефект не отклонен, то следующий шаг должен проверить, находится ли он в области. Предположим, у нас есть другая функция – функция электронной почты для того же приложения, и вы столкнулись с проблемой. Но это не является частью текущей версии, когда такие дефекты присваиваются как отложенный или отложенный статус.
7. Затем менеджер проверяет, был ли подобный дефект обнаружен ранее. Если да, дефекту присваивается дубликат статуса .
8. Если нет, дефект назначается разработчику, который начинает исправлять код. На этом этапе дефекту присваивается статус выполнения.
9. После того, как код исправлен. Дефекту присвоен статус исправлено
10. Далее тестер повторно проверит код. В случае, если контрольный пример проходит, дефект закрывается. Если тестовые случаи снова не пройдены, дефект повторно открывается и назначается разработчику.
11. Рассмотрим ситуацию, когда во время 1-го выпуска Резервирования рейса был обнаружен дефект в заказе факса, который был исправлен и ему был присвоен статус закрыт. Во время второго выпуска обновления тот же дефект снова обнаружился. В таких случаях закрытый дефект будет вновь открыт.

Это все, чтобы Bug Life Cycle

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

Нажмите здесь, если видео не доступно

Источник

Тестовые процедуры

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

Рис. 10.1. Пример фрагмента тестовой процедуры для ручного тестирования

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

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

Рис. 10.2. Пример фрагмента автоматизированной тестовой процедуры

Описание тестов

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

1. Анализировать степень покрытия продукта тестами на основании описания тестового набора.
2. Для любой функции тестируемого продукта найти тесты, в которых функция используется.
3. Для любого теста определить все функции и их сочетания, которые данный тест использует (затрагивает).
4. Понять структуру и взаимосвязи тестовых файлов.
5. Понять принцип построения системы автоматизации тестирования.

Документирование и жизненный цикл дефекта

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

1. Наименование подсистемы, в которой обнаружен дефект.
2. Версия продукта (номер build ), на котором дефект был найден.
3. Описание дефекта.
4. Описание процедуры (шагов, необходимых для воспроизведения дефекта).
5. Номер теста, на котором дефект был обнаружен.
6. Уровень дефекта, то есть степень его серьезности с точки зрения критериев качества продукта или заказчика.

Занесенный в базу дефектов новый дефект находится в состоянии ” New ” . После того, как команда разработчиков проанализирует дефект, он переводится в состояние ” Open ” с указанием конкретного разработчика, ответственного за исправление дефекта. После исправления дефект переводится разработчиком в состояние ” Resolved “. При этом разработчик должен указать следующую информацию:

1. Причину возникновения дефекта.
2. Место исправления, как минимум, с точностью до исправленного файла.
3. Краткое описание того, что было исправлено.
4. Время, затраченное на исправление.

После этого тестировщик проверяет, действительно ли дефект был исправлен и если это так, переводит его в состояние ” Verified “. Если тестировщик не подтвердит факт исправления дефекта, то состояние дефекта изменяется снова на ” Open “.

Если проектная команда принимает решение о том, что некоторый дефект исправляться не будет, то такой дефект переводится в состояние ” Postponed ” с указанием лиц, ответственных за это решение, и причин его принятия.

Тестовый отчет

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

1. Перечень функциональности в соответствии с пунктами требований, запланированный для тестирования на данном цикле, и реальные данные по нему.
2. Количество выполненных тестов – запланированное и реально исполненное.
3. Время, затраченное на тестирование каждой функции, и общее время тестирования.
4. Количество найденных дефектов.
5. Количество повторно открытых дефектов.
6. Отклонения от запланированной последовательности действий, если таковые имели место.
7. Выводы о необходимых корректировках в системе тестов, которые должны быть сделаны до следующего тестового цикла.

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

Рис. 10.3. Фрагмент тестового отчета

Источник