Введение в понятие жизненного цикла дефекта
В этом руководстве мы рассмотрим жизненный цикл дефекта и его различные стадии, с которыми приходится сталкиваться тестировщику во время работы в тестовой среде.
Мы также добавили наиболее часто задаваемые на собеседовании вопросы по жизненному циклу дефекта. Чтобы в нем разобраться, важно знать о различных состояниях дефекта.
С точки зрения реальных сценариев, ошибки/недочеты/неисправности называются багами/дефектами, поэтому можно сказать, что основная цель тестирования – убедиться, что продукт менее подвержен дефектам (отсутствие дефектов – нереалистичная ситуация).
Теперь возникает вопрос, что же такое дефект?
Содержание:
Реализация жизненного цикла дефекта
Дополнительная информация о дефекте
Некорректный и повторяющийся отчет о дефект
Друзья, поддержите нас вступлением в наш телеграм канал QaRocks. Там много туторилов, задач по автоматизации и книг по QA.
Что такое дефект?
Дефект простым языком – это недостаток или ошибка в приложении, которая ограничивает его нормальное функционирование путем несоответствия ожидаемого поведения приложения фактическому.
Дефект возникает, когда разработчик допускает какую-либо ошибку во время проектирования или создания приложения, после чего этот недостаток обнаруживается тестировщиком.
В обязанности тестировщика входит тщательное тестирование приложения с целью найти как можно больше дефектов и гарантировать, что конечный пользователь получит качественный продукт. Прежде чем переходить к рабочему процессу и различным состояниям дефекта, важно понимать, что существует жизненный цикл дефекта.
Рассмотрим его подробнее.
Жизненный цикл дефекта
Жизненный цикл дефекта(бага) – это цикл, через который проходит дефект за весь период своего существования, включая его различные состояния. Он начинается с момента обнаружения тестировщиком нового бага, и заканчивается, когда тестировщик закрывает баг, гарантируя, что он не будет воспроизведен снова.
Рабочий процесс дефекта
Разберемся в фактическом рабочем процессе жизненного цикла бага с помощью простой диаграммы, показанной ниже.
Состояния дефекта
1. Новый (New): Это первое состояние дефекта в его жизненном цикле. Когда обнаруживается любой новый баг, он переходит в состояние “Новый”, а его валидация и тестирование выполняются на более поздних стадиях жизненного цикла.
2. Назначен (Assigned): На этом этапе заведенный впервые дефект передается команде разработчиков. Разработчика-исполнителя назначает руководитель проекта или менеджер команды тестирования .
3. Открыт (Open): Данный статус присваивается дефекту, когда разработчик начинает процесс его анализа и работает над его исправлением, если это необходимо.
Если по мнению разработчика дефект неактуален или некорректен, то он может быть переведен в одно из следующих четырех состояний: “Дубликат”(“Duplicate“), “Отложено” (“Deferred”), “Отклонено” (“Rejected”) или “Не ошибка”(“Not a Bug”) на основании определенных фактов. Позже мы рассмотрим подробнее эти четыре состояния.
4. Исправлен (Fixed): Когда разработчик завершает задачу по исправлению дефекта, внося необходимые изменения в код, он изменяет статус дефекта на “Исправлен”.
5. Ожидание повторного тестирования (Pending Retest): После исправления дефекта разработчик передает его тестировщику для повторного тестирования. Пока этого не произойдет, баг остается в статусе “Pending Retest”.
6. Нужен повторный тест (Retest): На этом этапе тестировщик приступает к повторному тестированию дефекта, чтобы проверить, насколько точно он исправлен разработчиком в соответствии с требованиями.
7. Открыт заново (Reopen): Если в рамках дефекта какая-либо проблема не была исправлена, он снова передается разработчику, а статус дефекта меняется на “Reopen”.
8. Проверен (Verified): Если тестировщик после проведения повторного тестирования считает, что дефект был исправлен, то статус дефекта меняется на “Verified”.
9. Закрыт (Closed): Когда дефект больше не существует и полностью исправлен, тестировщик меняет статус дефекта на “Closed”.
Еще несколько возможных состояний:
- Отклонен (Rejected): Если разработчик считает дефект некорректным, то он помечается как “Rejected”.
- Дубликат (Duplicate): Если заведенный баг уже существует или его описание совпадает с любым другим дефектом, то статус меняется на “Duplicate”.
- Отложенный (Deferred): Если разработчику кажется, что у дефекта не очень высокий приоритет, и он может быть исправлен в следующих релизах, то статус может быть изменен на ‘Deferred”.
- Не ошибка (Not a Bug): Если дефект никак не влияет на функциональность приложения, то его статус меняется на “Not a Bug”.
Обязательные поля, которые тестировщик заполняет при заведении отчета по любому новому дефекту – Версия сборки (Build version), Программный продукт (Product), Модуль (Module), Серьезность (Severity), Краткое описание (Title) и Шаги воспроизведения (Steps to Reproduce).
В вышеприведенный список можно добавить еще несколько необязательных полей. К ним относятся Имя клиента (Customer name), Браузер (Browser), Операционная система (Operating system), Приложенные файлы (File Attachments).
Следующие поля могут быть либо заполнены, либо остаться пустыми:
Иногда у тестировщика есть право добавлять поля Статус ошибки (Status), Приоритет (Priority) и ‘Назначено на’ (‘Assigned to’). В противном случае QA менеджер сам установит статус и приоритет бага и назначит его соответствующему разработчику модуля.
Рассмотрим следующий цикл дефектов
Приведенная выше схема довольно подробно показывает основные этапы жизненного цикла дефекта.
После обнаружения баг изучают менеджеры по разработке и тестированию. Они могут установить статус “Open” и передать баг разработчику или отложить до следующего релиза.
Когда ошибка назначается разработчику, он начинает работу над ней. Разработчик может установить следующие статусы ошибки – “Не будет исправлена”(“won’t fix”), “Не удалось воспроизвести”(“Couldn’t reproduce”), “Требуется дополнительная информация”(“Need more information”) или “Исправлена”(“Fixed”).
Если статус ошибки, установленный разработчиком, либо “Need more information”, либо “Fixed”, то QA команда должна отреагировать на это в соответствии с присвоенным ошибке статусом. Если баг исправлен, тестировщик проверяет его и может установить статус “Проверен и закрыт” (“verified closed”) или “Открыт заново”(“Reopen”).
Реализация жизненного цикла дефекта
Перед началом работы с жизненным циклом дефекта важно прийти к некоторым важным договоренностям.
Они заключаются в следующем:
- Как говорилось ранее, очень важно, чтобы перед началом работы над жизненным циклом дефекта вся команда четко понимала различные состояния дефекта.
- Жизненный цикл бага должен быть надлежащим образом задокументирован, чтобы избежать путаницы в будущем.
- Убедитесь, что каждый человек, которому поручена какая-либо задача, связанная с жизненным циклом дефекта, четко понимает уровень своей ответственности для достижения лучших результатов.
- Каждый участник команды, у которого есть право изменять статус дефекта, должен быть хорошо осведомлен об этом статусе. Также он должен предоставить подробную информацию о присвоенном статусе и причине его присвоения, чтобы каждый, кто работает над этим конкретным дефектом, мог легко понять, почему баг переведен именно в это состояние.
- С инструментом отслеживания дефектов следует работать осторожно, чтобы поддерживать согласованность между дефектами и, следовательно, в рабочем процессе жизненного цикла дефекта.
Далее рассмотрим вопросы с собеседований на тему жизненного цикла дефекта.
Часто задаваемые вопросы
Вопрос №1: Что такое дефект с точки зрения тестирования ПО?
Ответ: Дефект – это любой недостаток или ошибка в приложении, который ограничивает его нормальную работу путем несоответствия ожидаемого поведения приложения фактическому.
Вопрос №2: В чем основная разница между ошибкой, дефектом и сбоем?
Ответ:
Ошибка: Это обнаружение несоответствия фактического и ожидаемого поведения приложения на этапе разработки.
Дефект: Это несоответствие между фактическим и ожидаемым поведением приложения на этапе тестирования.
Сбой: Это несоответствие между фактическим и ожидаемым поведением приложения после релиза, обнаруженное клиентом или конечным пользователем.
Вопрос №3: Каков статус дефекта при его первоначальном обнаружении?
Ответ: Когда новый дефект найден, он находится в статусе “New”.
Вопрос №4: Каковы различные состояния дефекта в жизненном цикле, когда он утвержден и исправлен разработчиком?
Ответ: Различные состояния дефекта, в данном случае, это “Новый” (“New”), “Назначен” (“Assigned”), “Открыт” (“Open”), “Исправлен” (“Fixed”), “Ожидает повторной проверки” (“Pending Retest”), “Повторная проверка” (“Retest”), “Проверен” (“Verified”) и “Закрыт” (“Closed”).
Вопрос №5: Что происходит, если тестировщик все еще обнаруживает дефект, который был исправлен разработчиком?
Ответ: Тестировщик может отметить состояние дефекта как “Reopen”, после чего он будет передан разработчику для повторного тестирования.
Вопрос №6: Что такое воспроизводимый дефект?
Ответ: Дефект, который повторяется при каждом выполнении, и шаги которого могут быть зафиксированы.
Вопрос № 7: Какой тип дефекта является невоспроизводимым дефектом?
Ответ: Дефект, который не повторяется стабильно при каждом выполнении, возникает только в некоторых случаях, и шаги которого в качестве доказательства должны быть записаны с помощью скриншотов или видео.
Вопрос №8: Что такое отчет о дефектах?
Ответ: Отчет о дефектах – это документ, содержащий информацию о дефектах или багах в приложении.
Вопрос №9: Какие сведения включают в отчет о дефектах?
Ответ: Отчет о дефектах состоит из ID, описания, названия функции, наименования тест-кейса, отметки, воспроизводимый дефект или нет, статуса, серьезности и приоритета, имени тестировщика, даты тестирования, версии сборки, в которой он был найден, разработчика, на которого был назначен дефект, имени человека, который его исправил, скриншотов или видео с изображением последовательности шагов, даты исправления и имени человека, который утвердил дефект.
Вопрос №10: Когда дефект переходит в статус ‘deferred’?
Ответ: Это обнаруженный дефект, который считается не столь важным и может быть исправлен в более поздних релизах.
Дополнительная информация о дефекте
- Баг может появиться в любой момент жизненного цикла разработки ПО.
- Чем раньше дефект будет обнаружен и устранен, тем ниже будет общая стоимость его устранения.
- Затраты на исправление дефекта минимизируется, когда он устраняется на том же этапе, на котором он был найден.
- Статическое тестирование находит дефект, а не сбой. Стоимость сведена к минимуму, так как отладка не требуется.
- При динамическом тестировании наличие дефекта обнаруживается, когда он приводит к сбою.
Состояния дефекта
| Исходное состояние | Состояние при возврате | Состояние при подтверждении |
| Сбор информации о лице, ответственном за воспроизведение дефекта | Дефект отклонен или запрошена дополнительная информация | Дефект устранен и должен быть протестирован и закрыт |
| Статус “открыт” или “новый” | Статус “отклонен” или “на уточнении” | Статус “решен” и “проверен” |
Некорректный и повторяющийся отчет о дефекте
- Иногда дефекты возникают не из-за кода, а из-за тестовой среды или недопонимания. Такой отчет должен быть закрыт как некорректный (Invalid).
- В случае дубликата бага один отчет сохраняется, а другой закрывается как дубликат.
- Менеджер по тестированию отвечает за общее управление дефектами и процессом тестирования, а команда управления дефектами обычно отвечает за отчеты.
- В команду входят менеджеры по тестированию, разработчики, проджект-менеджеры, продакт-менеджеры и другие заинтересованные стороны.
- Комитет по управлению дефектами должен определить обоснованность каждого дефекта и решить, когда его исправлять или же отложить до следующего релиза. Чтобы определить это, необходимо рассчитать стоимость, риски и последствия отказа от исправления какого-либо дефекта.
- Если дефект должен быть исправлен, то необходимо определить его приоритет.
Данные о дефекте
- Имя автора
- Вид тестирования
- Краткое описание проблемы
- Подробное описание дефекта
- Шаги для воспроизведения
- Фаза жизненного цикла
- ПО, в котором был обнаружен дефект.
- Серьезность и приоритет
- Подсистема или компонент, где возник дефект.
- Деятельность проекта, в ходе которой возник дефект.
- Тип дефекта
- Проекты и продукты, в которых существуют проблемы
- Текущий исполнитель
- Текущее состояние бага
- Влияние на проект
- Риск, потери, возможности и выгоды, связанные с устранением или отказом от устранения дефекта.
- Даты наступления различных фаз жизненного цикла дефекта.
- Описание того, как был устранен дефект, и рекомендации по тестированию.
- Рекомендации
Заключение
Выше было приведено подробное руководство по жизненному циклу дефекта и его управлению.
Мы надеемся, что вы получили обширные знания о жизненном цикле бага, и это пособие, в свою очередь, упростит вам дальнейшую работу с дефектами.
Перевод статьи “What is Defect/Bug Life Cycle in Software Testing? Defect Life Cycle Tutorial”