42
Title Slide 2000- "eRisk and eBenefit: the eConomics of software testing" by Les Hatton Oakwood Computing, Surrey, U.K. and the Computing Laboratory, University of Kent [email protected] V ersion 1.1: 12/Oct/2000 ©Copyright, L.Hatton, 2000- OAKWOOD COMPUTING - SURVIVAL AND AVOIDANCE STRATEGIES FOR SOFTWARE FAILURE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2000- eRisk and eBenefit: the eConomics of software testing · v. 1.1, 12/Oct/2000 , (slide 1 - 3). EuroStar 2000. © L.Hatton, 2000-An observation We can develop a theory and practice

  • Upload
    others

  • View
    2

  • Download
    0

Embed Size (px)

Citation preview

Page 1: 2000- eRisk and eBenefit: the eConomics of software testing · v. 1.1, 12/Oct/2000 , (slide 1 - 3). EuroStar 2000. © L.Hatton, 2000-An observation We can develop a theory and practice

Title Slide

2000-

" eRisk and eBenefit: the eConomicsof software testing"

by

Les Hatton

Oakwood Computing, Surrey, U.K. andthe Computing Laboratory, University of Kent

[email protected]

V ersion 1.1: 12/O c t/2000

© C op yright, L.Hatton, 2000-

OA KW OOD COM PUTING - SURV IV A L A ND A V OIDA NCE STRA TEGIES FOR SOFTW A RE FA ILURE

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 2: 2000- eRisk and eBenefit: the eConomics of software testing · v. 1.1, 12/Oct/2000 , (slide 1 - 3). EuroStar 2000. © L.Hatton, 2000-An observation We can develop a theory and practice

v. 1.1, 12/Oct/2000 , (slide 1 - 2). EuroStar 2000. © L.Hat t on, 2000-

Airbus involved in softwall failure

29/Sep/2000

Indian Airlines Airbus A320 flight IC229 had to circle Gauhati airport several times because an elephant broke through a wall and strolled around the airport.

Page 3: 2000- eRisk and eBenefit: the eConomics of software testing · v. 1.1, 12/Oct/2000 , (slide 1 - 3). EuroStar 2000. © L.Hatton, 2000-An observation We can develop a theory and practice

v. 1.1, 12/Oct/2000 , (slide 1 - 3). EuroStar 2000. © L.Hat t on, 2000-

An observation

We can develop a theory and practice of software testing but when a new software technology appears, many people seem to believe that it no longer applies.

This implies that most people see software testing as a tool or set of tools rather than a methodology.

Page 4: 2000- eRisk and eBenefit: the eConomics of software testing · v. 1.1, 12/Oct/2000 , (slide 1 - 3). EuroStar 2000. © L.Hatton, 2000-An observation We can develop a theory and practice

v. 1.1, 12/Oct/2000 , (slide 1 - 4). EuroStar 2000. © L.Hat t on, 2000-

Overview

❖ An introduction to Risk❖ Examples and sources of risk and failure❖ Software Risk Mitigation

Page 5: 2000- eRisk and eBenefit: the eConomics of software testing · v. 1.1, 12/Oct/2000 , (slide 1 - 3). EuroStar 2000. © L.Hatton, 2000-An observation We can develop a theory and practice

v. 1.1, 12/Oct/2000 , (slide 1 - 5). EuroStar 2000. © L.Hat t on, 2000-

Definitions

– Risk is when you don’ t know what will happen but you do know the probabilities

– Uncertainty is when you don’ t even know the probabilities

Page 6: 2000- eRisk and eBenefit: the eConomics of software testing · v. 1.1, 12/Oct/2000 , (slide 1 - 3). EuroStar 2000. © L.Hatton, 2000-An observation We can develop a theory and practice

v. 1.1, 12/Oct/2000 , (slide 1 - 6). EuroStar 2000. © L.Hat t on, 2000-

The eternal conflict

The study of risk is an eternal struggle between:-– Those who wish to quantify it– Those who feel it cannot be quantified

Page 7: 2000- eRisk and eBenefit: the eConomics of software testing · v. 1.1, 12/Oct/2000 , (slide 1 - 3). EuroStar 2000. © L.Hatton, 2000-An observation We can develop a theory and practice

v. 1.1, 12/Oct/2000 , (slide 1 - 7). EuroStar 2000. © L.Hat t on, 2000-

A mathematician’ s view of risk

If R is the Risk, F the Frequency and C the Consequence:

R = F x C

So unlikely catastrophic events have a similar risk to very frequent but unimportant events.

Mathematician’ s always seek to quantify risk.

Page 8: 2000- eRisk and eBenefit: the eConomics of software testing · v. 1.1, 12/Oct/2000 , (slide 1 - 3). EuroStar 2000. © L.Hatton, 2000-An observation We can develop a theory and practice

v. 1.1, 12/Oct/2000 , (slide 1 - 8). EuroStar 2000. © L.Hat t on, 2000-

A risk practitioner’ s view of risk

It is fundamentally impossible to quantify risk because of:-– Problems of measurement– Failure to take account of risk compensation, (people

compensate for greater safety by taking more risks.)

Page 9: 2000- eRisk and eBenefit: the eConomics of software testing · v. 1.1, 12/Oct/2000 , (slide 1 - 3). EuroStar 2000. © L.Hatton, 2000-An observation We can develop a theory and practice

v. 1.1, 12/Oct/2000 , (slide 1 - 9). EuroStar 2000. © L.Hat t on, 2000-

Problems of measurement - A genius’ s view of risk

“ If a guy tells me that the probability of failure is 1 in 105, I know he’ s full of crap.”

Richard P. Feynmann, Nobel Laureate commenting on the NASA Challenger disaster.

Page 10: 2000- eRisk and eBenefit: the eConomics of software testing · v. 1.1, 12/Oct/2000 , (slide 1 - 3). EuroStar 2000. © L.Hatton, 2000-An observation We can develop a theory and practice

v. 1.1, 12/Oct/2000 , (slide 1 - 10). EuroStar 2000. © L.Hat t on, 2000-

Risk compensation

Problem:-– 500 motorcyclists a year are killed in accidents in the

U.K.Solution

– Ban motorcycles

Discuss ...

Page 11: 2000- eRisk and eBenefit: the eConomics of software testing · v. 1.1, 12/Oct/2000 , (slide 1 - 3). EuroStar 2000. © L.Hatton, 2000-An observation We can develop a theory and practice

v. 1.1, 12/Oct/2000 , (slide 1 - 11). EuroStar 2000. © L.Hat t on, 2000-

The risk thermostat, (J. Adams)

This view of risk argues:-– Everybody has a propensity to take risk– This propensity varies between people– Risk-taking is influenced by the rewards– Perceptions of risk are influenced by experience of losses -

one’ s own and others– Risk-taking involved a balancing between the propensity to

take risk and the perceived risk

Page 12: 2000- eRisk and eBenefit: the eConomics of software testing · v. 1.1, 12/Oct/2000 , (slide 1 - 3). EuroStar 2000. © L.Hatton, 2000-An observation We can develop a theory and practice

v. 1.1, 12/Oct/2000 , (slide 1 - 12). EuroStar 2000. © L.Hat t on, 2000-

The dance of the ‘ risk thermostats’

Interaction in society involves:-– Continuous dance of every individual’ s risk thermostat

and interaction with other risk thermostats– Underlying chaos which further undermines quantification

If as it seems quantification seems impossible, are there any useful patterns ?

Page 13: 2000- eRisk and eBenefit: the eConomics of software testing · v. 1.1, 12/Oct/2000 , (slide 1 - 3). EuroStar 2000. © L.Hatton, 2000-An observation We can develop a theory and practice

v. 1.1, 12/Oct/2000 , (slide 1 - 13). EuroStar 2000. © L.Hat t on, 2000-

Patterns in uncertainty

The 4 managerial views of nature, (Holling)

Nature capricious,

fa ta list

Nature perverse / tolerant,

interventionist

Nature benign,

la issez-fa ire

Nature ephemeral,

precautionary

Page 14: 2000- eRisk and eBenefit: the eConomics of software testing · v. 1.1, 12/Oct/2000 , (slide 1 - 3). EuroStar 2000. © L.Hatton, 2000-An observation We can develop a theory and practice

v. 1.1, 12/Oct/2000 , (slide 1 - 14). EuroStar 2000. © L.Hat t on, 2000-

Different rationalities

– Rational argument is based upon logic, mathematics and grammar

– In an uncertain world, rational arguments are constructed on premises beyond rationality

– People apply different views of nature in a rational argument

Page 15: 2000- eRisk and eBenefit: the eConomics of software testing · v. 1.1, 12/Oct/2000 , (slide 1 - 3). EuroStar 2000. © L.Hatton, 2000-An observation We can develop a theory and practice

v. 1.1, 12/Oct/2000 , (slide 1 - 15). EuroStar 2000. © L.Hat t on, 2000-

Different rationalities

The four basic rationalities are:-– Individualist

◆ relatively free from control by others and seek to control

their environment. Example - hacker.

– Hierarchist◆ inhabit a world of strong group boundaries and

hierarchical structures. Example - quality manager

– Egalitarian◆ Strong group loyalties but little respect for externally

imposed rules. Example - users

– Fatalist◆ Resigned to their fate and make no effort to change it.

Example - trombone player.

Page 16: 2000- eRisk and eBenefit: the eConomics of software testing · v. 1.1, 12/Oct/2000 , (slide 1 - 3). EuroStar 2000. © L.Hatton, 2000-An observation We can develop a theory and practice

v. 1.1, 12/Oct/2000 , (slide 1 - 16). EuroStar 2000. © L.Hat t on, 2000-

Different rationalities

If asked how we manage risk, the reactions of the four basic rationalities are:-– Individualist

◆ asserts we are already over-regulated and we should

leave it to market forces

– Hierarchist◆ says we need more research but things are basically

OK

– Egalitarian◆ urge precaution and press for urgent action

– Fatalist◆ watch television and buy lottery tickets

Page 17: 2000- eRisk and eBenefit: the eConomics of software testing · v. 1.1, 12/Oct/2000 , (slide 1 - 3). EuroStar 2000. © L.Hatton, 2000-An observation We can develop a theory and practice

v. 1.1, 12/Oct/2000 , (slide 1 - 17). EuroStar 2000. © L.Hat t on, 2000-

Conclusions about risk

– It is almost impossible to quantify risk or at least we have totally failed to achieve it so far

– Realising that each person approaches a risk with some dynamic mixture of the four basic rationalities is important to understanding the inherently associative nature of risk.

Page 18: 2000- eRisk and eBenefit: the eConomics of software testing · v. 1.1, 12/Oct/2000 , (slide 1 - 3). EuroStar 2000. © L.Hatton, 2000-An observation We can develop a theory and practice

v. 1.1, 12/Oct/2000 , (slide 1 - 18). EuroStar 2000. © L.Hat t on, 2000-

Conclusions about risk, (J. Adams)

– Everyone else is seeking to manage risk too– Everybody is guessing. If they knew, its not risk– Guesses are extremely influenced by beliefs– The behaviour of others and the behaviour of nature are your risk

environment– Unless people’ s propensity to take risk is reduced:-

◆ Safety intervention simply leads to responses which re-

establish the level of risk

◆ Safety intervention redistributes risk but does not reduce it

– Science will continue to invent new risks– In the dance of the risk thermostats, the music never stops

Page 19: 2000- eRisk and eBenefit: the eConomics of software testing · v. 1.1, 12/Oct/2000 , (slide 1 - 3). EuroStar 2000. © L.Hatton, 2000-An observation We can develop a theory and practice

v. 1.1, 12/Oct/2000 , (slide 1 - 19). EuroStar 2000. © L.Hat t on, 2000-

Relevance

So what does all this have to do with risk and benefit in modern software engineering and how does it contribute to testing economics ?

Page 20: 2000- eRisk and eBenefit: the eConomics of software testing · v. 1.1, 12/Oct/2000 , (slide 1 - 3). EuroStar 2000. © L.Hatton, 2000-An observation We can develop a theory and practice

v. 1.1, 12/Oct/2000 , (slide 1 - 20). EuroStar 2000. © L.Hat t on, 2000-

Overview

❖ An introduction to Risk❖ Examples and sources of risk and failure❖ Software Risk Mitigation

Page 21: 2000- eRisk and eBenefit: the eConomics of software testing · v. 1.1, 12/Oct/2000 , (slide 1 - 3). EuroStar 2000. © L.Hatton, 2000-An observation We can develop a theory and practice

v. 1.1, 12/Oct/2000 , (slide 1 - 21). EuroStar 2000. © L.Hat t on, 2000-

Hierarchists v. Individualists

St andard t ransgression rat es

18 36

12167

771

0

100

200

300

400

500

600

700

800

1 2 3 4 5

Pack age

Ex

ecu

tab

le l

ine

s /

tr

an

sg

res

sio

n

Trangression rates of standards in executable lines pertransgression, Fortran77 and C commercial systems, Hatton (1995)

Page 22: 2000- eRisk and eBenefit: the eConomics of software testing · v. 1.1, 12/Oct/2000 , (slide 1 - 3). EuroStar 2000. © L.Hatton, 2000-An observation We can develop a theory and practice

v. 1.1, 12/Oct/2000 , (slide 1 - 22). EuroStar 2000. © L.Hat t on, 2000-

Some personal web observations:-– A significant percentage of web sites have basic

Javascript errors– Internet financial fraud is thought to be much higher

than normal financial fraud– The author’ s bank allowed the user to continue in the

clear without security as an ‘ option’ in its first release.

– Many web-sites exhibit unusual behaviour

Web failure examples

Page 23: 2000- eRisk and eBenefit: the eConomics of software testing · v. 1.1, 12/Oct/2000 , (slide 1 - 3). EuroStar 2000. © L.Hatton, 2000-An observation We can develop a theory and practice

v. 1.1, 12/Oct/2000 , (slide 1 - 23). EuroStar 2000. © L.Hat t on, 2000-

❖ ID Error halts Egg’ s online share dealing– The site allowed logon with wrong-IDs

❖ Netcetera web hosting problem– This allowed companies confidential files to be viewed

by other companies❖ E-mail bugs on BTs Talk21 line

– These allowed access to other users in-boxes

Web failures - short sample from 14/09/00-5/10/00

Page 24: 2000- eRisk and eBenefit: the eConomics of software testing · v. 1.1, 12/Oct/2000 , (slide 1 - 3). EuroStar 2000. © L.Hatton, 2000-An observation We can develop a theory and practice

v. 1.1, 12/Oct/2000 , (slide 1 - 24). EuroStar 2000. © L.Hat t on, 2000-

An example of an automobile system failure:-

• 22/July/1999. General Motors has to recall 3.5 million vehicles because of a software defect. Stopping distances were extended by 15-20 metres.

• Federal investigators received almost 11,000 complaints as well reports of 2,111 crashes and 293 injuries.

• Recall costs ? (An exercise for the reader).

Embedded control systems

Page 25: 2000- eRisk and eBenefit: the eConomics of software testing · v. 1.1, 12/Oct/2000 , (slide 1 - 3). EuroStar 2000. © L.Hatton, 2000-An observation We can develop a theory and practice

v. 1.1, 12/Oct/2000 , (slide 1 - 25). EuroStar 2000. © L.Hat t on, 2000-

Software safety defect hits Ford

• 14/Sep/2000. Production of year 2001 models of Ford Windstar, Crown Victoria, Mercury Grand and Lincoln stopped because of software defect causing airbags to deploy on their own and seatbelts to tighten suddenly.

• This stopped production for several days at Ford of Canada and other sites. At least 15,000 cars have to be recalled and fixed.

• The software was out-sourced.

• Recall costs are not yet known.

Embedded control systems

Page 26: 2000- eRisk and eBenefit: the eConomics of software testing · v. 1.1, 12/Oct/2000 , (slide 1 - 3). EuroStar 2000. © L.Hatton, 2000-An observation We can develop a theory and practice

v. 1.1, 12/Oct/2000 , (slide 1 - 26). EuroStar 2000. © L.Hat t on, 2000-

What can we find in common between web software and embedded control systems ?

Testing difficulties

Page 27: 2000- eRisk and eBenefit: the eConomics of software testing · v. 1.1, 12/Oct/2000 , (slide 1 - 3). EuroStar 2000. © L.Hatton, 2000-An observation We can develop a theory and practice

v. 1.1, 12/Oct/2000 , (slide 1 - 27). EuroStar 2000. © L.Hat t on, 2000-

All faults

Those faultswhich fail

Where and how do defects occur historically ?

Page 28: 2000- eRisk and eBenefit: the eConomics of software testing · v. 1.1, 12/Oct/2000 , (slide 1 - 3). EuroStar 2000. © L.Hatton, 2000-An observation We can develop a theory and practice

v. 1.1, 12/Oct/2000 , (slide 1 - 28). EuroStar 2000. © L.Hat t on, 2000-

Mean time to fail in Adams (1984)

Mean t ime t o f ail

0

5

10

15

20

25

30

35

1.6 5 16 50 160 500 1600 5000

Y ears

Pe

rce

nta

ge

of

all

fa

ult

s

Page 29: 2000- eRisk and eBenefit: the eConomics of software testing · v. 1.1, 12/Oct/2000 , (slide 1 - 3). EuroStar 2000. © L.Hatton, 2000-An observation We can develop a theory and practice

v. 1.1, 12/Oct/2000 , (slide 1 - 29). EuroStar 2000. © L.Hat t on, 2000-

All faults

Failure subsetlarger forheavily usedsystems

Where and how do defects occur historically ?

Page 30: 2000- eRisk and eBenefit: the eConomics of software testing · v. 1.1, 12/Oct/2000 , (slide 1 - 3). EuroStar 2000. © L.Hatton, 2000-An observation We can develop a theory and practice

v. 1.1, 12/Oct/2000 , (slide 1 - 30). EuroStar 2000. © L.Hat t on, 2000-

❖ This study found that:-– ~33% of all faults only failed < once every 5000 execution

years– The most common failures, ( > once every 5 years) were

caused by only 2% of the faults.– Any correction had about a 15% chance of introducing a

problem at least as big into the system.

Mean time to fail in Adams (1984)

Page 31: 2000- eRisk and eBenefit: the eConomics of software testing · v. 1.1, 12/Oct/2000 , (slide 1 - 3). EuroStar 2000. © L.Hatton, 2000-An observation We can develop a theory and practice

v. 1.1, 12/Oct/2000 , (slide 1 - 31). EuroStar 2000. © L.Hat t on, 2000-

Time to failure:-– In an air-traffic control system with 10 copies running

7x24x365, the first 5000 year failures would take 500 years to appear

– In an embedded control system in a car with say 1,000,000 copies around the world, they will first appear in about 4 days.

Web sites which are heavily used exhibit exactly the same kind of behaviour. (Note also that these are exactly the circumstances favouring inspections.)

Some notes

Page 32: 2000- eRisk and eBenefit: the eConomics of software testing · v. 1.1, 12/Oct/2000 , (slide 1 - 3). EuroStar 2000. © L.Hatton, 2000-An observation We can develop a theory and practice

v. 1.1, 12/Oct/2000 , (slide 1 - 32). EuroStar 2000. © L.Hat t on, 2000-

In October, the UK National Air Traffic Control authority admitted that the number of problems in its new centre at Swanwick in Hampshire followed this pattern:-

◆ 5/2000, 550

◆ 8/2000, 200

◆ 9/2000, 217

(This represents a re-injection rate of roughly 6 % which is quite good. No allowance appears to have been made for this effect.)

An example of the Ed Adams’ injection effect

Page 33: 2000- eRisk and eBenefit: the eConomics of software testing · v. 1.1, 12/Oct/2000 , (slide 1 - 3). EuroStar 2000. © L.Hatton, 2000-An observation We can develop a theory and practice

v. 1.1, 12/Oct/2000 , (slide 1 - 33). EuroStar 2000. © L.Hat t on, 2000-

Risk and Benefit

••

•• •

•R O C O F

U S A G E T I M E

F it t e d C u r v e

M e a s u r e d r e l ia b i l i t y

D e s ir e d r e l ia b i l i t y

How do you test a system intended for very heavy use ?

Page 34: 2000- eRisk and eBenefit: the eConomics of software testing · v. 1.1, 12/Oct/2000 , (slide 1 - 3). EuroStar 2000. © L.Hatton, 2000-An observation We can develop a theory and practice

v. 1.1, 12/Oct/2000 , (slide 1 - 34). EuroStar 2000. © L.Hat t on, 2000-

There is clear evidence with both embedded control systems and web development that the increased risks produced by unusually large usage are being ignored.

In essence, everybody temporarily becomes a fatalist.

Relevance to risk discussion

Page 35: 2000- eRisk and eBenefit: the eConomics of software testing · v. 1.1, 12/Oct/2000 , (slide 1 - 3). EuroStar 2000. © L.Hatton, 2000-An observation We can develop a theory and practice

v. 1.1, 12/Oct/2000 , (slide 1 - 35). EuroStar 2000. © L.Hat t on, 2000-

Scope of Standard language

Subset of well-defined features

Extens ionsSubset of allowed features

The need for subsetting programming languages

Problems with programming languages

Page 36: 2000- eRisk and eBenefit: the eConomics of software testing · v. 1.1, 12/Oct/2000 , (slide 1 - 3). EuroStar 2000. © L.Hatton, 2000-An observation We can develop a theory and practice

v. 1.1, 12/Oct/2000 , (slide 1 - 36). EuroStar 2000. © L.Hat t on, 2000-

Do languages improve with time ?

❖ Things get worse with time. The following areas of C are problematic because the committee could not agree:– At standardisation in 1990 (197 items)– At re-standardisation in 1999 (366 items)

❖ By comparison, C++99 contains the words:-– Undefined, 1825 times– Unspecified, 1259 times.

Page 37: 2000- eRisk and eBenefit: the eConomics of software testing · v. 1.1, 12/Oct/2000 , (slide 1 - 3). EuroStar 2000. © L.Hatton, 2000-An observation We can develop a theory and practice

v. 1.1, 12/Oct/2000 , (slide 1 - 37). EuroStar 2000. © L.Hat t on, 2000-

Control Process feedback - an example of a hierarchist technique

Process Product

Measure samples of product for

quality

Feed-back into Process to improve it

Page 38: 2000- eRisk and eBenefit: the eConomics of software testing · v. 1.1, 12/Oct/2000 , (slide 1 - 3). EuroStar 2000. © L.Hatton, 2000-An observation We can develop a theory and practice

v. 1.1, 12/Oct/2000 , (slide 1 - 38). EuroStar 2000. © L.Hat t on, 2000-

Why languages can’ t improve

ADD NEWFEATURES

Re-standardise

language

Recognise poorfeatures

Feedbackcrippled bybackwards

compatibility

Programming languages are designed by individualists.

Control process feedback is a tool used by hierarchists.

Page 39: 2000- eRisk and eBenefit: the eConomics of software testing · v. 1.1, 12/Oct/2000 , (slide 1 - 3). EuroStar 2000. © L.Hatton, 2000-An observation We can develop a theory and practice

v. 1.1, 12/Oct/2000 , (slide 1 - 39). EuroStar 2000. © L.Hat t on, 2000-

Language standardisation ...

❖ Language standardisation disobeys control process feedback in several important ways:-– It is characterised by often unconstrained creativity– It completely ignores measurement– The ‘ must not break old code’ rule means feedback is crippled so

although things are continually added, little gets taken out in practice.

The problem of course is that we are trying to use a hierarchist technique on an individualist technology.

Page 40: 2000- eRisk and eBenefit: the eConomics of software testing · v. 1.1, 12/Oct/2000 , (slide 1 - 3). EuroStar 2000. © L.Hatton, 2000-An observation We can develop a theory and practice

v. 1.1, 12/Oct/2000 , (slide 1 - 40). EuroStar 2000. © L.Hat t on, 2000-

Overview

❖ An introduction to Risk❖ Examples and sources of risk and failure❖ Software Risk Mitigation

Page 41: 2000- eRisk and eBenefit: the eConomics of software testing · v. 1.1, 12/Oct/2000 , (slide 1 - 3). EuroStar 2000. © L.Hatton, 2000-An observation We can develop a theory and practice

v. 1.1, 12/Oct/2000 , (slide 1 - 41). EuroStar 2000. © L.Hat t on, 2000-

As we saw earlier in the discussion of risk,– We must reduce the propensity of software managers and

engineers to take risks◆ By making managers more aware of the cost of failure

◆ By making engineers and managers more aware of the

ability of testing technology to reduce the cost of failure

– Will it help to produce more reliable software ?◆ Probably not. Every observation of society suggests that

risk compensation usually balances risk mitigation. In

software engineering, an improvement in basic reliability

will probably be offset by the addition of new features

What can we do ?

Page 42: 2000- eRisk and eBenefit: the eConomics of software testing · v. 1.1, 12/Oct/2000 , (slide 1 - 3). EuroStar 2000. © L.Hatton, 2000-An observation We can develop a theory and practice

v. 1.1, 12/Oct/2000 , (slide 1 - 42). EuroStar 2000. © L.Hat t on, 2000-

Improvements in software testing will not in general lead to improved reliability. They will simply lead to more features at least in the foreseeable future.

If we judge such a system to be better then we are making progress, however if we are building critical systems, feature introduction must take second place to reliability improvement.

Both feature introduction and reliability improvement do not seem to be an option.

A prediction