Programming languages and software engineering - The Computing Universe: A Journey through a Revolution - page 70

test cases. White-box testing is designed to test the internal structures of a pro-
gram. The tester attempts to choose sets of inputs that exercise all the different
possible paths through the code. Black-box testing takes the view of the user
rather than the software developer. The tester checks the software's function-
ality with no knowledge of the system's internal structure. Another important
type of evaluation is fuzz testing , in which valid input data sets are modified with
random mutations and then fed into the program. Providing such invalid and
unexpected inputs to the system allows the tester to determine how a program
handles exceptions - unpredictable conditions or situations that can cause a pro-
gram to crash or possibly create a security risk in the software ( Fig. 4.9 ).

Fig. 4.8. UML is a general methodology
that allows a systematic “step-by-step”
approach to software design. UML is a
unification of three software techniques
developed by Grady Booch (Booch),
Ivar Jacobson (Objectory), and James
Rumbaugh (OMT); although UML also
has roots in David Harel's statecharts.
In software engineering circles Booch,
Jacobson, and Rumbaugh are often
referred to as the “three amigos.” UML
diagrams allow evaluation of various
implementation options prior to actual
program coding.

Empirical software engineering

The increasing complexity of modern software development is indicated
by the numbers of programmers and lines of code in three releases of the
Microsoft Windows operating system ( Fig. 4.10 ). Here the programmers are
divided into “developers,” who write the code, and “testers,” who systemati-
cally check the code for bugs. To allow such large numbers of programmers
to work on different parts of the software system simultaneously, Microsoft
developed a synchronize-and-stabilize approach to writing software. Breaking up
the software into several different “branches” that can be worked on at the
same time allows “large teams to work like small teams.” Much of the com-
plexity now lies in the process of correctly joining the branches back together.
Microsoft solved the problem using “daily synchronizations through product
builds, periodic milestone stabilizations, and continual testing.” 15 Microsoft
also developed an error-reporting tool so that users could inform the company
of any software problems. Analysis of the data led to some interesting conclu-
sions, as summarized by former Microsoft CEO Steve Ballmer:

One really exciting thing we learned is how, among all the software bugs
involved in reports, a relatively small proportion causes most of the errors.
About 20 percent of the bugs cause 80 percent of all errors, and - this is
stunning to me - one percent of bugs cause half of all errors. 16

Fig. 4.9. A screenshot of the dreaded
moment when a computer crashes. In
programmer circles such an event is
known as “the blue screen of death.”