9 defects
A defect, is of course a problem; it causes the system to do one of:
	Not meet the specified requirements (functional or non-functional) 
	Return an incorrect result 
	Stop execution unexpectedly 
Natural language of requirements have ambiguity
	structured english
	use cases
BE REAL: in ANY complex system, there are usually undiscovered bugs

REPORT defects (most syntax errors should be gone before testing begins)
(sufficient to replicate, if possible)
environment (or environmental variables) may allow defects to happen

LIFE CYCLE:
Discovery 
Reporting 
	what the tester did to expose the issue, 
	what was expected to happen, 
	what was observed to happen 
	(In your projects you probably find and then fix)
Triage / prioritization / Assignment 
	which defects are worth fixing? (stakeholder decision)
	What priority is this defect? (consider importance to user)
	Who/how will it be fixed? (usually handed back to developers)
Fixing
	fix
	add (automated) test to ensure it STAYS fixed
Verification 
	tester verifies fix, and no other defect caused

Possible template:
SUMMARY: 
DESCRIPTION: 
REPRODUCTION STEPS: 
EXPECTED BEHAVIOR: 
OBSERVED BEHAVIOR: 
IMPACT: 
SEVERITY: 
WORKAROUND: 
NOTES: 

Modify for the needs of the organization
(Some sections may occasionally be N/A)
Possible template:
SUMMARY: 
	one sentence
	Do not overgeneralize (“it;s broke”--be specific)
DESCRIPTION: 
	more detail, boundaries
	first attempt to reproduce
REPRODUCTION STEPS: 
	The developer attempts to replicate defect. 
	If the developer cannot replicate the defect, 
		they will write on the defect report that “it works on my machine” 
		and stop working on defect. (Does NOT mean there is no error)
	Otherwise, the developer will write some code hoping to fix it. 
	The developer replicates the reproduction steps that caused defect. 
	The tester notes on the defect report whether or not the defect has been fixed. 
		If not, the process goes back to step 3. 
EXPECTED BEHAVIOR: 
	still be specific
	mention what the answer is
	sometimes people misunderstand what should happen
OBSERVED BEHAVIOR: 
	still be specific
	add 'why'  if possible
IMPACT: 
	what this means for user
	which users does it affect
	(how much) does it interfere with functionality
SEVERITY: 
	(could do 0 to 10 scale)
	Blocker: cannot use system
	Critical: major impact on function
	Major: very noticable
	Normal: inconvenience only, or has a workaround
	Minor: no big deal
	Trivial: probably not noticed 
	Enhancement: something that the users want
	(severity is not priority)
WORKAROUND: 
	how to avoid or minimize effect
NOTES: 
	anything else useful, possibly:
		Stack traces; Copies of program; log System or environment variables; 
		Technical specifications of the system ; Other applications running; 
		Particular settings, flags, or arguments passed into the program ;
		notable behavior of other programs; Copied error message text or screen