Sylnovie Merchant, Ph.D. MIS 161 Spring 2005 MIS 161 Systems Development Life Cycle II Lecture 5: Testing User Documentation

Sylnovie Merchant, Ph.D. MIS 161 Spring 2005 Definition Hetzel, 1988 “Testing is the measurement of software (system) quality” Effort required to fix / enhance applications can be up to 30 times greater after implementation than during development

Sylnovie Merchant, Ph.D. MIS 161 Spring 2005 Designing Tests The new or modified application programs, procedural manuals, new hardware, and all system interfaces must be tested thoroughly The purpose is not to demonstrate that the system is free of errors; The purpose is to detect as many errors as possible

Sylnovie Merchant, Ph.D. MIS 161 Spring 2005 Principles of Testing (Hetzel, 1988) Complete testing is not possible –too many combinations / permutations Testing work is creative and difficult An important reason for testing is to prevent deficiencies from occurring

Sylnovie Merchant, Ph.D. MIS 161 Spring 2005 Testing Philosophy It is dangerous to test early modules without an overall testing plan It may be difficult to reproduce sequence of events causing an error Testing must be done systematically and results documented carefully Testing requires independence –Let’s not kill the messenger

Sylnovie Merchant, Ph.D. MIS 161 Spring 2005 Software Quality Space Functionality Engineering Adaptability

Sylnovie Merchant, Ph.D. MIS 161 Spring 2005 Functionality External quality Includes –correctness –reliability –integrity

Sylnovie Merchant, Ph.D. MIS 161 Spring 2005 Engineering Internal quality Includes –efficiency –testability (audit) –documentation –structure

Sylnovie Merchant, Ph.D. MIS 161 Spring 2005 Adaptability Future quality Includes –flexibility –reusability –maintainability

Sylnovie Merchant, Ph.D. MIS 161 Spring 2005 Usability Learning time Performance speed Error handling Client satisfaction

Sylnovie Merchant, Ph.D. MIS 161 Spring 2005 Stages of Testing Unit testing –Tests each module to assure that it performs its function Integration testing (String testing) –Tests the interaction of modules to assure that they work together System testing –Tests to assure that the software works well as part of the overall system Acceptance testing –Tests to assure that the system serves organizational needs

Sylnovie Merchant, Ph.D. MIS 161 Spring 2005 Unit Testing Individual modules (subprograms) –Within specified data range Black Box Testing –Focuses on whether the unit meets requirements stated in specification White-Box Testing –Looks inside the module to test its major elements

Sylnovie Merchant, Ph.D. MIS 161 Spring 2005 Integration Testing User interface testing –Tests each interface function Use-case testing –Ensures that each use case works correctly Interaction testing –Tests each process in a step-by-step fashion System interface testing –Ensures data transfer between systems

Sylnovie Merchant, Ph.D. MIS 161 Spring 2005 String Testing Several modules run concurrently “Stub out” undeveloped modules Passing of data between modules Navigation path between modules What do we mean by “stub out”?

Sylnovie Merchant, Ph.D. MIS 161 Spring 2005 System Testing Full integration of hardware / software Main goals –Integration did not cause new errors –How easy and error-free the system is in use –Security functions are handled properly –System works under high volumes of activity –Documentation and examples work properly Includes –stress testing –regression testing

Sylnovie Merchant, Ph.D. MIS 161 Spring 2005 Stress Testing Ingest system with –more data than expected –no load at all –appropriate load In very short time frame Run software for longer than specified run time

Sylnovie Merchant, Ph.D. MIS 161 Spring 2005 Regression Testing Stress on repeated testing Compare new results with old –reconcile differences

Sylnovie Merchant, Ph.D. MIS 161 Spring 2005 Testing Techniques Equivalency classes –input values = 1 to 100 –test 1 and 100 values from 2 to 99 values outside range

Sylnovie Merchant, Ph.D. MIS 161 Spring 2005 Seam Testing Test at –extremes –value zero –exceptions that shouldn’t exist transaction occurring twice cancel transaction that doesn’t exist

Sylnovie Merchant, Ph.D. MIS 161 Spring 2005 Acceptance Testing Alpha Testing –Repeats tests by users to assure they accept the system Beta Testing –Uses real data, not test data

Sylnovie Merchant, Ph.D. MIS 161 Spring 2005 Testing Management Testing control –nothing falls through the cracks –validation matrix Testing documentation Testing responsibility

Sylnovie Merchant, Ph.D. MIS 161 Spring 2005 DEVELOPING DOCUMENTATION

Sylnovie Merchant, Ph.D. MIS 161 Spring 2005 User Documentation Intended to help users operate the system High quality documentation takes about 3 hours per page The task should not be left to the end of the project Time required to develop and test user documentation should be built into project plan On-line documentation is growing in importance

Sylnovie Merchant, Ph.D. MIS 161 Spring 2005 Types of User Documentation Reference documents (Help!) –How to perform a specific function. Procedures manuals –How to perform business tasks (printing, inputting information) Tutorials –Teach end-users how to use the system

Sylnovie Merchant, Ph.D. MIS 161 Spring 2005 Designing the Documentation Structure Documentation navigation controls Documentation topics –Commands and menus –Common tasks –Definitions

Sylnovie Merchant, Ph.D. MIS 161 Spring 2005 Organizing On-Line Reference Documents

Sylnovie Merchant, Ph.D. MIS 161 Spring 2005 Guidelines for Crafting Documentation Topics Use the active voice Minimize use of “to be” verbs Use consistent terms Use simple language Use friendly language Use parallel grammatical structure Use steps correctly Use short paragraphs