Bug Databases - theory

Bug Databases - theory

Post by Eri » Thu, 17 Jul 2003 23:02:29



It seems pretty obvious to me that when entering bugs into a bug
database, that they should be single issue entries...i.e. if one found
multiple problems, each problem should be in a separate entry in the
database.

Is this obvious to everyone else here as well? If you disagree, I would
be interested in learning why.

--
== Eric Gorr ========= http://www.veryComputer.com/ ========= ICQ:9293199 ===
"Therefore the considerations of the intelligent always include both
benefit and harm." - Sun Tzu
== Insults, like *, are the last refuge of the incompetent... ===

 
 
 

Bug Databases - theory

Post by Tom Schulenbur » Fri, 18 Jul 2003 08:43:33



Quote:> It seems pretty obvious to me that when entering bugs into a bug
> database, that they should be single issue entries...i.e. if one found
> multiple problems, each problem should be in a separate entry in the
> database.

> Is this obvious to everyone else here as well? If you disagree, I would
> be interested in learning why.

I'll agree, but only if you're talking about bugs that will each require a
separate fix. If there are five typo's on a screen, don't enter 5 bugs,
enter one bug for the screen and list the typo's. If a calculation is wrong,
such as "xyz total", and it's displayed on multiple screens, don't enter a
bug for each screen that it's displayed on, enter a bug to fix "xyz total".
You should never combine bugs that have no relation - "Total is wrong and
link is broken", etc.

-T

 
 
 

Bug Databases - theory

Post by Wilhelm Steffe » Fri, 18 Jul 2003 15:55:57



> It seems pretty obvious to me that when entering bugs into a bug
> database, that they should be single issue entries...i.e. if one found
> multiple problems, each problem should be in a separate entry in the
> database.

> Is this obvious to everyone else here as well? If you disagree, I would
> be interested in learning why.

I agree if each bug corresponds to a separate fix. One bug can even lead
to more than one entry in the bug database if it turns out that it is
due to a combination of separate bugs in different subsystems, or if the
product has variants which require separate fixes. Alternatively a tree
structure where a problem entry splits into multiple solution entries,
one for each subsystem or variant, would be appropriate.

--
Dr. Wilhelm Steffen
SCHENCK PEGASUS GmbH

 
 
 

1. no theory in comp.db.theory?

I think the closest one would be comp.object.corba (to which this is cross
posted)

hm ... do you mean it's copied to several hosts, or do some hosts have
references to objects on other hosts, or is the state of the objects 'spread
out' over different hosts, or perhaps a combination  of all this? Sounds
tricky.

sure ... corba is just middleware. FYI, there is a group concerned with
CORBA and simulation; checkout http://www.mews.org/omg-sim/

                                                                      Philip

--

-----------------------------------------------------------------------------

+44 (0)1223 49 4639                 | Wellcome Trust Genome Campus, Hinxton
+44 (0)1223 49 4468 (fax)           | Cambridgeshire CB10 1SD,  GREAT BRITAIN
PGP fingerprint: E1 03 BF 80 94 61 B6 FC  50 3D 1F 64 40 75 FB 53

2. How DOES ASP.Net Render Buttons on NN6

3. comp.database, comp.databases, comp.databases.oracle, comp.databases.oracle.tools, comp.databases.oracle.misc, comp.databases.sybase, comp.databases.olap, comp.editors

4. typedef, templates, and "The C++ P.L."

5. Bugs, bugs, bugs...

6. keep losing connection between cable modem and pc

7. Bugs bugs and more bugs

8. Can not recieved attachements

9. Must all bugs be formally entered into database?

10. Bug tracking databases

11. known problem/bugs database.

12. Bug Tracker Database (recomend?)

13. Bug Reporting Database Software- What are you using?