Redmine — система управления проектами и задачами, которая часто встречается в командах с собственным размещением и сложившимися процессами. QA использует её для дефектов, связей между задачами, версий и истории обсуждений. Польза здесь определяется не возрастом интерфейса, а качеством настроенного процесса. Даже простой трекер позволяет сохранить воспроизводимый дефект и подтверждённое исправление, если команда понимает назначение полей, допустимые переходы и правила поиска релизных рисков.
Что означает tracker в Redmine
Tracker определяет тип задачи: Bug, Feature, Support или другое настроенное значение. Это не отдельная система отслеживания, а характеристика issue внутри Redmine. Для tracker могут задаваться свой workflow, поля и начальное состояние. Issue также относится к проекту, может иметь категорию, приоритет, исполнителя и целевую версию. Конкретный набор зависит от установки. Если два проекта называют тип ошибки по-разному, общий отчёт должен учитывать это явно, иначе часть дефектов исчезнет из выборки.
Workflow зависит от роли и типа задачи
Допустимые переходы задаются для сочетания роли и tracker. Поэтому QA и разработчик могут видеть разные варианты смены состояния одной задачи. Отсутствующая кнопка не обязательно является дефектом Redmine: проверь роль, текущий статус и правила workflow. Дополнительно на переход влияют связанные ограничения, например блокирующие задачи. Не проси административные права ради обхода процесса; сначала выясни, какое действие должно быть разрешено конкретному участнику и зачем.
Закрытый статус и процент готовности
В Redmine статус может иметь признак закрытия. Значение 100% в поле готовности не следует автоматически считать подтверждением закрытого дефекта: расчёт процента настраивается отдельно. Для QA важно согласовать различие между «исправление реализовано» и «исправление проверено на нужной сборке». Если команда использует Resolved перед retest, это должно быть понятно по правилам проекта. Названия статусов сами по себе не объясняют, кто и на основании какого наблюдения их выставляет.
Репорт и история изменений
В описании дефекта сохрани исходные данные, сборку, окружение, шаги, ожидание и фактический результат. Последующие наблюдения добавляй в историю с коротким выводом: воспроизвелось на новой версии, изменилось условие, подтверждена причина. Не подменяй исходное описание исправленным сценарием так, чтобы пропала возможность понять первое наблюдение. Вложения называй содержательно и очищай от секретов. Для внешнего исполнителя заранее проверь доступ к задаче и необходимой диагностике, а не только наличие ссылки.
Практика: повторная отправка заявки
Есть сервис заявок и требование: двойное нажатие подтверждения не создаёт две записи. На тестовом стенде QA видит две заявки с одинаковым содержимым после быстрого повтора. Подготовлены тестовый пользователь, безопасное описание заявки и способ проверить список созданных объектов. Задача QA — зафиксировать дублирование, а после исправления проверить и интерфейс, и фактические записи.
- 1.Найди похожие issues в проекте по повторной отправке и дубликатам. Уточни, совпадают ли условия и наблюдаемые данные, прежде чем объявить проблему дублем.
- 2.Создай задачу нужного tracker и укажи две созданные записи, исходную сборку и минимальные шаги. Ожидается один объект при повторе согласно требованиям.
- 3.Согласуй приоритет, владельца и целевую версию. Если дефект блокирует приёмку, установи подходящую связь задач, а не только текст «блокирует» в комментарии.
- 4.После реализации дождись доступной сборки и повтори быстрый двойной submit, повтор после задержки и обновление страницы. Проверь число объектов через разрешённый источник данных.
- 5.Запиши фактический итог retest и версию. При повторном открытии приложи новые доказательства, сохранив историю первоначального исправления.
Запросы для ежедневной очереди
На странице issues собери фильтр по проекту, tracker дефектов, незакрытым статусам и целевой версии. Добавь исполнителя и сортировку по обновлению для очереди зависших задач. Сохрани запрос, если это позволяет ваша конфигурация и права. До передачи коллегам проверь его на известных примерах: свежий Bug, закрытая задача и дефект другого релиза должны попадать либо исключаться по понятной причине. Область подпроектов тоже важна: родительский проект может включать их задачи.
REST API и полная выгрузка
Redmine предоставляет API для issues. Для аудита полезны явные фильтры и пагинация; первый ответ не обязательно содержит все записи. Пример ниже показывает запрос первой страницы открытых задач проекта с числовым id=17. Адрес установки и credentials добавляются в используемом API-клиенте по правилам команды, а не публикуются в тексте запроса.
GET /issues.json?project_id=17&status_id=open&limit=100&offset=0Для полной истории нужны и закрытые задачи: в API status_id=* включает оба состояния. Увеличивай offset и сверяй метаданные выдачи, пока не получишь весь доступный набор. Права API-пользователя ограничивают результат; успешный ответ не доказывает, что видны приватные issues. Не сравнивай число задач двух пользователей без учёта доступа и фильтров.
Связи с задачами и изменениями кода
Используй отношения related, duplicate и blocks по их реальному смыслу. В Redmine некоторые связи влияют на поведение: закрытие основной задачи может закрывать дубли, а незакрытая блокирующая задача препятствовать завершению зависимой. Поэтому ошибочно выбранное отношение меняет больше, чем рисунок связей. При интеграции репозитория revisions помогают найти исправление, но наличие commit всё ещё не подтверждает развёртывание и retest. Отдельно указывай сборку, в которой QA проверил результат.
Расширения и особенности установки
Плагины могут добавлять доски, поля и интеграции, но инструкция по одному серверу не обязана работать на другом. Перед обновлением Redmine проверь совместимость важных расширений и критические сценарии процесса: создание Bug, переходы ролей, поиск, вложения и API-выгрузку. Не нужно тестировать всю административную панель ради одной привычной формы, но риск потери истории и доступа требует конкретных проверок на копии данных. Ожидания фиксируют до обновления, а не после неожиданного изменения поведения.
Типичные ошибки и практический вывод
Частые ошибки — путать tracker с проектом, считать 100% готовности результатом QA, выгружать только первую страницу API и закрывать задачу по наличию commit. Качественная работа в Redmine даёт понятный дефект, корректные связи, честную очередь незавершённой работы и проверенную сборку при закрытии. Система тогда поддерживает договорённости команды, даже если интерфейс выглядит проще современных альтернатив.