Development teams that use Redmine for issue tracking eventually face the same problem when QA work grows: Redmine tracks bugs well, but it was not built to manage test cases. There is no test plan structure, no test run container, no pass/fail result per test case, and no direct link from a failed test case to the bug it created. As a result, QA teams work around this by writing test cases as issues, using custom fields to approximate results, and managing test coverage in spreadsheets alongside Redmine.
The result is two parallel systems Redmine for development work, a spreadsheet for QA that drift apart over time and give no one a clear picture of release readiness.
The Redmineflux Testcase Management Plugin adds structured test management directly inside Redmine. Test plans, test cases, test runs, and result tracking sit in the same system as your development issues. QA leads can link a failed test case to a bug issue in one action. Project managers can see test coverage and pass rates without leaving Redmine.
The short answer: Redmine does not have built-in test case management. Its issue tracker handles bug reporting and task tracking but has no test plan, test run, or pass/fail result structure. The Redmineflux Testcase Management Plugin is a dedicated Redmine testing plugin that adds structured test management to Redmine test plans, test case libraries, test run execution, pass/fail/blocked tracking, and bug linking within your existing Redmine instance.
Redmine’s issue tracker is flexible enough that some teams create a “Test Case” tracker type and use custom fields to record expected results, actual results, and test status. This approach works at small scale 20 to 50 test cases across one or two projects but breaks down as coverage grows. There is no aggregated pass rate, no run history, and no structured relationship between test cases and the versions being tested.
The Redmineflux Testcase Management Plugin introduces a dedicated test management layer to Redmine without replacing the issue tracker. Both systems issue tracking for development, test management for QA operate within the same Redmine instance and share the same projects, members, and versions.
The plugin adds a test case library to each project. Each test case includes:
Importantly, test cases in the library are reusable. The same test case can appear in multiple test plans and run across different versions. Updating a test case in the library applies the change to all future runs automatically.
A test plan groups a set of test cases for execution against a specific version or release. For a v2.4 release, the QA lead creates a test plan, selects the relevant test cases from the library, and assigns the plan to the version being tested.
In practice, test plans give project managers a clear scope: here are the test cases that must pass before this version ships. Before the plugin, teams typically managed this scope in a spreadsheet separate from Redmine.
When a QA engineer executes a test plan, the plugin creates a test run. Each test case in the run shows its current execution status:
During execution, the QA engineer updates each test case status. The plugin records the time and user for every result update. The plugin also retains the full test run history for any future reference.
When a test case fails, the QA engineer can create a Redmine bug issue directly from the failed test case record. The plugin pre-links the new issue to the test case, so the relationship between failure and bug is visible in both directions.
As a result, this removes a manual step that most teams forget linking bugs back to the test cases that found them and gives QA leads traceability from failure to resolution.
In addition, the plugin provides test run summary views showing:
Project managers use this to assess release readiness objectively. “87% pass rate, 4 critical fails remaining” is a clear release decision input. A spreadsheet with 200 rows of test case status does not give that at a glance. Redmine QA tracking becomes measurable rather than estimated pass rate data is live throughout the test run, not assembled manually after the fact.
Want to see test case management running inside a live Redmine instance? Book a Free Demo — the QA workflow from test plan to bug creation takes 30 minutes to walk through.
Managing test cases in Redmine with the plugin follows a four-step cycle that mirrors how QA teams already work:
This cycle replaces the spreadsheet layer that most teams use for test management in Redmine today. Every step happens inside Redmine visible to the project manager, linked to the development workflow, and stored as release history.
The QA lead creates a test plan for the upcoming version. They select all regression test cases plus any new cases for features added in this version. They assign the test plan to the version in Redmine.
The QA team executes the run over the testing period. Results update in real-time. Consequently, the project manager can check pass rate at any point without asking the QA lead for a status update.
When a test case fails, the QA engineer creates a bug issue directly from the failed case record. From there, the bug enters the Redmine issue tracker with a link back to the test case. Then, the development team picks up the bug through the normal issue workflow.
Once the fix is deployed, the QA engineer re-executes the failed test case. The status updates. Consequently, the test case links to both the original failure and the re-run pass.
The completed test run stays in the system as a record of what was tested and what passed for the version that shipped. If a regression is reported in production, the QA lead can check whether the affected area was covered in the release test plan and whether the test case was passing or absent.
For teams running sprints with the Redmineflux Agile Board Plugin, test case management connects to sprint delivery directly. The Testcase Management Plugin tracks QA work for a sprint’s issues. Furthermore, failed test cases generate bug issues that appear on the sprint board as new cards automatically.
The QA lead sees the test run summary for the sprint. Meanwhile, the project manager sees the sprint board. Both views draw from the same Redmine data the plugin stores test results against the version under test, and bug issues flow into the normal issue workflow.
No. Redmine does not have a built-in test plan, test run, or pass/fail result structure. Some teams use a custom issue tracker type to approximate test cases, but this approach lacks test run containers, pass rate reporting, and structured bug linking. The Redmineflux Testcase Management Plugin adds full test case management to Redmine.
Yes. The Testcase Management Plugin lets QA engineers create a Redmine bug issue directly from a failed test case. The new issue is pre-linked to the test case. The relationship is visible from both the issue and the test case record.
Yes. The library stores test cases at the project level, making them available for multiple test plans. Updating a test case applies the change to all future test plans. However, past test run records preserve the version of the test case the team executed at that time.
Yes. Each test case result update records the user who made the change and the timestamp. The test run history is fully auditable project managers and QA leads can see who marked each case as pass, fail, or blocked and when.
The Redmineflux Testcase Management Plugin supports Redmine 5.0.x, 5.1.x, and 6.0.x. Teams on earlier versions should contact support before purchasing to confirm compatibility.
QA work that lives outside Redmine is QA work that nobody can see in context. Test cases in spreadsheets cannot be linked to the bugs they found, cannot be traced to the version they covered, and cannot show a project manager the pass rate needed to make a release decision. SThe Testcase Management Plugin brings that work inside Redmine where the rest of the project already is.
Explore Managed Cloud — Redmine with all plugins pre-installed, including Testcase Management
