Keeping Software Under Control
Keeping
Software
Under Control.
Either insufficient testing, or the wrong type of testing.
With all of the examples we have seen so far, what common themes can we identify? There may be several, but one theme is clear.
More and better software testing seems a reasonable aim, but that aim is not quite as simple to achieve as we might expect.
Exhaustive testing is not possible.
A particular software module was reused from the Ariane 4 programme. Only part of the functionality was required, but the module was incorporated without changes. The unused functionality indirectly caused a directional nozzle to move in an uncontrolled way.
Conditions were encountered in the first few seconds after the launch that were not expected, and therefore had not been tested. If every possible test had been run, the problem would have been detected.
However, if every test had been run, the testing would still be running now, and the ill-fated launch would never have taken place.
Video
game.
Lower probability of failure in a less complex system. The impact of failure is limited — inconvenience, not catastrophe.
Automatic
flight
control.
Greater probability of failure in the more complex system. The impact of failure is also greater — lives are at stake.
What we test, and how much we test it, must be related in some way to the risk. Greater risk implies more and better testing. These uncertainties become more significant as the system complexity and the implications of failure increase.
If a system meets its users' requirements, that is a starting point.
Online tax
returns breach.
An obvious functional weakness in allowing one user to view another user's details. Hard to imagine any user finding that acceptable.
Top 10
criminals crash.
No failure of functionality — the system was simply swamped by requests. It could not deliver services because it was not designed to handle the peak load after media coverage.
Three vertices that consume each other.
The software development process, like any other, must balance competing demands. If we need to deliver a system faster, it will usually cost more. These three affect one another, and also influence the features that are or are not included in the delivered software.
Time
Deliver faster and the other two vertices must shift. Less time means higher cost or lower quality.
Money
Increased budget can buy more time or more quality — but resources are never infinite.
Quality
The degree to which the system meets requirements. Squeezed when time or money run short.