Требования к тестировщику ч.8: дефекты и ошибки ПО

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

1. Что такое дефект и ошибка?

  • Дефект (Defect, Bug Report) – это документ, в котором описано неправильное поведение тестируемой системы или ПО. Не нужно путать дефект с ошибкой\багом. В терминологии тестирования ПО ошибка или баг - это непосредственно проблема ПО (например, ошибка в коде), а дефект - это описание данной проблемы.

2. Для чего необходимо описывать дефекты?

  • Описывая ошибку мы даем возможность другому человеку воспроизвести тот же результат и убедиться в наличии проблемы. Такое описание необходимо аналитикам, чтобы убедиться в том, что требования действительно не выполняются а также разработчикам, чтобы понять что и как им исправлять
  • Когда мы получаем исправленное ПО для повторной проверки, детальное описание ошибки дает возможность ничего не забыть и убедиться, что все действительно исправлено
  • Имея описание ошибки (даже уже исправленной ранее) мы можем повторно проверить, что она не повторяется в новой версии ПО. По такому принципу можно строить скоп регрессионного тестирования

3. Как формируется дефект и из чего он состоит?

  • Для описания дефектов могут использоваться как специализированные программы (Bugzilla, HP ALM, Redmine, JIRA и д.р.), так и обычные офисные приложения типа Excel, Word и даже Notepad. Вне зависимости от средств и систем для описания дефекта самым важным будет наличие основных параметров и полей, таких как (список основных атрибутов дефекта также приведен на схеме Шаблон типового дефекта):
    • Номер и краткое описание дефекта
    • Версия ПО и название модуля\компонента\приложения
    • Серьезность (Severity) и срочность (Priority) ошибки. На вопросе различия Severity и Priority остановимся немного подробнее, т.к. он очень часто возникает на собеседовании. В этом случае Severity – показывает насколько ошибка критична для работоспособности всей системы (например, Severity=Blocker), а Priority – говорить как быстро ошибку необходимо исправить с точки зрения планов проекта. Тут главное понимать и помнить, что высокая срочность не означает, что ошибка серьезная как и наоборот – серьезность не говорит, что дефект необходимо исправлять в первую очередь. Например, ошибка серьезная и блокирует часть функциональности новой системы, однако в ближайшем релизе мы не планируем выпускать этот функционал. В этом случае более срочным будет исправление ошибок в той части, которая войдет в релиз, пусть даже эти ошибки будут локальными и не такими значительными. Обычно используются следующие варианты серьезности и срочности:
      • Severity = Blocker, Critical, Major, Minor, Trivial
      • Priority = High, Medium, Low
    • Ссылка на требование, нарушение которого описано в дефекте
    • Автор дефекта, тот кто обнаружил и описал ошибку
    • Описание конфигурации и состояния системы, при котором удалось обнаружить ошибку
    • Детальное описание самой ошибки, которое состоит из:
      • Шагов по воспроизведению ошибки
      • Ожидаемого результата (в соответствии с требованиями)
      • Фактического результата, который мы наблюдаем
    • Дополнительным плюсом будут различные логи и скриншоты экрана, которые помогут увидеть, как проявилась ошибка. Любой разработчик точно скажет за это спасибо.

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

О проекте

  • Проведение тренингов и вебинаров: QA, Time management, People management, Agile
  • Консалтинг в области организации рабочих процессов в ИТ
  • Проведение и подготовка к собеседованиям

Информация об авторе проекта

 

Контакты

Skype: xpavnov

E-mail: xpavnov@gmail.com

VK: https://vk.com/doitsmartly

Группа вконтакте

doITsmartly©2024
Яндекс.Метрика

Search