Redmine

In what way is this different than just creating a new tracker for "Requirement" and treating it like any other issue/feature/bug/etc? Any issue can be linked to any other, and to commits in the scm repository.

Personally I don't see this as any different than adding an issue as a "Feature".

We are setting up a set of wiki pages to deal with our requirements/specs./test cases/help pages/etc. We have a seperate project for each application. The idea is that if we make an enhancement we can update the wiki (nice now that we can lock the wiki) then create an issue to our testers by simpling pointing to the wiki. The tester can then update the issue with the test result including reassigning it to the developer if the test fails. The issues contain the testing and we have an updated wiki page to document the software. Our hotline can update the wiki to improve/enhance the documentation when they need to. In all it is making a useful tool instead of a book that we set on the shelf.

We currently testing all of this on a major application and so are streamline the format and structure but so far all of the responses are positive.

• How do you intend to check completeness of your testing for example, I mean generation of trace matrices between reqs and test cases ?
• How do you intend to manage your requirements under configuration (identifying the reason for evolution between 2 versions of your spec, for example) ?

The complement of Carl seems interesting too, but is it possible / practical to link from the wiki to the requirements being a kind of issue ? Personally, in a spec, I expect to see the content of the req : assuming content of the req is the description of the issue typed req, how can you display it in the wiki ? how the evolution is managed ?

May I "up" this very interesting subject?

Requirements could be a new tracker, but there is a little difference : requirements are not directly linked to a work. Requirements should be linked to tasks and to test cases.
To be able to manage all these aspects in one tool would be very useful, and not necessarily very difficult.

Requirements could be treated like issues (but on a separate page) without work load or planning aspects. We could have several types of requirements (screens, rules, ...), priorities (required, optional, ...) and we should be able to print a detailed list of all requirements (for customer approval for instance).
Probably a lot files to be attached (images, diagrams, ...).

Another page could allow test case creation and management (see TestLink for a good open source project regarding test cases and test plans), each test case linked to a requirement and/or to a bug/issue.

And of course, we keep the issue page, with the ability to link each issue to a requirement and/or a test case (bugs detected during tests).

That way, you can manage a project from the very beginning to the end. The ultimate project management tool! (see http://www.pragmaticsoftware.com/ for a tool that cover all these aspects).

A lot of work but a very big improvement!

This subject need much more than these few lines to be treated (and probably a better english...). But in my opinion, it worth a long debate!

I hope this could meet Redmine team ambitions, because I already appreciate this tool very much.
Just missing some QA aspects and I can definitively ignore all these complicated and expensive tools that emerged everywhere.

I wrote the requirement to achieve a similar function.

#732
(#443 Related function)

To have a complete management, some configuration management feature would be necessary I guess. Baseline of requirements need to be defined, justification for the modification of a requirement or a test case, ...
For UI point of view, it could be useful to define screens where all requirements and text around it (structuring the specification for example with titles and text) can be written at the same time, avoiding to many "clicks" and screen change.

The ideas are good and need to be work further I guess. Interface with other tools (like UML / SysML modeling tools) could be of value as well.

Isotrol RequMNGT Redmine Plugin manage requirement, use case, testcase, traceability, baseline concepts according to the OpenUP and CMMi metodology .

You can download it here:
http://forge.isotrol.org/projects/list_files/org00006-requmngt
http://www.isotrol.org

I'm about to start on a test case management plugin for redmine and would be interested in collaborating with a requirements management plugin. I'm actually thinking of a more agile-oriented acceptance & regression categorization of tests.

-Aaron Evans
aarone_at__one-shore.com

Yes, very interesting Aaron,

Have you a first prototype ? I can open a project in http://www.isotrol.org (redmine and subversion).

Nicolas

definitely interested in this. currently planning this out for a large opensource/ruby project, and looking at using testlink for test case management.

aaron - can you give a little clarification on what you're thinking? are you looking at writing the entire tcm within the context of a redmine pluging (presumably using a "test" issue?) or would there be a separate database for test cases?

definitely timely that you bring this up, based on the research i'm doing, there a decent amount of need for something like this.

I think it will be easier to have a separate test database and have Redmine access it through a simple API. There's potential for integrating it with other project management tools like Trac, but I think the structure will be influenced by the Redmine UI, at least at first.

It may be possible to use existing tools like TestLink on the back end, but I'm not going to tackle that at first -- going to keep it simple (I hope.) But if you're interested, we can work together and try to accomplish it. Interaction with different (web based) tools for bug tracking, etc. will hopefully be possible with links and (somewhat) RESTful APIs.

But my first goal is to enter text in redmine with a "test" label that has meta data that makes sense for my projects, with an eye towards functional test documentation & automation -- with inspiration drawn by Fitnesse and Cucumber, but from a QA rather than development centric perspective.

Nicolas-

I don't have a prototype or anything more than some general ideas and a desire to have a product that works the way I want.

I want to have something useful fairly quickly, that can be developed iteratively and not lose my testing data. I'm eager for any help, and hope to have something that meets the needs of the general public in the long term, but right now, I'm going to focus on learning how to write a Redmine plugin. I hope to have something very basic to look at within a few weeks.

After that, I might take you up on the offer of hosting, though github might be a better choice for SCM.

-Aaron

As a matter of fact, this topic is very interesting !

I'd love to see a requirements tracker added to Redmine.
Maybe, we should start from the bug tracker and build up.

Keep up the good work,
Bertrand.

FWIW I have some advice. I have been running SCM and release management for a small software organization for over ten years now. We are in the telecom/switch business and so are required to have very accurate bug tracking, testing, and long-term bug fixes on old releases. We are also small, and have no room for bureaucracy. The code tree includes a complete embedded Linux and the bug system has about 8,000 bugs to date.

some lessons learned:

1. above all, KISS. Do just enough to guarantee security, availability, and usefulness and no more.
2. Developers will only use a few features of a bug tracking system, and thats OK. Your job as SCM is to prevent them from spending time on SCM.
3. Upper management is too busy to have a clue, and thats just as well.
4. (applies to a non-consumer business I think) You must be able to tell exactly when and where a change went in the code and be able to pull it out in the future. If you can't do this, you may be writing too much or too complex code, but thats a design issue...

I don't have all the answers and every shop is different, but I have found I am much more likely to remove some permission-based rule or report than create one. Its better to have good engineers, and stay out of their way, than doing a lot of management.

anyway thats my input, if anyone wants to discuss it further.

John

John, I agree. Add complexity only when it's asked for, and then make it optional.

• TestRail - http://www.gurock.com/testrail/
• RequMNGT - http://forge.isotrol.org/wiki/org00006-requmngt
• RedCase - http://www.qaproject.net/?p=1

I've used TestRails - it is pretty nice and easy to use. The integration with Redmine is not what I expected. You are basically just adding your redmine url + bug # to a field in each test case. So when you click on the bug # it just redirects you to the bug on your redmine. It's not great, but it's not bad. It costs $$ though.

Have not used RequMNGT

Other people on my team have tried RedCase but said it is in a very alpha state, and there has been no updates so we abandoned trying to use that.

In my experience the process flow for defect tracking tools makes them a bad fit for tracking test cases. A defect has a life cycle from being opened to being closed. Testcases don't follow that same process. They get created and then executed. Each execution gives a unique result (e.g. passed, failed, etc). So you end up with this complex model of cases (and different versions of them) relating to multiple result records. This is why defect tracking tools don't work well as test management tools.

The alternative is to go for a dedicated test management tool that integrates with your defect tracking tool. In this way you get the best of both worlds. QA get the process flow in a tool that works well for them and dev get the process flow in a tool that fits their model. The trick is with picking the right integration tool. There are some interesting tools starting to develop out their now (for example OpsHub). With integration setup your QA team can create defects in their test management tool and that defect then gets sync'd up to the defect tracking tool like RedMine. Once created by the sync tool in Redmine the dev team can resolve the bug. That resolution can then be reflected back by the sync tool to the test management tool from where the QA team can create regression tests to confirm the fix.

This is a much neater solution than trying to get a defect management workflow to fit a test management workflow where both are essentially completely different. Talk to us at [[http://www.testmanagement.com]] if you'd like advice on integration solutions.

Checkout redmine_impasse it's a redmine plugin for test case managment and pretty does whyt you say, but fully intgrated into redmine. The community is growing, but the project needs developers to get the issues done. Fork and pull your ideas and extentions!

Have you seen this: http://redmine-re.korem.de/projects/redmine-re. Looks very good, but needs help in its stage of developement.