Testing and the Software Process
•	Reading: Kaner et al., ch. 3
•	Personnel roles
•	Process phases
•	Testing and each phase
(Personnel) roles
•	Roles reflect jobs that need to be done
•	One person may play more than one role
•	Project Manager
•	Overall responsibility for budget and schedule
Designer roles
•	Architect
•	Strategizes and develops overall structure of software
•	Subject matter expert/software analyst
•	Makes sure product functionality follows needs and desires of the users
Designer roles
•	Human factors analyst/ergonomist
•	Makes sure product suits users psychologically and physically
•	User interface programmer
•	Focuses on graphics/presentation
•	Not just what to display, but how
•	Shares responsibilities with human factors analyst
Designer roles
•	Product manager/marketing manager
•	Makes sure product is compatible with organization goals, competitive with competing products, and (often) profitable
•	Technical support
•	Wants to make product easier ==> fewer calls from customers
Designer roles
•	Writers -- ex: user manuals, Help files, web pages
•	Testers
•	May have others ex: lawyers, artists
•	Others may be doing testing activities (ex: ergonomist may check for physical strain or discomfort during use of product -- consider first version of the Nokia game phone)
Development phases (p. 30)
•	Planning
•	Design
•	Coding and documentation
•	Testing and Fixing
•	Post-release Maintenance and Enhancement
Development phases (comments)
•	These are actually more like activities that the team performs
•	Frequently, projects go from planning through testing and fixing, then repeat those 4 phases to refine product
•	Maintenance is often done in steps like the first 4 phases
Development phases and testing
•	Changing earlier is better than later
•	In particular, programmers fix bugs without any overhead (bug reports, bug status reviews)
•	Pre-release fix is much cheaper than post-release
Planning phase testing
•	Team develops requirements
•	Testers focus on ideas
•	Do the ideas make sense? "Should we do this"?
•	Compatibility of ideas
•	Completeness
•	Possible? (achievable? reasonable? testable?)
Planning phase testing
•	Compare proposed features with those of competitors
•	Work with focus groups to discuss demand for product and usefulness of product
•	Observe users in their work environment
Design phase testing
•	External design -- user interface design
•	User-system interactions may involve things not on the screen
•	ex: input and output devices
•	Define specification, can draft user manual
Design phase testing
•	Can design high-level acceptance tests
•	Testing if something works must wait until product is completed
•	Testing user concerns can be done with stub routines
•	Implement skeleton program
•	When user selects option, call simple function that produces correct type of response (ex: for computation result, display 100 on screen)
Design phase testing
•	The above program is an example of a prototype
•	Looks and behaves like the intended product, but is missing things
•	"Quick and dirty" solution
•	Goal is to get early feedback from customers
Design phase testing
•	Evolutionary prototype is intended to grow into final product
•	Why might this be a bad idea?
•	Repeat, "quick and dirty" solution
•	Typically has a poor, unmaintainable design
•	Throwaway prototype is intended to be discarded
•	Standard advice from either industry or open source practitioners (Brooks, Raymond) is that first version should be thrown away