Professional Documents
Culture Documents
Requirements (2) Design (4) Implementation (5) Deployment
Requirements (2) Design (4) Implementation (5) Deployment
Developing software starts with identifying a part of real worlds that we are not satisfied with. Then:
(1) Requirements – document what is unsatisfactory – why new software is needed
(2) Design – create a high level description of the solution architecture
(3) create a detailed design
(4) Implementation – create the solution components
(5) Deployment – delivery of the solution
We are now satisfied with that part of the real world.
Quality issues:
● Moving from algorithms to code is not always non-trivial
● Mistakes can be made
● The algorithms might not meet the specification
● The specification might not cover all requirements
Testing helps us improve software
Pandora’s box
Quality
The quality attributes of a system are called non-functional (operational) requirements. Some examples
are:
● Correctness
● Reliability
● Usability
● Re-usability
● Reliability
● Maintainability
● Testability
We must plan early to test these.
Quality is about having practices in place that:
● Promote reproducible standards of work
● Promote continuous improvement
Testing identifies faults, whose removal increases the software quality by increasing software’s potential
reliability.
Testing is the measurement of software quality. We measure how closely we have achieved quality by
testing the relevant factors such as correctness, reliability, usability, maintainability, reusability, testability
etc.
Other factors that may determine the testing performed may be contractual or legal requirements,
normally defined in industry-specific standards or based on agreed best practice.
Reliability is the probability that software will not cause the failure of a system for a specified time
under specified conditions.
Acceptable errors?
Errors occur because we are not perfect and even if we were, we are working under constraints, such as
delivery deadline.
Errors result in faults in the artefacts of software development.
Faults may lead to failures. A single failure can cost nothing or a lot (or anything in between):
Web-page script missing – simply reload
Failure in safety-critical software can cause death or injury – e.g. aircraft control software
Testing approaches
Testing is primarily done to find faults, rather than prove correctness. There are 2 different ways we can
discover faults:
● Execute the software and try to detect faults – dynamic testing
● Scrutinise development documents without running the software – static testing
Errors cause faults, which can cause failures. Bearing in mind the architecture and management
concerns, we can identify a large number of artefacts – any can have faults.
However, establishing quality control regime and setting up testing resources is a cost to the organisation
– is it worth the investment?