what should be bug to testcase relation

Lee Ivy lee at netzentry.com
Mon Oct 18 04:45:18 UTC 2004

I agree with Gervase that there are cases where you see either several bugs
from 1 test case, or several test cases for 1 bug. However, if a
many-to-many relationship will create a lot of extra complexity, my advice
to Prasad would be to ask your users what query operations are most
important to them.

In my experience running QA groups, it's very important to answer the
question, "What is the status of the bug(s) for this test case?" (usually
this is implemented as a query to the test case database) -- but it is less
common for someone to ask, "What are all the test cases associated with this
bug?". So if you are under pressure to deliver a solution quickly, you may
want to try simplifying your problem a bit -- perhaps you could get away
with supporting a single test case per bug, but be sure to allow multiple
bugs per test case.

If my experience is not typical, I'm sure the kind people in the group will
not be shy about providing a different view.


----- Original Message ----- 
From: "Gervase Markham" <gerv at mozilla.org>
To: <developers at bugzilla.org>
Cc: <kprasad at vyomlabs.com>
Sent: Sunday, October 17, 2004 5:55 AM
Subject: Re: what should be bug to testcase relation

> prasad kadbane wrote:
> >         I am a perl developer and I working on project
> > which support testcase management system and bug
> > tracking  system. I also know the bugzilla well. I am
> > confused about what should be the test case to bug
> > relation Is it one-to-one or one-to-many or
> > many-to-many. Some experts says that it should be one
> > to many ie one test case can have one or many bugs.
> >     Please help about relation and tell me what is standerd.
> I would suggest that one bug can certainly have multiple testcases, and
> one testcase can sometimes refer to multiple bugs. So it's many-to-many.
> Gerv
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=lee@netzentry.com>

More information about the developers mailing list