4. INTRODUCTION
4
• Failures need to be documented with much care
in order to report them to the company that
develops the program.
• Testing should not only find defects but make
sure that a program meets the expected
reliability.
5. THE PSYCHOLOGY OF TESTING
• One of the primary causes of poor application testing is the fact that
most programmers begin with a false definition of the term.
They might say:
• ‘‘Testing is the process of demonstrating that errors are not present.’’
• ‘‘The purpose of testing is to show that a program performs its intended
functions correctly.’’
• ‘‘Testing is the process of establishing confidence that a program does what it
is supposed to do.’’
5
6. THE FACT
When you test a program, you want to add some value to it, but :
• Adding value through testing means raising the quality or reliability of the
program.
• Raising the reliability of the program means finding and removing errors.
• Therefore, don’t test a program to show that it works; rather, start
with the assumption that the program contains errors (a valid
assumption for almost any program) and then test the program to
find as many of the errors as possible.
6
8. DEFINITION
• There is no doubt that the reliability of a computer program is an
important element. If a program repeatedly fails to perform, it is a
little doubtful whether other software quality factors are acceptable.
• Software reliability, unlike other quality factors, can be measured,
directed, and estimated using historical development data.
8
9. DEFINITION
• Software reliability is defined in statistical terms as :
• “The probability of failure-free operation of a computer
program in a given environment and time.”
• This means that we can never know the exact
moment when a software product will fail because we
will never have the complete data needed to calculate
the probability.
9
10. CONCEPT ILUSTRATION
• Program X is estimated to have a reliability
of 0.96 over eight processing hours.
• In other words, if program X is to be executed
100 times and requires eight hours of
elapsed processing time (execution time), it
will operate correctly (without failure) 96
times out of 100 executions.
10
11. QUALITY AND RISK
• “People bet their jobs, their comforts, their safety, their
entertainment, their decisions, and their very lives on computer
software. It better be right.” SEPA, Chapter 1
• Example:
• Throughout the month of November, 2000 at a hospital in Panama, 28
patients received massive overdoses of gamma rays during treatment for a
variety of cancers. In the months that followed, five of these patients died
from radiation poisoning and 15 others developed serious complications.
• What caused this tragedy? A software package, developed by a U.S.
company, was modified by hospital technicians to compute modified doses of
radiation for each patient.
11
12. QUALITY AND SECURITY
• Gary McGraw comments [Wil05]:
• “Software security relates entirely and completely to quality. You must think
about security, reliability, availability, dependability—at the beginning, in
the design, architecture, test, and coding phases, all through the software
life cycle [process]. Even people aware of the software security problem have
focused on late lifecycle stuff. The earlier you find the software problem, the
better. And there are two kinds of software problems. One is bugs, which are
implementation problems. The other is software flaws—architectural
problems in the design. People pay too much attention to bugs and not
enough on flaws.”
12
13. SOFTWARE SECURITY AND RISK ANALYSIS
• Software security and risk analysis is a software quality assurance
activity that focuses on identifying and assessing potential risks that
may negatively affect software and cause the entire system to fail.
• If risks can be identified early in the software engineering process,
then software design features can be established that will eliminate
or control potential risks.
13
14. SOFTWARE SAFETY
• Software safety is a software quality
assurance activity that focuses on the
identification and assessment of
potential hazards that may affect
software negatively and cause an entire
system to fail.
• If hazards can be identified early in the
software process, software design
features can be specified that will either
eliminate or control potential hazards.
14
15. SOFTWARE SAFETY
• Once hazards are identified and analyzed, safety-related
requirements can be specified for the software.
• That is, the specification can contain a list of undesirable events and
the desired system responses to these events.
• The role of software in managing undesirable events is then
indicated.
15
16. RELIABILITY VS SAFETY
• Although software reliability and software safety are related to one
another, it is important to understand the subtle difference between
them.
• Software reliability uses statistical analysis to determine the
likelihood that a software failure will occur. However, the occurrence
of a failure does not necessarily result in a hazard or mishap.
• Software safety examines the ways in which failures result in
conditions that can lead to a mishap. That is, failures are not
considered in a vacuum but are evaluated in the context of an entire
computer-based system and its environment.
16
18. ISO 9001 STANDARDS FRAMEWORK
• An international set of standards that can be used as a basis for
developing quality management systems.
• ISO 9001, the most general of these standards, applies to
organizations that design, develop and maintain products, including
software.
• The ISO 9001 standard is a framework for developing software
standards.
• It sets out general quality principles, describes quality processes in general
and lays out the organizational standards and procedures that should be
defined. These should be documented in an organizational quality manual.
18
21. ISO 9001 STANDARD REQUIREMENTS
1. Management responsibilities
2. Quality System
3. Contract Review
4. Design Control
5. Data and document control
6. Purchase
7. Control of products supplied by
customers
8. Product identification and
traceability
9. Process Control
10. Inspection and testing
The standard contains 20 requirements that must be in place to achieve a quality
assurance system effective, namely:
21
22. ISO 9001 STANDARD REQUIREMENTS (con…)
11. Control Inspection, measurement
and test equipment
12. Check and test status
13. Control of product non-conformance
14. Preventive and corrective actions
15. Handling, storage, packing,
preservation and delivery.
16. Control of quality records
17. Internal quality audit
18. Training
19. Service
20. Statistical techniques
22
23. To become registered to one of the quality
assurance system models contained in ISO
9000, a company’s quality system and
operations are scrutinized by third-party
auditors for compliance to the standard and
for effective operation.
23
24. References
Lewis, W. E. (2009). Software Testing And Continuous Quality
Improvement ed. 3rd. Auerbach publications.
02
Majchrzak, T. A. (2012). Improving Software Testing: Technical And
Organizational Developments. Springer Science & Business Media.
03
Myers, G. J., Sandler, C., & Badgett, T. (2012). The Art Of Software
Testing. John Wiley & Sons.
04
Roger, S. P., & Bruce, R. M. (2019). Software Engineering: A
Practitioner’s Approach Ed.9th. McGraw-Hill Education.
01