Topic: Bugs in software testing !!!

Message

Bugs in software testing !!! 

	Bug:

	An Error found in the development 
	environment before the product is shipped to the customer.

	Bug Reporting :

	A

	person who uses a product

	Reports a Bug/Malfunctioning ..etc to a person who developed the product

	Bug Tracking :

	Managing and Reviewing a bug and its 
	status

	Bug Tracking System :

	This is a system designed especially to

	manage

	software problems, enhancement,

	change request during software development life cycle. 

Tips for Bug Tracking !!! 

	1. A good tester will always try to 
	reduce the repro steps to the minimal steps to reproduce; this is extremely 
	helpful for the programmer who has to find the bug.

	2. Remember that the only person who can 
	close a bug is the person who opened it in the first place. Anyone can 
	resolve it, but only the person who saw the bug can really be sure that what 
	they saw is fixed.

	3. There are many ways to resolve a bug. 
	FogBUGZ allows you to resolve a bug as fixed, won't fix, postponed, not 
	repro, duplicate, or by design.

	4. Not Repro means that nobody could 
	ever reproduce the bug. Programmers often use this when the bug report is 
	missing the repro steps.

	5. You'll want to keep careful track of 
	versions. Every build of the software that you give to testers should have a 
	build ID number so that the poor tester doesn't have to retest the bug on a 
	version of the software where it wasn't even supposed to be fixed.

	6. If you're a programmer, and you're 
	having trouble getting testers to use the bug database, just don't accept bug reports by any other method. 
	If your testers are used to sending you email with bug reports, just bounce 
	the emails back to them with a brief message: "please put this in the bug 
	database. I can't keep track of emails."

	7. If you're a tester, and you're having 
	trouble getting programmers to use the bug database, just don't tell them 
	about bugs - put them in the database and let the database email them.

	8. If you're a programmer, and only some 
	of your colleagues use the bug database, just start assigning them bugs in 
	the database. Eventually they'll get the hint.

	9. If you're a manager, and nobody seems 
	to be using the bug database that you installed at great expense, start 
	assigning new features to people using bugs. A bug database is also a great 
	"unimplemented feature" database, too.

	10. Avoid the temptation to add new 
	fields to the bug database. Every month or so, somebody will come up with a 
	great idea for a new field to put in the database. You get all kinds of 
	clever ideas, for example, keeping track of the file where the bug was 
	found; keeping track of what % of the time the bug is reproducible; keeping 
	track of how many times the bug occurred; keeping track of which exact 
	versions of which DLLs were installed on the machine where the bug happened. 
	It's very important not to give in to these ideas. If you do, your new bug 
	entry screen will end up with a thousand fields that you need to supply, and 
	nobody will want to input bug reports any more. For the bug database to 
	work, everybody needs to use it, and if entering bugs "formally" is too much 
	work, people will go around the bug database.

Priority in Bug Tracking !!! 

	Priority is used to organize the 
	work.This field describes the importance and order in which a bug should be 
	fixed. 

	The field only takes meaning when owner 
	of the bug 

	P1 - Fix in next build

	P2 - Fix as soon as possible

	P3 - Fix before next release

	P4 - Fix if time allows

	P5 - Unlikely to be fixed

	Default priority for new defects is set 
	at P3.
Severity in Bug tracking !!! 

	This field describes the impact of a 
	bug. The submitter of the bug should consider carefully their view of the 
	bug severity, i.e. the impact to them as the end user.

	Blocker 
	- Blocks development and/or testing work 

	Critical - crashes, loss of data, severe memory leak 

	Major 
	- major loss of function 

	Normal 
	- Minor loss of function.Unfriendly behavior that is hindering, but 
	workable, for the user or service 

	Minor 
	- Minor loss of function.Unfriendly behavior that is merely annoying to the 
	user 

	Trivial 
	- cosmetic problem like misspelled words or misaligned text 

	Enhancement - Request for enhancement 

	Note 
	: The default severity is Normal.

Bug Life Cycle !!! 

	Life cycle of a BUG:

	*********************

	As defects move through the system they 
	are given various states. At each state there are a number of possible 
	transitions to other states

	The following figure is the life cycle 
	of a bug

	NEW 
	Recently added

	to ASSIGNED by acceptance

	to RESOLVED by analysis and maybe fixing

	to NEW by reassignment

	ASSIGNED The owner, i.e. the person referenced by Assigned-To has 
	accepted this bug as something they need to work on

	to NEW by reassignment

	to RESOLVED by analysis and maybe fixing

	REOPENED Was once resolved but has been reopened

	to NEW by reassignment

	to ASSIGNED by acceptance

	to RESOLVED by analysis and maybe fixing

	RESOLVED Has been resolved (e.g. fixed, deemed
	unfixable, 
	etc. See "resolution" column)

	to REOPENED by reopening

	to VERIFIED by verification

	to CLOSED by closing

	VERIFIED The resolution has been approved by
	QA

	to CLOSED when the product ships

	to REOPENED by reopening

	CLOSED 
	Over and done with

	to REOPENED by reopening
	Bug Life Cycle - Resolutions !!!

		Fixed - The Bug has been fixed

		Invalid - The problem described is not a bug

		WontFix - The
		bug 
		will never be fixed

		Later - The
		bug 
		will not fixed in this version

		Remind - The bug probably wont be fixed in this version

		Duplicate - This is a duplicate of an existing bug

		Worksforme - the bug could not be reproduced

		Moved - The bug has been moved to another database
	Effective Bug Reporting !!!

		Keep bug 
		reporting simple:

		Don't make bug reporting complicated by requiring entry of more data 
		than is really necessary 

		Describe how to reproduce bugs:

		A bug report should include a step-by-step description on how to 
		reproduce the bug (or replication information)

		Record how bugs are detected:

		Report all the facts-Allow them to reproduce the bug

		Write bug reports immediately :

		the longer you wait between finding the problem and reporting it, the 
		more likely it is the description will be incomplete, the problem not 
		reproducible, or simply forgotten.

		Writing a one-line report summary :

		Writing the Bug's report title is an art. You must master it (the same 
		should be related to bug you are reporting)

		Don't use the same summary:

		For two different reports, even if they are similar don’t use similar 
		summary

		Consult your peer member:

		Before writing a bug consult your peer team member (if the same has 
		already been reported).

Edited by Mithi25 - 10Aug2009 at 12:06am

Author	Message
Mithi25 Senior Member Joined: 23Jun2009 Online Status: Offline Posts: 288	Topic: Bugs in software testing !!! Posted: 10Aug2009 at 12:05am
	Bugs in software testing !!! Bug: An Error found in the development environment before the product is shipped to the customer. Bug Reporting : A person who uses a product Reports a Bug/Malfunctioning ..etc to a person who developed the product Bug Tracking : Managing and Reviewing a bug and its status Bug Tracking System : This is a system designed especially to manage software problems, enhancement, change request during software development life cycle. Tips for Bug Tracking !!! 1. A good tester will always try to reduce the repro steps to the minimal steps to reproduce; this is extremely helpful for the programmer who has to find the bug. 2. Remember that the only person who can close a bug is the person who opened it in the first place. Anyone can resolve it, but only the person who saw the bug can really be sure that what they saw is fixed. 3. There are many ways to resolve a bug. FogBUGZ allows you to resolve a bug as fixed, won't fix, postponed, not repro, duplicate, or by design. 4. Not Repro means that nobody could ever reproduce the bug. Programmers often use this when the bug report is missing the repro steps. 5. You'll want to keep careful track of versions. Every build of the software that you give to testers should have a build ID number so that the poor tester doesn't have to retest the bug on a version of the software where it wasn't even supposed to be fixed. 6. If you're a programmer, and you're having trouble getting testers to use the bug database, just don't accept bug reports by any other method. If your testers are used to sending you email with bug reports, just bounce the emails back to them with a brief message: "please put this in the bug database. I can't keep track of emails." 7. If you're a tester, and you're having trouble getting programmers to use the bug database, just don't tell them about bugs - put them in the database and let the database email them. 8. If you're a programmer, and only some of your colleagues use the bug database, just start assigning them bugs in the database. Eventually they'll get the hint. 9. If you're a manager, and nobody seems to be using the bug database that you installed at great expense, start assigning new features to people using bugs. A bug database is also a great "unimplemented feature" database, too. 10. Avoid the temptation to add new fields to the bug database. Every month or so, somebody will come up with a great idea for a new field to put in the database. You get all kinds of clever ideas, for example, keeping track of the file where the bug was found; keeping track of what % of the time the bug is reproducible; keeping track of how many times the bug occurred; keeping track of which exact versions of which DLLs were installed on the machine where the bug happened. It's very important not to give in to these ideas. If you do, your new bug entry screen will end up with a thousand fields that you need to supply, and nobody will want to input bug reports any more. For the bug database to work, everybody needs to use it, and if entering bugs "formally" is too much work, people will go around the bug database. Priority in Bug Tracking !!! Priority is used to organize the work.This field describes the importance and order in which a bug should be fixed. The field only takes meaning when owner of the bug P1 - Fix in next build P2 - Fix as soon as possible P3 - Fix before next release P4 - Fix if time allows P5 - Unlikely to be fixed Default priority for new defects is set at P3. Severity in Bug tracking !!! This field describes the impact of a bug. The submitter of the bug should consider carefully their view of the bug severity, i.e. the impact to them as the end user. Blocker - Blocks development and/or testing work Critical - crashes, loss of data, severe memory leak Major - major loss of function Normal - Minor loss of function.Unfriendly behavior that is hindering, but workable, for the user or service Minor - Minor loss of function.Unfriendly behavior that is merely annoying to the user Trivial - cosmetic problem like misspelled words or misaligned text Enhancement - Request for enhancement Note : The default severity is Normal. Bug Life Cycle !!! Life cycle of a BUG: ********************* As defects move through the system they are given various states. At each state there are a number of possible transitions to other states The following figure is the life cycle of a bug NEW Recently added to ASSIGNED by acceptance to RESOLVED by analysis and maybe fixing to NEW by reassignment ASSIGNED The owner, i.e. the person referenced by Assigned-To has accepted this bug as something they need to work on to NEW by reassignment to RESOLVED by analysis and maybe fixing REOPENED Was once resolved but has been reopened to NEW by reassignment to ASSIGNED by acceptance to RESOLVED by analysis and maybe fixing RESOLVED Has been resolved (e.g. fixed, deemed unfixable, etc. See "resolution" column) to REOPENED by reopening to VERIFIED by verification to CLOSED by closing VERIFIED The resolution has been approved by QA to CLOSED when the product ships to REOPENED by reopening CLOSED Over and done with to REOPENED by reopening Bug Life Cycle - Resolutions !!! Fixed - The Bug has been fixed Invalid - The problem described is not a bug WontFix - The bug will never be fixed Later - The bug will not fixed in this version Remind - The bug probably wont be fixed in this version Duplicate - This is a duplicate of an existing bug Worksforme - the bug could not be reproduced Moved - The bug has been moved to another database Effective Bug Reporting !!! Keep bug reporting simple: Don't make bug reporting complicated by requiring entry of more data than is really necessary Describe how to reproduce bugs: A bug report should include a step-by-step description on how to reproduce the bug (or replication information) Record how bugs are detected: Report all the facts-Allow them to reproduce the bug Write bug reports immediately : the longer you wait between finding the problem and reporting it, the more likely it is the description will be incomplete, the problem not reproducible, or simply forgotten. Writing a one-line report summary : Writing the Bug's report title is an art. You must master it (the same should be related to bug you are reporting) Don't use the same summary: For two different reports, even if they are similar don’t use similar summary Consult your peer member: Before writing a bug consult your peer team member (if the same has already been reported). Edited by Mithi25 - 10Aug2009 at 12:06am
	Send Unlimited FREE SMS to Any Mobile Anywhere in INDIA, Click Here Post Resume: Click here to Upload your Resume & Apply for Jobs

	IP Logged


One Stop Testing Forum : Types Of Software Testing @ OneStopTesting : Manual Testing @ OneStopTesting