The online community for software testing & quality assurance professionals
 
 
Calendar   Today's Topics
Sponsors:




Lost Password?

Home
BetaSoft
Blogs
Jobs
Training
News
Links
Downloads



Quality Engineering >> Defect Tracking

Pages: 1
AmitK
Member


Reged: 12/23/01
Posts: 75
Attributes of a Defect (Bug)
      #228184 - 01/15/02 10:07 PM

I am trying to find Attributes of a Defect (Bug). I have found some, & some are missing. What are those?
Please help!!!

Attributes of a Defect (Bug):

1. Type (Functionality, UI, etc)
2. Priority
3. Severity
4. Product (Module)
5. Component (Part of that module)
6. Version Entered
7. Version Fixed
8. Reproducible (Always, sometimes, etc)
9. Operating System
10. Description about Bug/Defect
11. Steps to reproduce

Thanks,
AmitK

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


Post Extras: Print Post   Remind Me!   Notify Moderator  
colin g
Advanced Member


Reged: 08/15/00
Posts: 522
Loc: Livingston (Scotland)
Re: Attributes of a Defect (Bug)
      #228185 - 01/16/02 01:59 AM

You might also want to add:

Detected Date
Detected By
Phase Detected
Assigned To
Build Number

eh, if i think of anymore i'll add them later...

------------------
Hope this helps.

Regards,
Colin.


Post Extras: Print Post   Remind Me!   Notify Moderator  
Jules
Member


Reged: 03/15/01
Posts: 484
Loc: UK
Re: Attributes of a Defect (Bug)
      #228186 - 01/16/02 03:27 AM

Presumably you mean:

'Attributes of a bug that should be included in a bug report' ?

In my opinion this should be in several lists

1) Essential (i.e. if you can't list these in an interview I ain't giving you a job!)
2) Useful
3) Nice to know but usually useless
4) Stuff that people mistakenly think is required but is actually useless and just takes up extra time.

and P.S, we have different projects within the same company that would give you different answers for the above. The question must be answered for your situation. There is no universal or general answer.

Good luck.

Jules

------------------
Softly, Softly catchee monkey...


Post Extras: Print Post   Remind Me!   Notify Moderator  
JRica
Advanced Member


Reged: 12/05/00
Posts: 536
Loc: Basking Ridge, NJ USA
Re: Attributes of a Defect (Bug)
      #228187 - 01/16/02 06:25 AM

You'll eventually need to assign an Owner, to fill in the following information once the defect is repaired:

Owner
Repair Date
Repair Build
Component(s) Repaired
Time to Fix (if you want to collect metrics)

------------------
JRica, CSTE
Software QA Engineer Lead


Post Extras: Print Post   Remind Me!   Notify Moderator  
Charles Reace
Moderator


Reged: 05/03/01
Posts: 2498
Loc: Ankh-Morpork
Re: Attributes of a Defect (Bug)
      #228188 - 01/16/02 06:52 AM

Some sort of Title or Brief Description field is useful to provide a one-line description which can be used on summary reports and such.

------------------
Charles Reace

charles{DOT}reace{AT}verizon{DOT}net

Post Extras: Print Post   Remind Me!   Notify Moderator  
gsh
Unregistered




Re: Attributes of a Defect (Bug)
      #228189 - 01/16/02 08:14 AM

A bug should also have a unique identifying number to differentiate it from the other bugs in the database.

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


Post Extras: Print Post   Remind Me!   Notify Moderator  
JCTreb
Active Member


Reged: 08/16/01
Posts: 789
Loc: Minneapolis, MN
Re: Attributes of a Defect (Bug)
      #228190 - 01/16/02 08:27 AM

The one that comes to mind is the defect status. Seeing as there is usually a process surrounding defect resolution...it's important to be able to know the state of the defect at any given time.

------------------
Jason Trebilcock
Cyberentomological Detection, Prevention, and Eradication Specialist
Wells Fargo


Post Extras: Print Post   Remind Me!   Notify Moderator  
QAGirl
Veteran


Reged: 08/14/01
Posts: 2678
Loc: Atlanta, GA
Re: Attributes of a Defect (Bug)
      #228191 - 01/16/02 08:41 AM

And as Jason says that, I also don't see "Resolution". It's nice to track they 'why' of something being 'closed'. In some cases, it works as designed, which you want to know if the same thing comes up again. Also helps to know if it was Fixed, or just 'went away', which we define as either "No Longer an Issue" or "Overcome by Events". (Overcome by events can also be when a defect is no longer applicable due to design changes in the UI, removal of features, etc.)

------------------
"They were painters and they were painting themselves a lovely world.."


Post Extras: Print Post   Remind Me!   Notify Moderator  
e-tester
Member


Reged: 08/24/00
Posts: 216
Re: Attributes of a Defect (Bug)
      #228192 - 01/16/02 08:57 AM

This is a list of all the fields that I have on our bug tracking systems form.

ID
A unique number to identify the defect in the system.

Status
The current status of the bug (New, Open, Closed)

Resolution
In Process, Fixed Pending Review, Fixed, Resubmit, By Design, No Fix, User Error, Need More Information, QA Investigation, Not Reproducible, Software Limitation, Hardware Limitation

Fixed In Build
What build to test the fix in.

Severity
Priority
Date Created
Last Updated at
Author
Assigned To
Product
Application

Area
Specific section(s) of application

Version
Version bug was found in

Build
Build bug was found in

Summary
Brief description of bug

Steps/Additional Information
Detailed steps for recreation

Results
Expected results, if needed for clarity, and actual results of steps

Additional Information
Operating System
Browser
Environment
What environment(s) was this recreated in

Related/Duplicated Defects
Attachments
Original Defect

------------------
ER,
Sr. QA Lead


Post Extras: Print Post   Remind Me!   Notify Moderator  
Jeanj
Moderator


Reged: 02/25/00
Posts: 2079
Loc: Minneapolis, MN
Re: Attributes of a Defect (Bug)
      #228193 - 01/16/02 10:56 AM

Big list!

I may have missed them. Did anybody say;
"Build found in"
"Root Cause"

Sometimes it's not a "bug" but something else.
"Enhancement Request"
"Requirements missing or incorrect"
etc.

The KISS method though, regardless of details is the best.
CRITICAL -
"This thing is gonna 'die' if I send it out like this. Ain't NObody gonna buy this."

HIGH -
"Man, you gotta get on this NOW. Half the stuff ain't gonna work right."

MED -
"Well this stinks, you know what I gotta do to get around this? I'd be embarrassed to show this."

LOW -
"Hee! Did you see how 'xyz' was spelled, and what color they put on that thing?"

------------------
-- Jean
There are no failures.
There are only extended learning opportunities.


Post Extras: Print Post   Remind Me!   Notify Moderator  
rashmipires
Junior Member


Reged: 02/08/01
Posts: 32
Re: Attributes of a Defect (Bug)
      #228194 - 01/16/02 11:39 AM

Also you can add customer perception and exposure fields

Customer perception:
how would a customer react to this defect.
C1- High
C2- Medium
C3- Low

Customer Exposure
% of customers will see this defect
80%-100% High- almost all the customers
20%-80% Medium- most customers
upto 20% Low- very few people

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


Post Extras: Print Post   Remind Me!   Notify Moderator  
AmitK
Member


Reged: 12/23/01
Posts: 75
Re: Attributes of a Defect (Bug)
      #228195 - 01/16/02 08:46 PM

On more thing I found is:

How many times the bug has been reported?

Explaination:
Bug 'A' is reported in Build 001 for say Win Xp Prof. Now same bug is reproding for Win XP Server for Build 002. Insted of changing the desciption of bug, same bug is reprted 2nd time.

Thanks,

AmitK

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


Post Extras: Print Post   Remind Me!   Notify Moderator  
QAGirl
Veteran


Reged: 08/14/01
Posts: 2678
Loc: Atlanta, GA
Re: Attributes of a Defect (Bug)
      #228196 - 01/17/02 04:36 AM

quote:
Originally posted by AmitK:

Explaination:
Bug 'A' is reported in Build 001 for say Win Xp Prof. Now same bug is reproding for Win XP Server for Build 002. Insted of changing the desciption of bug, same bug is reprted 2nd time.

Are you saying that's how it is currently done, or how you believe it should be done?

I'd disagree. If it is the same bug, with the OS being the only difference, the original defect should be updated to reflect additional OS. It's much easier for development to troubleshoot and solve issues if all of the notes and research related to that issue are located within a consolidated defect report.

------------------
"They were painters and they were painting themselves a lovely world.."


Post Extras: Print Post   Remind Me!   Notify Moderator  
AmitK
Member


Reged: 12/23/01
Posts: 75
Re: Attributes of a Defect (Bug)
      #228197 - 01/17/02 05:51 AM

quote:
Originally posted by QAGirl:
If it is the same bug, with the OS being the only difference, the original defect should be updated to reflect additional OS. It's much easier for development to troubleshoot and solve issues if all of the notes and research related to that issue are located within a consolidated defect report.

I agree that what I am saying is not correct in every situation,but in cases like
1) Reopenong a bug for different OS (With same / different steps to reproduce.)
2) Reopenong a bug for same OS (With same steps to reproduce.)

This is useful.
Inaddition it also helps to track life of a bug.

Thanks,

AmitK

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


Post Extras: Print Post   Remind Me!   Notify Moderator  
gaur
Member


Reged: 05/08/01
Posts: 228
Loc: calcutta,west bengal,india
Re: Attributes of a Defect (Bug)
      #228198 - 01/17/02 07:15 AM

U could add these to the list:

1.Assigned To
2.Resolved By
3.Verified By
4.Closed By

U could also have a bug status as postponed....for the ones which are going to be released in the next release etc.

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


Post Extras: Print Post   Remind Me!   Notify Moderator  
techen_hsiung
Junior Member


Reged: 12/02/02
Posts: 7
Loc: Taipei, Taiwan
Re: Attributes of a Defect (Bug)
      #228199 - 12/15/02 12:48 AM

Hi:

Some questions regarding the "Version" and "Build" fields on the bug report UI.

1. We just need to have "Build field" or we need to have both of the fields?

2. In the testing cycle, QAs know the build number and they could enter it in the "Build field". But what number should be entered in the "Version field"?

For example, if the product is a new one, it will be released as version 1.0. So during the testing cycle, QAs should enter 1.0 in the "Versoin field"?

For example: if the product is not a new one, it will be released as version 2.0. So
during the testing cycle, QAs should enter 2.0 or 1.0 in the "Version field"?

3. If the product is released and customer found a bug, the tech-support should enter the version number the customer is using in the "Version field". What number should be entered in the "Build field" for the custmer bug?

Thanks!

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


Post Extras: Print Post   Remind Me!   Notify Moderator  
CSNuts
Member


Reged: 11/20/01
Posts: 86
Loc: USA
Re: Attributes of a Defect (Bug)
      #228200 - 12/17/02 04:10 AM

quote:
Originally posted by techen_hsiung:
Hi:

Some questions regarding the "Version" and "Build" fields on the bug report UI.

1. We just need to have "Build field" or we need to have both of the fields?



I think it depends on where you are in your product but we prefer to track version from the beginning. Makes life easier down the road for us at least.

quote:
2. In the testing cycle, QAs know the build number and they could enter it in the "Build field". But what number should be entered in the "Version field"?

For example, if the product is a new one, it will be released as version 1.0. So during the testing cycle, QAs should enter 1.0 in the "Versoin field"?


Yes we always enter the detected version in the field. You may be entering an enhancement that may not come about until version 2 or 3.

quote:
For example: if the product is not a new one, it will be released as version 2.0. So
during the testing cycle, QAs should enter 2.0 or 1.0 in the "Version field"?

Again, this should be detected in version...we also add a planned fix and actual fix version.

quote:
3. If the product is released and customer found a bug, the tech-support should enter the version number the customer is using in the "Version field". What number should be entered in the "Build field" for the custmer bug?

Thanks!


Well if you use the same system for tech-support then once the product is shipped, they need to know the build that shipped. I say this because once it ships QA is probably gearing up for the next version or a sub version and the issue may have already been fixed. Or it could already be in the tracking system found in the first build after ship.

Just my 2 cents,


------------------
Cat

If you break it; they will come.

Post Extras: Print Post   Remind Me!   Notify Moderator  
sauli1
Junior Member


Reged: 08/09/02
Posts: 16
Loc: Espoo, Finland
Re: Attributes of a Defect (Bug)
      #228201 - 01/08/03 03:24 AM

"External Reference" is also a very good attribute.

Also, if you have systems&processes supporting this, this could be even more sofisticated:
- Associated Task
- Associated Requirement
- Associated "Customer Case" (ref. to CRM system)

------------------
Sauli Karhu
http://www.saunalahti.fi/sauli1


Post Extras: Print Post   Remind Me!   Notify Moderator  
Pages: 1



Extra information
0 registered and 9 anonymous users are browsing this forum.

Moderator:  AJ, Daniel_S, swt88 

Print Topic

Forum Permissions
      You cannot start new topics
      You cannot reply to topics
      HTML is disabled
      UBBCode is enabled

Rating:
Topic views: 18990

Rate this topic

Jump to

Contact Us | Privacy statement SQAForums

Powered by UBB.threads™ 6.5.5