Life Cycle Testing
•	Psychology
•	Waterfall process
•	Plan-Do-Check-Act for Testing Plan
Psychology
•	People may be reluctant to find problems in their work
•	Problems detected => more work
•	Mistakes often come from incorrect assumptions
Psychology: standard solution
•	Different person/group responsible for quality
–	Identify problems/uncertainties
•	Non-computer science examples:
–	Police Internal Affairs division
–	How has the Enron scandal affected Andersen and other accounting/consulting firms?
Waterfall process
•	Requirements
•	Logical design (Analysis/Architecture):
–	Data decomposition: entity relation diagram
–	Function decomposition: "function" : what the software should do
–	Divides problem into subsystems
–	Ex: major steps in solution, software layers
Waterfall process (continued)
•	Physical design, program unit design: Get more detailed
•	Coding:
–	should only be implementing what was designed
–	should not be adding functions/files visible to other parts of software
Waterfall process (continued)
•	Testing:
–	unit/component testing
–	integration testing (combining components)
–	system testing: internal testing of entire application
–	Acceptance testing: external (customer) testing
•	Maintenance ...
Plan
•	Deliverable: test plan (not final)
•	Test objectives:
–	How are these different than product objectives?
•	Overall plan: What? When? What will be reported?
•	Testing requirements: hardware, personnel, data, when to start/stop testing
Test Plan and Process
•	Some parts must be completed before coding
–	Ex: system description, scope of testing, approval of test plan
•	Some parts cannot be begun at the start
–	Ex: Deciding test environment before getting requirements not feasible
Do (Design and execute tests)
•	Test cases, expected results, function/test case matrix, ...
–	Function/test case matrix associates test cases with requirements
•	Requirements must be testable, identifiable
•	Maintain test plan: tool selection, dependencies, conditions
Sample test case form (Exhibit 3)
•	actual data, expected/actual results
•	Version -- Why would we need different versions of a test case?
•	Environment -- consider info required in a bug report
•	What kind of testing is this intended for?
�¨	Function being tested -- requirements, not code
Check
•	Maintain measurements during testing
•	Now analyze test results and measurements
•	Deliverables: Report of defects found, suggestions for improvements
Act
•	Account for failures, surprises
•	Update test plan
•	Update general process for generating test plan
•	Ex: Found attribute duplicated in 2 different tables in database -- try to solve by using normalization
Technical Review
•	done formally and informally
•	Goals:
–	Cover defects which tools cannot check
•	Ex: specification, most standards
–	Early detection -- helps schedule, cheaper and easier to find source of defect
Structured walkthrough
•	Material being reviewed is presented
•	Reviewers respond during presentation
•	Some structure is desirable for productive review
•	[Observation: you need to be able to present what you do]
Inspection
•	Plan: Identify who is involved
–	Inform everyone what is to be inspected, what they do
•	Do: Individual preparation, inspect
•	Check: identify and document defects
–	Do not try to solve (Why not?)
•	Act: repair defects, check repairs
–	What should the inspection team do here?
Roles
•	Each participant in a review has one or more roles
•	Helps people know what they should be doing
•	Leader
•	Recorder
•	Reviewer(s)
For a good review ...
•	Plan: include agenda (checklists in Appendix F)
•	Include schedule: management usu. needs to know when you can finish the product
•	Report should address all interested parties:
–	management, users, developers, quality assurance people