8 Testing
(Debugging)

VALIDATION
	Are we building the right product?
VERIFICATION
	Are we building the product right?
REPAIR

Stated functional and nonfunctional requirements
	Meet
Software Purpose determines HOW important V and V are
	Reliability security safety etc.
	Critical need –DO BETTER
	Cheap or free system—more forgiving
	Workaround

Marketing Environment
	Competitors
	Price
	Schedule

Inspections
	(helpful to have a partner)
	(even if your partner is your dog)
	Incomplete work can be inspected
	Quality of programming shows on inspection
	Some errors can cover/hide other errors
	Cannot replace testing

Testing
	Automatic test data generation is rarely possible
	Humans need to create test data
	Usually need to specify results
	Running test data can be automated
8.1 development testing
	Done by programmers (in pairs)
	Unit, component, system
	Unit
		Test each part
		Call with different parameters
			(include incorrect ones)
		Use driver
			Code to call routine and pass it values
			Check the results
			Might use mock objects to test
			Generalization makes tests more difficult
			Choose text cases
				Normal
				Problematic
				Illegal
				Overload or oversize
			Partition testing
				Groups of values
				Check boundaries
	Component
		What the unit is part of
		Do you need the units to test?
		Stub testing
		Parameters
		Shared memory
		Procedural testing
		Message testing
		Interaction between faults
		Interface mis-use
		Interface mis-understanding
		Timing errors

System testing
		Look for misunderstandings
		Case based testing
		Check all menu options
		All combinations of functions
		Both correct and incorrect input
		Complexity
			(footnote in multi-column format)
	
	Test driven development
		Incrementally add test data
		Test until working
		Add more data, repeat
		Once working for existing data:
		Add new functionality or more test data
		Helps localize what it crashes on
		(run prior test cases each time, automatically)
	
	Release testing
		Development team should NOT do release testing
		Purpose: good enough to use?
		(fit user requirements)

Requirements base testing
	Scenario testing
	Performance testing
		Fast? Accurate?

User testing
	Alpha testing (internal)
	Beta testing (open to users)
	Acceptance testing
		(can be conditional) 

Pragmatic ideas
	Put a print statement in every chunk of code
	Know if executed
	Checks for illegal values
	0, negative, non-numeric
	Simulate all possible decisions
Generate all possible error messages
	Check negative, o
	Cause buffers to overflow
	Underflow, overflow….
	Values too large or too small
	Test null pointers
	Cause components to fail
	Stress testing
	Vary order of components