CPSC 3720 - DAY 23
APRIL 7, 2017

==============================================================================

getInterest(CreditScore, AgeofCar, Miles, Bankmember, BaseRate)

Credit Score

	Equivalence Classes:
	0 <= CreditScore < 550
	...
	...

	Boundry Cases
	0, 549, 550

AgeOfCar

	Equivalence Classes:
	...
	...

	Boundry Cases:
	...
	...

Acceptance Testing

	The testers must be familiar with the functional and nonfunctional
	requirements.

		Its testing how well the system meets those requirements
		Testers are often the cutomer

	Benchmark test - client prepares a set of test cases that represent
	typical conditions for the system
		Can be performed by actual users or a special test team

	Competitor testing - system is tested against a competitor's system, 
	or an existing system that it is replacing

	Shadow testing - the new system and the elgacy system are run in
	parallel and the output is compared.
		A type of competitor testing

	After acceptance testin, the customer reports which requirements are
	not satisfied
		Can discus changing requirements 
		If customer is satisfied, system is accepted

Installation Testing

	After the system has been accepted.
	System is installed in the target environment
	Repeat test cases from functional and performance testing
	Some requirements may not have been able to be tested without being
	in the target environment
	Some requirements may not have been able to be tested without being in
	the target environment
		May depend on target specific resources
	When installation test is complete, the system is formally deliverecd

	Example: Blackboard and Canvas at Clemson

Regression Testing

	Rerun all previous unit tests and integration tests after changing
	the system
	Can be very time consuming, there are techniques to reduce time
	Retest dependent components
		Focus on components that depend on the changed component
		Other areas of the system should be unaffected
		Lower coupling in the system reduces the amount of the test
	Retest risky uses cases
		Focus on catastrophic faults
	Retest frequent use cases
		What uses cases are most often run by the users?

Avoiding new faults
	
	Revision of code could iintroduce new faults
	Can use techniques to avoid 
	Problem Tracking
		Document each failure, erroneous state and fault
		Document correction and revisions
	Regression testing
		Re-execute all prior tests after a change
	Rationale Maintenance
		Document the rationale for the change
		Track assumptions.