Slide 1

Construction (Testing)

Chapter 15

Alan Dennis, Barbara Wixom, and David Tegarden

John Wiley & Sons, Inc.

Slides by Fred NiedermanEdited by Solomon Negash

Slide 2

Key DefinitionsConstruction is the development of all parts of the software itself, documentation, and new operating procedures.Testing is a form of insurance. It costs more to repair software bugs when people are depending on the programs than in earlier stages before the systems are in use. Documentation provides information to make the system easier to use and repair.

Slide 3

Main Tasks of Managing the Programming Effort

Assigning the programmersCoordinating the activitiesManaging the schedule

Slide 4

The Programmer Paradox

After an appropriate number of people are assigned to a programming task, adding more people slows down rather than speeds up completion of the project.When projects are so complex they require a large team, the best strategy is to break the project into a series of smaller parts that can function as independently as possible.

Slide 5

Managing the Schedule

Use initial time estimates as a baselineRevise time estimates as construction proceedsFight against scope creepMonitor “minor” slippageCreate risk assessment and track changing risksFight the temptation to lower quality to meet unreasonable schedule demands

Slide 6

Avoid Classic Mistakes

1. Research-oriented developmentIf you use state-of-the art technology, lengthen planned time

2. Using “low-cost” personnelIf using a significant number of entry level personnel, lengthen planned time

3. Lack of code controlUse source code library to keep programmers from changing the same code at the same time

4. Inadequate testingAlways allocate sufficient time for formal testing

Slide 7

Designing Tests

The purpose is not to demonstrate that the system is free of errors;The purpose is to detect as many errors as possible

Slide 8

Testing Philosophy

It is dangerous to test early modules without an overall testing planIt may be difficult to reproduce sequence of events causing an errorTesting must be done systematically and results documented carefully

Slide 9

Stages of TestingUnit testing

Tests each module to assure that it performs its function

Integration testingTests the interaction of modules to assure that they work together

System testingTests to assure that the software works well as part of the overall system

Acceptance testingTests to assure that the system serves organizational needs

Slide 10

Error Discover Rates

Slide 11

Testing and Object-Orientation

Encapsulation and information hidingPolymorphism and dynamic bindingInheritanceReuseOO Development process and products

Slide 12

Test Planning

Address all products created during developmentTest completeness of CRC cardsTest casesStubs

Slide 13

Class Test Plan

Slide 14

Unit Testing

Black Box TestingFocuses on whether the unit meets requirements stated in specification

White-Box TestingLooks inside the module to test its major elements

Slide 15

Integration TestingUser interface testing

Tests each interface functionUse-case testing

Ensures that each use case works correctlyInteraction testing

Tests each process in a step-by-step fashionSystem interface testing

Ensures data transfer between systems

Slide 16

System TestingRequirements Testing

Ensures that integration did not cause new errorsUsability Testing

Tests how easy and error-free the system is in useSecurity Testing

Assures that security functions are handled properlyPerformance Testing

Assures that the system works under high volumes of activity

Documentation TestingAnalysts check that documentation and examples work properly

Slide 17

Acceptance Testing

Alpha TestingRepeats tests by users to assure they accept the system

Beta TestingUses real data, not test data

Slide 18

DEVELOPING DOCUMENTATION

Slide 19

User DocumentationIntended to help users operate the systemHigh quality documentation takes about 3 hours per pageThe task should not be left to the end of the projectTime required to develop and test user documentation should be built into project planOn-line documentation is growing in importance

Slide 20

Types of User Documentation

Reference documentsProcedures manualsTutorials

Slide 21

Designing the Documentation Structure

Documentation navigation controlsDocumentation topics

Commands and menusCommon tasksDefinitions

Slide 22

Organizing On-Line Reference Documents

Slide 23

Guidelines for Crafting Documentation Topics

Use the active voiceMinimize use of “to be” verbsUse consistent termsUse simple languageUse friendly languageUse parallel grammatical structureUse steps correctlyUse short paragraphs

Slide 24

SummaryThe project manager needs to manage coordination, scheduling, and overall effectiveness of the project.Testing begins early in the development process and continues looking to find problems throughout the development lifecycle.Documentation helps the user quickly assimilate the new technology and provide assistance in transitioning to the new business processes.

Slide 25

Expanding the Domain

An extensive example of on-line documentation of the Java language is available at the Sun Corporation website:http://java.sun.com/j2se/javadoc/

Slide 26

Expanding the Domain

An excellent source of information about many aspects of computing can be found through the IEEE Computing Society, and in particular through their software development conferences. See the following for a list of proceedings:http://www.computer.org/proceedings/compsac