Lecture 5: Testing
-
Upload
softwarecentral -
Category
Documents
-
view
156 -
download
0
Transcript of Lecture 5: Testing
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