Бесплатная консультация юриста

+7 (800) 301-07-30

Реклама jurik.ru

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

Что такое дефектная ведомость?

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

уникальный идентификатор дефекта;
краткое описание проблемы;
шаги воспроизведения;
ожидаемый и фактический результат;
серьёзность (severity) и приоритет (priority);
ответственный за исправление;
текущий статус (новый, в работе, закрыт и т.д.);

Зачем нужна дефектная ведомость?

Основные цели документа:

Контроль качества. Позволяет отслеживать количество и типы ошибок.
Коммуникация. Обеспечивает прозрачность между разработчиками, тестировщиками и руководством.
Аналитика. На основе данных можно проводить ретроспективы и улучшать процессы.
Отчётность. Упрощает подготовку отчетов для заказчиков и аудита.

Основные элементы дефектной ведомости

Поле	Описание	Пример
ID	Уникальный номер дефекта	DEF‑2026‑001
Название	Краткое название проблемы	«Ошибка при сохранении формы»
Описание	Подробное описание дефекта	При попытке сохранить форму с полем «Электронная почта» без символа «@» система выдает сообщение «Ошибка сервера».
Шаги воспроизведения	Последовательность действий, приводящих к ошибке	Открыть форму. Ввести «testexample.com» в поле e‑mail. Нажать «Сохранить».
Ожидаемый результат	Что должно произойти	Показать валидацию «Введите корректный e‑mail».
Фактический результат	Что произошло на самом деле	Отображается «Ошибка сервера».
Severity	Степень влияния на работу системы	Средняя
Priority	Необходимость исправления в текущем спринте	Высокий
Ответственный	Разработчик/команда, отвечающая за исправление	Иванов И.И.
Статус	Текущее состояние дефекта	В работе
Когда дефект был зафиксирован	2026‑04‑15
Дата закрытия	Когда дефект был исправлен и проверен	—

Пошаговое создание дефектной ведомости

Шаг 1. Подготовка

Определите, в какой системе будет вестись учёт (Excel, Google Sheets, Jira, Redmine, Azure DevOps и т.п.).
Согласуйте набор полей с командой, чтобы каждый понимал, что и как заполнять.
Создайте шаблон (см. пример таблицы выше) и разместите его в общем доступе.

Шаг 2. Сбор информации

Тестировщик или любой член команды обнаруживает ошибку.
Заполняет все обязательные поля: название, описание, шаги воспроизведения, severity, priority.
При необходимости прикладывает скриншот, лог‑файл или видео (можно добавить ссылку на Google Drive).

Шаг 3. Оформление

В зависимости от выбранного инструмента оформление может различаться:

Excel/Google Sheets. Заполняете строки таблицы, используете выпадающие списки для полей Severity и Priority.
Трекер задач (Jira, Redmine). Создаёте задачу типа «Bug», выбираете шаблон «Defect», заполняете форму.

Шаг 4. Проверка и подтверждение

Тестировщик проверяет корректность заполнения и ставит статус «Новый».
Ответственный разработчик меняет статус на «В работе» и начинает исправление.
После исправления тестировщик проверяет исправление и переводит статус в «Закрыт» (или «Требует повторного теста»).

Шаг 5. Аналитика и отчётность

Регулярно (еженедельно, в конце спринта) формируйте отчёты:

Общее количество открытых/закрытых дефектов.
Распределение по severity и priority.
Среднее время исправления (MTTR).

Эти данные помогают управлять качеством и планировать ресурсы.

Полезные рекомендации и лайфхаки

Единый язык. Используйте одинаковую терминологию во всех полях (например, «Серьёзность» вместо «Важность»).
Выпадающие списки. Для полей Severity и Priority задайте фиксированный набор значений (Critical, High, Medium, Low).
Автоматизация. При работе в Google Sheets можно подключить Google Apps Script для автоматической генерации уникального ID и отправки уведомлений по e‑mail.
Связывание с требованиями. Указывайте номер требования или пользовательской истории, к которой относится дефект (например, REQ‑1234).
Контроль доступа. Оставьте права редактировать только тестировщикам и разработчикам, а остальные могут только просматривать.
Регулярные ревью. Проводите совместные встречи (bug triage) раз в 2–3 дня, чтобы согласовать приоритеты и распределить задачи.

Часто встречающиеся ошибки при заполнении ведомости

Недостаточная информация. Пропуск шагов воспроизведения делает дефект «не воспроизводимым».
Неправильный приоритет. Слишком низкий приоритет для критической ошибки замедляет её исправление.
Отсутствие скриншотов/логов. Без доказательств разработчик тратит время на уточнение.
Дублирование. Перед созданием нового дефекта проверяйте, нет ли уже аналогичной записи.
Необновлённый статус. Оставление дефекта в статусе «В работе» после закрытия приводит к путанице.

Пример готовой дефектной ведомости в Google Sheets

Ниже представлена ссылка на готовый шаблон, который можно скопировать в свой аккаунт:

Шаблон дефектной ведомости (Google Sheets)

Создание и поддержание дефектной ведомости – один из фундаментальных процессов в любой команде, занимающейся разработкой программного обеспечения. Чётко структурированный документ ускоряет поиск и исправление ошибок, повышает прозрачность работы и позволяет проводить аналитические оценки качества продукта. Следуйте описанным шагам, используйте предложенный шаблон и не забывайте о регулярных ревью – и ваша команда будет уверенно двигаться к цели без лишних «скрытых» багов.

Дата публикации: