Процесс управления дефектами при тестировании программного обеспечения
Томас Гамильтон
⚡ Умное резюме
Процесс управления дефектами в тестировании программного обеспечения — это структурированная система для выявления, классификации, устранения, проверки, закрытия и сообщения об ошибках. Он обеспечивает предсказуемое взаимодействие между тестировщиками и разработчиками, повышает качество выпуска и снижает количество ошибок на этапе разработки на протяжении всего жизненного цикла проекта.
Что такое процесс управления дефектами?
Процесс управления дефектами Это систематический подход, используемый в тестировании программного обеспечения для выявления, классификации, исправления и проверки ошибок до выпуска программного обеспечения. Жизненный цикл включает шесть основных этапов: 1) Обнаружение дефекта, 2) Категоризация, 3) Устранение разработчиками, 4) Проверка тестировщиками, 5) Закрытие и 6) Сообщение о дефекте в конце проекта.
В этой статье объясняется, как применять процесс управления дефектами с помощью... GuruПример веб-сайта банка «99», чтобы начинающие и опытные тестировщики могли понять каждый шаг в контексте реального проекта.
Зачем вам нужен процесс управления дефектами?
Представьте, что ваша команда обнаружила несколько ошибок во время тестирования. Guru99. Банковский проект. Без структурированного процесса общение между тестировщиками и разработчиками происходит устно или посредством разрозненных сообщений.
Неделю спустя разработчик отвечает, излагая иное понимание проблемы.
На следующей неделе тестировщик снова отвечает, что еще больше сбивает с толку.
Когда информация о дефектах передается устно или неформально, ситуация очень быстро усложняется. Для контроля и эффективного управления ошибками необходим четко определенный жизненный цикл дефектов, который стандартизирует способы отчетности команд. track и закрыть вопросы.
Шаг 1) Открытие
В Дискавери На этом этапе проектная группа должна выявить как можно больше дефектов до того, как с ними столкнется конечный клиент. Дефект считается «обнаруженным», как только он подтвержден и принят командой разработчиков, после чего его статус меняется на Принятый.
В приведенном примере тестировщики обнаружили 84 дефекта. GuruВеб-сайт банка «99».
Однако тестировщики и разработчики не всегда приходят к согласию. Рассмотрим следующий случай, в котором команда тестирования выявляет проблемы в GuruНа сайте 99 Bank размещены сообщения об этих ошибках, но команда разработчиков оспаривает утверждение, что это дефекты:
В таком случае, что должен делать менеджер по тестированию?
А) Согласиться с группой тестирования в том, что это дефект.
Б) Выступите в роли судьи и решите, является ли проблема дефектом или нет.
C) Согласиться с командой разработчиков в том, что это не является дефектом.
Правильный подход — вариант B. Для разрешения конфликта следует применить процедуру урегулирования, и менеджер по тестированию должен беспристрастно оценить проблему, прежде чем решить, квалифицируется ли она как дефект.
Шаг 2) Категоризация
Классификация дефектов помогает разработчикам расставлять приоритеты в работе, чтобы в первую очередь устранялись наиболее важные для бизнеса проблемы. Классификация обычно выполняется менеджером по тестированию и основывается на степени серьезности и влиянии на бизнес.
Дефекты обычно подразделяются на четыре уровня приоритета: Критический, высокий, средний и низкийПопробуйте присвоить каждому из следующих дефектов правильный приоритет:
- Сайт работает слишком медленно.
- Функция авторизации на сайте работает некорректно.
- Графический интерфейс веб-сайта отображается некорректно. мобильный устройств.
- Веб-сайт не может запомнить сессию входа пользователя.
- Некоторые ссылки не работают.
Вот рекомендуемые ответы:
| № | Описание | приоритет | объяснение |
|---|---|---|---|
| 1 | Работа сайта слишком медленная | Высокий | Проблемы с производительностью доставляют значительные неудобства конечным пользователям. |
| 2 | Функция авторизации работает некорректно. | критический | Вход в систему — ключевая функция банковского сайта. Если он не удается, весь пользовательский опыт блокируется. |
| 3 | Графический интерфейс пользователя отображается некорректно на мобильных устройствах. | Средний | Данная ошибка затрагивает пользователей, просматривающих веб-сайт на смартфонах. |
| 4 | Веб-сайт не может запомнить сессию входа пользователя. | Высокий | Пользователи могут войти в систему, но не могут совершать дальнейшие транзакции. |
| 5 | Некоторые ссылки не работают | Низкий | Разработчикам это легко исправить, и пользователи по-прежнему смогут получить доступ к остальной части сайта. |
Шаг 3) Разрешение дефектов
Разрешение дефектов В тестировании программного обеспечения исправление дефектов — это поэтапный процесс. Процесс устранения начинается с назначения дефектов разработчикам, которые затем планируют исправления в соответствии с приоритетом, внедряют исправления и, наконец, отправляют отчет об устранении дефектов обратно менеджеру по тестированию. Эта последовательность позволяет устранить дефекты. tracКороль прозрачен и подотчетен.
Для устранения неисправности выполните следующие действия:
- Назначение: Дефект передается разработчику или техническому специалисту, и его статус изменяется на Реагирование.
- Исправление расписания: Команда разработчиков берет на себя задачу по исправлению ошибок и составляет график их устранения в зависимости от приоритета дефектов.
- Исправьте дефект: Пока разработчики исправляют ошибки, менеджер по тестированию tracпрогресс по сравнению с запланированным графиком.
- Сообщить о решении: Разработчики отправляют отчет, подтверждающий, какие дефекты были исправлены и как.
Шаг 4) Проверка
После того, как команда разработчиков фиксированной и сообщал дефекты, команда тестирования проверяет что проблемы решены.
Например, когда команда разработчиков сообщает об исправлении 61 дефекта, команда тестирования повторно проверяет каждый из них, чтобы подтвердить, корректно ли работают исправления в тех же условиях, которые вызвали первоначальную ошибку.
Шаг 5) Закрытие
После устранения и проверки дефекта его статус изменяется на закрытоЕсли дефект не будет должным образом устранен в процессе проверки, необходимо отправить уведомление команде разработчиков для повторного расследования. Закрытие означает, что дефект больше не активен в системе.
Шаг 6) Отчет о дефектах
Отчет о дефектах В тестировании программного обеспечения отчет о дефектах — это процесс, в ходе которого менеджеры по тестированию составляют отчет и сообщают о статусе дефектов команде управления. Команда управления рассматривает отчет и предоставляет обратную связь или дополнительную поддержку, если это необходимо. Сообщение о дефектах улучшает коммуникацию. tracкороль и видимость дефектов.
Руководство имеет право знать о состоянии дефектов для эффективной поддержки проекта. Поэтому необходимо регулярно отчитываться о текущей ситуации с дефектами, чтобы иметь возможность предоставлять рекомендации и ресурсы.
Важные показатели дефектов
Возвращаясь к исходному сценарию, команды разработчиков и тестировщиков совместно анализируют дефекты. Сводные результаты представлены ниже.
Как можно измерить и оценить качество выполнения тестов?
Это критически важный вопрос каждый Test Manager хочет ответить. Обычно используются два ключевых параметра:
В описанном выше сценарии, Коэффициент отклонения дефектов (DRR) вычисляется как 20/84 = 0.238 (23.8%).
В качестве другого примера предположим, что GuruНа сайте 99 Bank в общей сложности содержится следующее: 64 дефекты, но группа тестирования обнаруживает только 44 - значение 20 Дефекты были пропущены. Коэффициент утечки дефектов (DLR) вычисляется как 20/64 = 0.312 (31.2%).
В итоге, качество выполнения тестов оценивается с помощью двух параметров, указанных ниже:
Чем меньше значения DRR и DLR, тем выше качество выполнения тестов. Допустимый диапазон обычно определяется целевыми показателями проекта или сравнивается с аналогичными проектами. В этом примере рекомендуемый допустимый диапазон составляет: от 5% до 10%Текущее выполнение выходит за пределы этого диапазона, что указывает на необходимость улучшения качества тестирования с помощью следующих мер:
- Совершенствовать навыки тестирования членов команды.
- Проводи больше времени при выполнении тестов, особенно при анализе результатов выполнения.
Лучшие практики эффективного управления дефектами
Следование структурированным передовым практикам отличает зрелый процесс управления дефектами от хаотичного. Цель состоит не просто в исправлении ошибок, а в создании системы, которая предотвращает их проникновение в рабочую среду и минимизирует сбои в коммуникации между тестировщиками и разработчиками.
Вот лучшие практики, которые начинающим и опытным тестировщикам следует внедрить прямо сейчас:
- Стандартизируйте шаблон описания дефекта: Используйте фиксированный шаблон отчета о дефекте, содержащий такие поля, как идентификатор дефекта. Description, Шаги воспроизведения, Серьезность, Приоритет, Окружение и Вложения. Последовательность действий сокращает обмен информацией между тестировщиками и разработчиками.
- Перед назначением задач определите приоритеты: Перед отправкой разработчикам всегда классифицируйте дефекты по степени серьезности и приоритету. Это гарантирует, что критические проблемы не останутся позади косметических.
- Перед отправкой отчета воспроизведите проблему: Перед тем как сообщать о дефекте, необходимо как минимум дважды воспроизвести его в чистой среде. Воспроизводимые дефекты устраняются быстрее и снижают процент брака.
- Принять дефект tracглавный инструмент: Используйте такие инструменты, как JIRA, Bugzilla или Богомол централизовать tracкороль, история и репортажи.
- Проведение совещаний по сортировке пациентов: Проводите короткие, целенаправленные совещания по анализу дефектов для согласования приоритетов между командами контроля качества, разработки и создания продукта.
- Измерение утечек и брака: Track DLR и DRR в каждом спринте или цикле. Рост уровня утечки является ранним предупреждением о неполном тестовом покрытии.
- Проведите анализ первопричин: В случае повторяющихся или серьезных дефектов проведите анализ первопричин, чтобы предотвратить повторное возникновение ошибок того же класса в будущих релизах.
- Завершите цикл отчетности: Предоставляйте заинтересованным сторонам еженедельные отчеты об обнаруженных дефектах, чтобы проблемы оставались видимыми и позволяли принимать необходимые меры.
При последовательном применении эти методы стабилизируют жизненный цикл дефектов и повышают общее качество каждого релиза.
Ресурсы:
Загрузите образец шаблона отчета о дефектах
