MIS 161Systems Development Life Cycle II

Lecture 5:Testing

User Documentation

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

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

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

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

Software Quality Space

• Functionality• Engineering• Adaptability

Functionality

• External quality• Includes

– correctness– reliability– integrity

Engineering

• Internal quality• Includes

– efficiency– testability (audit)– documentation– structure

Adaptability

• Future quality• Includes

– flexibility– reusability– maintainability

Usability

• Learning time• Performance speed• Error handling• Client satisfaction

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

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

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

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”?

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

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

Regression Testing

• Stress on repeated testing• Compare new results with old

– reconcile differences

Testing Techniques

• Equivalency classes– input values = 1 to 100– test

• 1 and 100• values from 2 to 99• values outside range

Seam Testing

• Test at– extremes– value zero– exceptions that shouldn’t exist

• transaction occurring twice• cancel transaction that doesn’t exist

Acceptance Testing

• Alpha Testing– Repeats tests by users to assure they accept the

system

• Beta Testing– Uses real data, not test data

Testing Management

• Testing control– nothing falls through the cracks– validation matrix

• Testing documentation• Testing responsibility

DEVELOPING DOCUMENTATION

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

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

Designing the Documentation Structure

• Documentation navigation controls• Documentation topics

– Commands and menus– Common tasks– Definitions

Organizing On-Line Reference Documents

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