Jeff,
I am very mindful about how tools should be used and employed, especially
using the right tool for the job. What I am going to do is write a basic
list how we use mantis in our organisation, including some of the changes I
asked the list about. I also ask the list if it would be a good idea for me
to create a document in great detail explaining the use of mantis and some
suggested uses of certain areas?
We use a wiki to create our requirements using comments and review dates to
drive the changes.
Test Link will be used to manage test plans. I would strongly recommend
reviewing this tool.
Firstly we track issues logged by the test team. This is rather simple.
The can attach screen shots and shortly will be able to populate the
reproduction steps with information directly from a test script in another
open source application called TestLink (http://www.teamst.org) . Issues
raised here run the normal lifecycle from new to closed. I intend to add a
status yet to be named between resolved and closed to ensure that any
documentation as a result of a bug gets completed before a bug (or feature)
is fully closed.
Secondly we track issues logged by support and customers which follows the
same rules as above.
As you can see Jeff, we don't use mantis to track our requirements or test
plans, however, if you were to do this I could suggest the following;
Use categories, among others, called 'Requirements' and 'Test Plan'. When
there is a requirement for review, a new issue is created with the category
of 'Requirements' and any other necessary information for your company, such
as assigning it to the person to review, attaching the requirement and the
priority etc. and with the status of 'new'. When the person reviewing the
requirements picks up the issue they could assign it to themselves, status
becomes ' assigned'. If the person reviewing the requirements finds an
error they can assign it back to the author with a status of 'feedback' who
fixes the issue and uploads the new document and sends it back for review.
If it passes review then it can either be resolved or closed. The above can
also be done with the use of a 'developer' called 'requirements pool' for
example where all new requirements are loaded into a pool and the reviewers
pick them off a list by priority -this list can be easily viewed by use of
the filters. E.g. View All New issues assigned to 'requirements pool'
sorted by priority. Remember that mantis has the ability to predefine and
save filters to make this easy.
The important thing here Jeff, is to make sure that your work flow fits in
with the status and assignments. Have a good look at the reports (making
sure jpgraph is installed and working) as this will also give you an
indication of what information you can get at the click of a link.
Be sure to understand the status' and resolution codes. As this will affect
the reports.
I have learn't that they key to making mantis work for you is to understand
fully the workflow of both mantis and your company.
Good luck Jeff, and if you have any more questions, I'll be glad to give you
as much information as I can. Mantis is a great tool, enjoy!
Shawn
On 4/28/07, Garlitz, Jeffrey D <[EMAIL PROTECTED]> wrote:
Shawn,
I am a new user of Mantis and plan to also use the tool to track
issues identified during reviews of requirements and test plans that
need to be addressed by someone following the review. Can you tell me
which functions you use in Mantis to do your tracking?
Jeff Garlitz
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Gerhard Fiedler
Sent: Friday, April 27, 2007 10:58 AM
To: mantisbt-help@lists.sourceforge.net
Subject: Re: [mantisbt-help] Correct Use of Mantis
Shawn Hill wrote:
> Mantis is a bug tracker. Features aren't bugs.
Just on this one... Mantis can be seen as an issue tracker :) Features
are
issues, issues are issues, ...
We use Mantis to track all kinds of issues; anything that needs to be
done
or needs a decision or a resolution or a review or ... at a later point
in
time or by someone else.
We don't include documentation in the workflow, we either report a new
issue if documentation has to be changed, or assign the issue with an
appropriate comment to the one who should write it. (We don't use it in
a
very formalized manner :)
Gerhard
------------------------------------------------------------------------
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
mantisbt-help mailing list
mantisbt-help@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mantisbt-help
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
mantisbt-help mailing list
mantisbt-help@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mantisbt-help
--
[EMAIL PROTECTED]
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
mantisbt-help mailing list
mantisbt-help@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mantisbt-help
