Собеседования

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

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. Жизненный цикл дефектов – это последовательность перехода дефекта между разными статусами и специалистами, которые с ним работают. Типичный жизненный цикл дефекта представлен на схеме Жизненный цикл дефекта.