Redmine is a project and issue management system often found in teams with self-hosted infrastructure and established processes. QA uses it for defects, issue relationships, versions, and discussion history. Its value depends on the quality of the configured process, rather than the age of its interface. Even a simple tracker can preserve a reproducible defect and a verified fix when the team understands field purposes, permitted transitions, and how to find release risks.
What a tracker means in Redmine
A tracker defines the issue type: Bug, Feature, Support, or another configured value. It is a property of an issue within Redmine, rather than a separate tracking system. A tracker can have its own workflow, fields, and initial state. An issue also belongs to a project and may have a category, priority, assignee, and target version. The exact set depends on the installation. If two projects use different names for defects, a shared report must account for that explicitly, or some defects will be missing from the results.
Workflows depend on roles and issue types
Allowed transitions are configured for each combination of role and tracker. QA and developers may therefore see different status options for the same issue. A missing button is not necessarily a Redmine defect: check the role, current status, and workflow rules. Related restrictions, such as blocking issues, can also affect transitions. Do not request administrator access to bypass the process; first establish which action the participant should be allowed to perform and why.
Closed statuses and percentage complete
A Redmine status can be marked as closed. A value of 100% in the completion field should not automatically be treated as confirmation that a defect is closed: percentage calculation is configured separately. QA needs an agreed distinction between "the fix is implemented" and "the fix has been verified in the required build." If the team uses Resolved before retesting, the project rules should make that clear. Status names alone do not explain who sets them or on what evidence.
Reports and change history
Record the original data, build, environment, steps, expected result, and actual result in the defect description. Add subsequent observations to the history with a brief conclusion: reproduced in a new version, conditions changed, or cause confirmed. Avoid rewriting the original description so extensively that the initial observation can no longer be understood. Give attachments meaningful names and remove secrets. For an external contributor, verify access to the issue and necessary diagnostics in advance; having a link is not enough.
Exercise: submitting a request twice
A request management service has a requirement: double-clicking confirmation must not create two records. In the test environment, QA sees two requests with identical contents after a quick repeat. A test user, a safe request description, and a way to inspect the created objects are available. QA needs to document the duplication and, after the fix, check both the interface and the actual records.
- 1.Search the project for similar issues involving repeated submissions and duplicates. Compare the conditions and observed data before marking the problem as a duplicate.
- 2.Create an issue with the appropriate tracker, identifying the two created records, original build, and minimum steps. According to the requirements, repeating the action should produce one object.
- 3.Agree on priority, owner, and target version. If the defect blocks acceptance, create the appropriate issue relationship instead of only writing "blocks" in a comment.
- 4.Once the fix is implemented and a build is available, repeat a rapid double submission, a repeat after a delay, and a page reload. Check the number of objects using an authorized data source.
- 5.Record the actual retest result and version. If reopening the issue, attach new evidence while preserving the history of the original fix.
Queries for the daily queue
On the issues page, filter by project, defect tracker, open statuses, and target version. Add the assignee and sort by update time to build a queue of stalled issues. Save the query if your configuration and permissions allow it. Before sharing it with colleagues, test it against known examples: a new Bug, a closed issue, and a defect from another release should be included or excluded for clear reasons. Subproject scope also matters: a parent project may include its subprojects' issues.
REST API and complete exports
Redmine provides an issues API. Explicit filters and pagination are useful for audits; the first response does not necessarily contain all records. The example below requests the first page of open issues for the project with numeric id=17. Configure the installation address and credentials in your API client according to team rules, rather than publishing them in the request text.
GET /issues.json?project_id=17&status_id=open&limit=100&offset=0A complete history also requires closed issues: status_id=* includes both states in the API. Increase offset and check the response metadata until you have the entire accessible set. The API user's permissions limit the results; a successful response does not prove that private issues are visible. Account for access and filters when comparing issue counts between two users.
Relationships with issues and code changes
Use related, duplicate, and blocks relationships according to their actual meanings. Some Redmine relationships affect behavior: closing the main issue may close its duplicates, while an open blocking issue may prevent a dependent issue from being completed. An incorrect relationship therefore changes more than the relationship diagram. With repository integration, revisions help locate a fix, but a commit still does not confirm deployment or retesting. Identify the build in which QA verified the result separately.
Extensions and installation differences
Plugins can add boards, fields, and integrations, but instructions for one server may not work on another. Before updating Redmine, check the compatibility of important extensions and critical process scenarios: creating a Bug, role transitions, search, attachments, and API exports. Testing the entire administration panel for one familiar form is unnecessary, but the risk of losing history or access calls for specific checks on a data copy. Define expectations before the update, rather than after an unexpected behavior change.
Common mistakes and practical takeaways
Common mistakes include confusing a tracker with a project, treating 100% completion as QA verification, exporting only the first API page, and closing an issue because a commit exists. Good Redmine practice produces a clear defect report, correct relationships, an accurate queue of unfinished work, and a verified build when an issue closes. The system then supports team agreements even if its interface looks simpler than modern alternatives.