Шаги для поддержания хорошей базы данных ошибок

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

• Дата выпуска время
• Кто назначен на
• Было ли это решено или нет
• Если решено, то решено время

Достаточно ли этого, чтобы поддерживать хорошую базу данных ошибок?

Хорошая база ошибок может иметь следующие

// Дата и время

• Дата выпуска, время ошибки
• Ожидаемая дата исправления / решения
• Если решено, то решено время

// Назначено + для

• Назначено (обнаружено)
• Назначено

// Ошибка поведения

• Наблюдаемое (глючное) поведение
• Снимок экрана (возможно)
• Выполните шаги, чтобы воспроизвести ошибку
• Ожидаемое поведение

// Приоритет

• Приоритет ошибки

// Ссылка, статус и другие

• Ссылка связанных ошибок
• Статус ошибки
• Было ли это решено или нет
• Если решено, то как решено с объяснением

РЕДАКТИРОВАТЬ: я также хочу рекомендовать

• В какой ревизии / ветке была обнаружена ошибка
• В какой ревизии / ветке исправлена ​​ошибка

РЕДАКТИРОВАТЬ: Мне нравится комментарий @ jgauffin

• Не исправить, Не ошибка, Дублировать, Решено

РЕДАКТИРОВАТЬ: хорошая система базы данных ошибок также поддерживает

• Матрица распределения ответственности

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

• Проблема DateTimeОшибка / Дефект
• Описание ошибки - шаги по воссозданию.
• Среда, в которой он обнаружен (Dev, QA, QC, Staging, Prod)
• Снимок экрана с вопросом
• Кто это регистрировал (обнаружил)
• Кому это назначено (назначено)
• Серьезность ошибки (низкая, средняя, ​​высокая)
• Ожидаемое разрешение DateTime
• Государственная сортировка (предложено, в процессе, решено, закрыто)
• Ошибка закрыта DateTime- когда ошибка устранена и закрыта
• Назначено для тестирования (проверено)

Редактировать: Большинство распространенной информации, которая имеет значение для отслеживания, хорошо описаны в таких программах, как Bugzilla . Bugzilla - это веб-инструмент для отслеживания ошибок общего назначения и тестирования, изначально разработанный и используемый в проекте Mozilla и лицензированный в рамках общественной лицензии Mozilla, - и БЕСПЛАТНЫЙ . Я настоятельно рекомендую взять их в качестве основного примера и распространить его на потребности вашего проекта.

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

• В какой ревизии / ветке была обнаружена ошибка.
• В какой ревизии / ветке это было исправлено.

Это немного более конкретно, чем в какой день / время ошибка была обнаружена / исправлена.

Если ваше программное обеспечение работает на нескольких платформах (ОС или оборудовании), вам также может понадобиться поле, в котором перечислены платформы, на которых возникает ошибка.

Но это не только поддержка базы данных ошибок, чем те поля, которые она должна содержать. Вы также должны рассмотреть, как вы используете базу.

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

Вам часто нужно видеть историю ошибки - она ​​может быть устранена, затем вновь открыта, затем решена снова и т. Д. Итак, в дополнение к тому, что уже было предложено, я бы посоветовала вам иметь отдельную таблицу для отслеживания истории ошибки каждый раз, когда она (повторно) открывается. Таблица будет иметь отношение многие к одному с таблицей ошибок и, вероятно, будет иметь такие поля, как:

• Дата открытия
• Открыт
• Дата решения
• Решено
• Проведенное время
• Как было решено
• и т.п.

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

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

Процесс отслеживания ошибок так же важен, как и данные. Попробуйте также подумать о следующем:

• Как пользователи сообщают об ошибке?
• Кто вводит ошибку в хранилище?
• Кто может подтвердить, что ошибка существует?
• Кто может подтвердить, что ошибка устранена?
• Кто сообщает конечному пользователю, что ошибка устранена?

Создайте диаграмму RACI, чтобы все в вашей команде (включая конечных пользователей знали свои обязанности). Объедините это с правильными методами ввода данных, и вы увидите гораздо больше пользы при небольших дополнительных усилиях.