Жизненный цикл ошибки это

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

As we know during the development of any software product the development teams follow the Software Development Life Cycle (SDLC) processes. But the development process is not so easy and always runs smoothly. During the development process when a product is being developed different types of defects or bugs arise with the product. So these defects are identified and resolved throughout the development process just to deliver a good quality software product at last. So in this article, we will discuss these bugs in the software development process and how these are identified during software testing, and how these are resolved.

What is a Bug/Defect?

A defect is an error or bug in an application that is created during the building or designing of software and due to which software starts to show abnormal behaviors during its use. So it is one of the important responsibilities of the tester to find as much as defect possible to ensure the quality of the product is not affected and the end product is fulfilling all requirements perfectly for which it has been designed and provide required services to the end-user. Because as much as defects will be identified and resolved then the software will behave perfectly as per expectation.

What is Defect Life Cycle?

In the Software Development Process, Defect Life Cycle is the life cycle of a defect or bug which it goes through covering a specific set of states in its entire life. Mainly bug life cycle refers to its entire state starting from a new defect detected to the closing off of that defect by the tester. Alternatively, it is also called a Bug Life Cycle.

• The journey of the Defect Cycle varies from organization to organization and also from project to project because development procedures and platforms as well as testing methods and testing tools differ depending upon organizations and projects. 
• The number of states that a defect goes through also varies depending upon the different tools used and processes followed during the testing of software.
• The objective of the defect lifecycle is to easily coordinate and communicate the current status of the defect and thus help to make the defect-fixing process efficient. 

Defect Status

Defect status or Bug status is the current state from which the defect is currently going through. The number of states the defect goes through varies from project to project. The below diagram illustrates all the possible states of the defect:

1. New: When any new defect is identified by the tester, it falls in the ‘New’ state. It is the first state of the Bug Life Cycle. The tester provides a proper Defect document to the Development team so that the development team can refer to Defect Document and can fix the bug accordingly.

2. Assigned: Defects that are in the status of ‘New’ will be approved and that newly identified defect is assigned to the development team for working on the defect and to resolve that. When the defect is assigned to the developer team the status of the bug changes to the ‘Assigned’ state.

3. Open: In this ‘Open’ state the defect is being addressed by the developer team and the developer team works on the defect for fixing the bug. Based on some specific reason if the developer team feels that the defect is not appropriate then it is transferred to either the ‘Rejected’ or ‘Deferred’ state.

4. Fixed: After necessary changes of codes or after fixing identified bug developer team marks the state as ‘Fixed’.

5. Pending Request: During the fixing of the defect is completed, the developer team passes the new code to the testing team for retesting. And the code/application is pending for retesting on the Tester side so the status is assigned as ‘Pending Retest’.

6. Retest: At this stage, the tester starts work of retesting the defect to check whether the defect is fixed by the developer or not, and the status is marked as ‘Retesting’.

7. Reopen: After ‘Retesting’ if the tester team found that the bug continues like previously even after the developer team has fixed the bug, then the status of the bug is again changed to ‘Reopened’. Once again bug goes to the ‘Open’ state and goes through the life cycle again. This means it goes for Re-fixing by the developer team.

8. Verified: The tester re-tests the bug after it got fixed by the developer team and if the tester does not find any kind of defect/bug then the bug is fixed and the status assigned is ‘Verified’.

9. Closed: It is the final state of the Defect Cycle, after fixing the defect by the developer team when testing found that the bug has been resolved and it does not persist then they mark the defect as a ‘Closed’ state.

Few More States that also come under this Defect Life Cycle:

1. Rejected: If the developer team rejects a defect if they feel that defect is not considered a genuine defect, and then they mark the status as ‘Rejected’. The cause of rejection may be any of these three i.e Duplicate Defect, NOT a Defect, Non-Reproducible.

2. Deferred: All defects have a bad impact on developed software and also they have a level based on their impact on software. If the developer team feels that the defect that is identified is not a prime priority and it can get fixed in further updates or releases then the developer team can mark the status as ‘Deferred’. This means from the current defect life cycle it will be terminated.

3. Duplicate: Sometimes it may happen that the defect is repeated twice or the defect is the same as any other defect then it is marked as a ‘Duplicate’ state and then the defect is ‘Rejected’.

4. Not a Defect: If the defect has no impact or effect on other functions of the software then it is marked as ‘NOT A DEFECT’ state and ‘Rejected’.

5. Non-Reproducible: If the defect is not reproduced due to platform mismatch, data mismatch, build mismatch, or any other reason then the developer marks the defect as in a ‘Non-Reproducible’ state.

6. Can’t be Fixed: If the developer team fails to fix the defect due to Technology support, the Cost of fixing a bug is more, lack of required skill, or due to any other reasons then the developer team marks the defect as in ‘Can’t be fixed’ state.

7. Need more information: This state is very close to the ‘Non-reproducible’ state. But it is different from that. When the developer team fails to reproduce the defect due to the steps/document provided by the tester being insufficient or the Defect Document is not so clear to reproduce the defect then the developer team can change the status to “Need more information’. When the Tester team provides a good defect document the developer team proceeds to fix the bug.

Defect Lifecycle

Consider the flow chart below to understand the defect lifecycle.

1. The tester finds a defect.
2. The defect status is changed to New.
3. The development manager will then analyze the defect.
4. The manager determines if the defect is valid or not.
5. If the defect is not valid then the development manager assigns the status Rejected to defect.
6. If the defect is valid then it is checked whether the defect is in scope or not. If no then the defect status is changed to Deferred.
7. If the defect is in scope then the manager checks whether a similar defect was raised earlier. If yes then the defect is assigned a status duplicate.
8. If the defect is not already raised then the manager starts fixing the code and the defect is assigned the status In-Progress.
9. Once the defect is fixed the status is changed to fixed.
10. The tester retests the code if the test is passed then the defect status is changed to closed.
11. If the test fails again then the defect is assigned status reopened and assigned to the developer.

Benefits of Defect Lifecycle

• Deliver High-Quality Product
• Improve Return on Investment (ROI) by Reducing the Cost of Development
• Better Communication, Teamwork, and Connectivity
• Detect Issues Earlier and Understand Defect Trends
• Better Service and Customer Satisfaction

Limitations in Defect Lifecycle

• Variations of the Bug Life Cycle
• No Control on Test Environment

Last Updated :
18 Aug, 2023

Like Article

Save Article

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

Ошибка, дефект, но чаще всего баг. Именно так называется то, что находят тестировщики в процессе работы.

Определение бага

Bug в переводе означает “жук, насекомое”. Первая ошибка, которая была задокументирована, возникла как раз из-за жука. В середине 40-х годов 20 века ученых Гарвардского университета вызвали для того, чтобы определить причину сбоя в работе вычислительной машины Mark II. Покопавшись в этой громадной куче приборов, соединенных проводами, они обнаружили бабочку, застрявшую между контактами электромеханического реле. Стало ясно, что именно она и явилась причиной сбоя. Одна из сотрудниц университета, Грейс Хоппер, так и сформулировала результат исследований: «неполадку вызвал баг». Извлеченное насекомое было вклеено скотчем в технический дневник, с соответствующей сопроводительной надписью. Ее, как говорят, до сих пор можно увидеть в этом журнале, хранящемся в университетском научном музее.

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

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

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

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

Жизненный цикл бага

Давайте вкратце разберем каждый этап жизненного цикла

1. Новый (New) — Тестировщик находит баг, локализует и вносит его в специальную систему, где хранятся баг-репорты. С этого момента баг начинает официально существовать.
   Далее его статус меняется на Отказ (Rejected) или на Назначен (Assigned).
2. Отказ (Rejected) — пишется комментарий программиста или менеджера о причине reject-a(отклонения). Это может быть некачественное описание дефекта, такой дефект уже существует (дубликат), невозможность воспроизвести дефект. Также это может произойти потому что для заказчика какие-то ошибки перестали быть актуальными. После этого, тестировщик или закрывает дефект (Closed), или дополняет комментарии данного дефекта и переводит дефект заново в состояние Назначен(Assigned).
3. Назначен (Assigned)— дефект просмотрен и открыт (то есть признан для исправления).
4. Решен (Fixed) — дефект исправили и он в этом состоянии требует перепроверки тестировщиком.
5. После проверки ошибки тестировщиком, дефект переводится в состояние Переоткрыт (Re-opened) (если дефект не исправлен или исправлен не полностью) либо в Закрыт (Closed), если ошибка исправлена.

Данную схему можно изобразить в текстовом виде. Вот несколько вариантов прохождения багов (можно просто нарисовать на листочке на собеседовании):
1. Новый (new) —> Отклонен (rejected) —> Закрыт (closed)
2. Новый (new) —> Назначен (аssigned) —> Решен (fixed) —> Закрыт (closed)
3. Новый (new) —> Назначен (аssigned) —> Решен (fixed) —> Закрыт (closed) —> Переоткрыт (re-opend)

Жизненный цикл бага с точки зрения команды

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

Сначала тестировщик находит баг. Далее заносит его в систему учета ошибок. После этого программист начинает изучать отчет о дефекте. Именно на этом этапе он решает баг это или нет.

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

Если баг больше не воспроизводится, то тестировщик закрывает баг.
Если баг снова воспроизводится, то мы возвращаем его программисту. И снова проходим все шаги, начиная с 3-го шага (рассмотрения проблемы программистом).

Теперь другой сценарий — разработчик не принял баг. Если баг не принят, то разработчик возвращает его нам. Наша задача — рассмотреть проблему. Если баг вернули из-за некорректного описания, то значит переписываем его. Если невозможно воспроизвести дефект, то заново проверяем все шаги, может мы что то упустили при описании. Если разработчик прав и бага нет, то мы закрываем баг. А если баг все же есть, то вносим необходимые коррективы и опять возвращаемся на шаг 3.

***

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