8

Software Quality and Metrics

The aim of object-oriented software engineering is to build a high-quality maintainable software

system. The software quality process and assessment should begin at the start of the software
development life cycle phases. In this chapter, we describe the basic concepts, elements and
models of software quality.
The metrics are required to capture the object-oriented concepts such as coupling, cohesion,
inheritance and polymorphism. The metrics are used to assess the quality of the product or
process used to build it. We describe object-oriented metrics that capture the structural quality
of object-oriented design and source code.

8.1 What is Software Quality?

What is the meaning of the term ‘quality’? It is very important but difficult to define quality.
The Institute of Electrical and Electronics Engineers (IEEE) defines quality as:
1. The degree to which a system, component, or process meets specific requirements.
2. The degree to which a system, component, or process meets customer or user needs or
expectations.

In terms of software quality, the software must conform to both functional and non-functional
requirements specified by the customer or user. For example, if two cars meet their specified
speed, standard, style and performance, then they are said to meet the specified requirements.
If the product meets the customer’s requirements, the customer feels satisfied and the product is
expected to be of high quality. The goal of software quality is to determine:
1. How well is the design of the software?
2. How well the software conforms to the developed design?

287
288  Object-Oriented Software Engineering

8.1.1 Software Quality Attributes

Software quality can be measured in terms of attributes. The attribute domains that are required
to define for a given software are as follows:
1. Functionality
2. Usability
3. Testability
4. Reliability
5. Maintainability
6. Adaptability
These attribute domains can be further divided into attributes that are related to software quality
and are given in Figure 8.1. The details of software quality attributes are given in Table 8.1.

Figure 8.1 Software quality attributes.

Table 8.1 Software quality attributes

Functionality: The degree to which the purpose of the software is satisfied.
1 Completeness The degree to which the software is complete.
2 Correctness The degree to which the software is correct.
3 Efficiency The degree to which the software requires resources to perform a
software function.
4 Traceability The degree to which requirement is traceable to the software
design and source code.
5 Security The degree to which the software is able to prevent unauthorized
access to the program data.

Usability: The degree to which the software is easy to use.

1 Learnability The degree to which the software is easy to learn.
2 Operability The degree to which the software is easy to operate.
3 User-friendliness The degree to which the interfaces of the software are easy to use
and understand.
(Contd.)
 Software Quality and Metrics  289
Table 8.1 Software quality attributes (Contd.)
4 Installability The degree to which the software is easy to install.
5 Satisfaction The degree to which the user feels satisfied with the software.
Testability: The ease with which the software can be tested to demonstrate the faults.
1 Verifiability The degree to which the software deliverable meets the specified
standards, procedures and process.
2 Validatable The ease with which the software can be executed to demonstrate
whether the established testing criterion is met.
Reliability: The degree to which the software performs failure-free functions.
1 Robustness The degree to which the software performs reasonably under
unexpected circumstances.
2 Recoverability The speed with which the software recovers after the occurrence
of a failure.
Maintainability: The ease with which the faults can be located and fixed, quality of the
software can be improved or software can be modified in the maintenance phase.
1 Agility The degree to which the software is quick to change or modify.
2 Modifiability The degree to which the software is easy to implement, modify
and test in the maintenance phase.
3 Readability The degree to which the software documents and programs are
easy to understand so that the faults can be easily located and
fixed in the maintenance phase.
4 Flexibility The ease with which changes can be made in the software in the
maintenance phase.
Adaptability: The degree to which the software is adaptable to different technologies and
platforms.
1 Portability The ease with which the software can be transferred from one
platform to another platform.
2 Interoperability The degree to which the system is compatible with other systems.

8.1.2 Elements of a Quality System

The software quality process should start at the beginning of the software development life
cycle and should carry out throughout the software development life cycle. In order to produce
a quality product, the voice of the customer must be incorporated and then translated into
software requirements. These requirements must be properly defined and documented. Hence,
the customer’s satisfaction should be the prime concern of the developer. The quality system
consists of 10 elements as given below:
1. Standards, processes and metrics
2. Reviews and audits
3. Software testing
4. Defect management and trend analysis
5. Configuration management
6. Risk management activities
290  Object-Oriented Software Engineering

7. Supplier control
8. Training
9. Documentation
10. Safety and security
The software development life cycle consists of various phases that divide the software
development work into various parts. The software development life cycle phases are given
below:
1. Requirement analysis phase—gathering and documentation of requirements.
2. Design phase—preliminary and detailed design of the software.
3. Implementation and unit testing phase—development of source code and initial testing
of independent units.
4. Integration and system testing phase—testing the integrated parts of various units and
the system as a whole.
5. Operational phase—delivering and installing the software at the customer’s site.
6. Maintenance phase—removing defects, accommodating changes and improving the
quality of the software after it goes into the operational phase.
These phases are non-overlapping (e.g. waterfall model) or overlapping and incremental (e.g.
unified process model), depending on the type of the software development life cycle model
being used.
The elements of the quality system are related with the phases of software development
life cycle and these associations are shown in Figure 8.2. The associations depict the period
for which the element of the quality system is more closely related to the phases of software
development life cycle.

Requirement Design Implementation Integration and Operational Maintenance

analysis and unit testing system testing
Standards, processes √ √ √ √ √ √
and metrics
Reviews and audits √ √ √ √ √
Software testing √ √ √ √ √ √
Defect management √ √ √ √ √
and trend analysis
Configuration √ √ √ √ √
management
Risk analysis and √ √ √ √ √
assessment
Supplier control √ √ √ √
Training √ √ √ √ √ √
Documentation √ √ √ √ √
Safety and security √ √ √
Figure 8.2 Associations between elements of quality system and life cycle phases.

Each of the 10 elements of the quality system is discussed as follows:

 Software Quality and Metrics  291

Standards, Processes and Metrics

The standards, processes and metrics that need to be followed and can be applied in the software
development should be identified. The standards provide procedures that must be enforced
during the software development life cycle. The standards may be defined by the Institute of
Electrical and Electronics Engineers (IEEE), American National Standards Institute (ANSI), or
International Organization for Standardization (ISO).
All aspects of the software development life cycle may be covered by the standards. They
may specify the format of documentation of software requirement or may guide a developer in
developing source code by following specified coding practices and standards. The standards
that are important and feasible to apply and whose progress can be monitored must be chosen by
an organization. These standards, thus, can be enforced on the software development life cycle.
The standards should be supported by concrete, well-defined and effective processes so that
they are effectively implemented. A process is a collection of activities that are required to produce
a good quality product. An effective process is well practised, enforced, documented and measured.
The metrics must be used to measure the effectiveness of software processes and practices
followed during the software development. The metrics must be selected based on the aim to
increase the customer’s satisfaction level.

Reviews and Audits

Reviews are conducted as a part of verification activities. A detailed discussion on verification
activities is provided in Chapter 9. Reviews are very effective as they are conducted in early
phases of software development. They minimize the probability of occurrence of faults
in the earlier phases of software development, i.e. before the validation activities begin.
Reviews are cost effective and consume less cost. They increase the confidence about the
correctness of the software under development. Reviews are carried out throughout the
software development life cycle in order to verify the correctness of the documents and programs.
Reviews are of two types: formal reviews and informal reviews. The informal reviews are carried
out throughout the software development life cycle and are known as in-process reviews. Formal
reviews are carried out at the end of the software development life cycle phase.
Reviews find faults well before the validation process begins. The cost of removal of such
faults will be very reasonable as compared to those faults which we may find in the later phases
of software development. Hence, the sooner the faults are detected in the software development
life cycle, lower is the cost of the software as shown in Figure 8.3.
If an error is found and fixed in the specification and analysis phase, it hardly costs anything.
We may say this as “1 unit of cost” for fixing an error during the specification and analysis
phase. The same error, if propagated to design, may cost 10 units and, if further propagated
to coding, may cost 100 units. If it is detected and fixed during the testing phase, it may lead
to 1000 units of cost. If it could not be detected even during testing, and found by the customer
after release, the cost may increase to 10000 units.
Reviews include software requirement specification review, software design review, software
verification and validation plan or report review, user documentation review, etc. Physical and
functional audits are part of formal audits. Physical audits verify whether the final product
complies with the final documentation. Functional audits verify whether the developed software
complies with software requirements in order to check that all the requirements have been met.
292  Object-Oriented Software Engineering

Software Testing
Software testing increases the confidence in the software by assuring that the requirements have
been met. It includes both the verification and validation activities. The basic testing (refer to
Chapter 6) consists of test planning, test cases, test design and procedures, and test reports.

Figure 8.3 Phase-wise cost of fixing a fault.

Test planning starts in parallel to requirement phases of software development. The test cases
to be used in acceptance testing are also generated in this phase. By generating test cases in the
requirements phase, the requirements are verified whether they are testable or not. Each test case
includes inputs, expected results and test case pass/fail details. Test design and procedure guides
the execution of testing.
The validation testing begins as soon as the source code is available for execution. The
results generated are properly documented and recorded. Any unexpected result needs further
corrective action. Finally, the acceptance testing is carried out by the user.

Defect Management and Trend Analysis

Defect management includes fault detection and correction activities. It consists of all the record
of discrepancies observed in the software. Defect management is a part of change management
activity. The typical cycle of change request and management is shown in Figure 8.4.
The change procedure allows to manage the faults reported, fixed and closed. These records
will help in future projects in order to improve the processes so that the occurrences of some
pattern of defects can be removed or at least reduced. The defects are reported by software
defect report. The format of this report is given in Table 8.2 and the meanings of some of the
fields are given in Table 8.3.
 Software Quality and Metrics  293

Figure 8.4 Typical change procedure.

Table 8.2 Format of software defect report

Project name:
Defect reported by:
Defect description:
Defect found in:
Severity:
Priority:
Phase in which defect occurred:
Phase in which defect is found:
Process through which defect is detected:
Estimate cost of correcting the defect:
Actual cost of correcting the defect:
Defect closed by:

Table 8.3 Meaning of some fields in software defect report

Field Meaning
Severity Severity is defined as the impact of failure on the operation of the software.
It can be categorized as:
1. Critical: It could be harmful to the life of the individual or a great
threat to the existence of the organization.
2. Serious: It brings loss to the organization.
3. Moderate: It is a temporary loss or threat.
4 Trivial: It has very less impact.
Priority Priority is defined as the speed with which the defect must be addressed.
The priority can be categorized as:
1. Very high: The defect must be addressed immediately.
2. High: The defect has high impact on the existing work.
3. Medium: The defect has medium impact on the existing work.
4. Low: The defect does not interfere with the existing working.
Phase in which defect It specifies the phase of the software development life cycle in which the
occurred defect was introduced.
1. Requirement
2. Design
3. Implementation
4. Testing
5. Maintenance
(Contd.)
294  Object-Oriented Software Engineering

Table 8.3 Meaning of some fields in software defect report (Contd.)

Field Meaning
Phase in which defect is It specifies the phase of the software development life cycle in which the
found defect was detected.
1. Requirement
2. Design
3. Implementation
4. Testing
5. Maintenance
Process through which It specifies the process through which the defect is detected.
defect is detected 1. Peer Review
2. Inspection
3. Walkthrough
4. Audit
5. Testing

Configuration Management
The management of changes is very important to ensure that the state in which the software is
in is known at any given stage in the software development life cycle. It consists of identification
and record of each item of the software. This helps in keeping track of each software item at any
point of time in the project. Thus, the correct version of the software item is always known. Any
change in the document or source code is assigned a new identifier.
The configuration management also involves approving the changes suggested by anyone
during the software development. This prevents unauthorized changes being made in the software.
Thus, each change that is necessary is implemented as we move ahead in the software development
life cycle. The configuration management activities are addressed in detail in Chapter 10.

Risk Management Activities

A project may consist of several types of risks. Risk management is an essential activity in
any project. The risks can vary from availability of skilled professionals, poor communication
among developers to more severe such as identification of incorrect requirements, overrun of
budget, unable to meet delivery deadlines, improper construction of design, etc.
The risk management activities include risk identification, determining of impact of the risk,
prioritization of risk, and taking corrective actions to reduce the risks.

Supplier Control
The software that is purchased by a supplier must be assured in terms of quality. The purchased
software should meet the software requirements.

Training
Training involves educating the developer about a new technique or tool or training the users
about the software operation and use.
The quality of the software can only be assured when the developers are trained on the
various technologies or tools to be used in the project. For example, if the project requires the
use of Rational Rose software for analysis and design purpose, then the designers must be taught
 Software Quality and Metrics  295
about its use before the beginning of the analysis and design of the software. Similarly, the use
of testing tools, debugging tools, documentation standards, platforms, etc. must be taught before
they can be applied in the software development.
Once the software has been developed, the user must also be trained about the objectives
and use of the software. The purpose of user interfaces, navigation items in the software,
installation procedure of the software, data entry provisions, report generation mechanisms,
system administration part, etc. must be taught to the user. In addition, all the things required to
promote the effective use of the software must be explained to the user.
The system administrator must be taught of the environment in which the system must
run, hardware requirements of the software, handling of unexpected or exceptional event and
recovering from any failure. Security and backup mechanisms must also be explained to the
system administrator.
The software quality professional must always keep themselves updated about any need
of training of developer or users of the software. The software quality professional must also
keep informing the higher authorities about the requirement of any training session to meet the
quality of the software.

Documentation
Documentation is a very important part of the quality system. During the software development
phases, the SRS document, SDD, test plans and test cases, user manuals and system guides, etc.
must be produced. The specified documentation standards must be followed in order to create
these documents. The documentation helps strongly in the debugging process and hence the
maintenance of the product.
The documentation done in the requirement phase guides the design process and the
documentation done in the design phase serves as the basis of implementation of the software.
The documentation in the source code enhances its readability and understandability and helps
in debugging activities. The minimum documents that must be produced by any software under
development are given in Table 8.4.
Table 8.4 Recommended documentation for a software
S. No. Document name
1 Software requirement specification
2 Software design description document
3 Test plans
4 Test cases
5 Test reports
6 Risk management plan
7 User manual
8 Operation manual
9 Installation guide

Safety and Security

The safety and security of the software is essential for the project. The safety of implication
of the software failure after it is installed and the security of the program data are two major
concerns for every software project.
296  Object-Oriented Software Engineering

The safety critical software is that whose failure could have an impact on the lives of the
humans or heavy loss in terms of cost or resources. The world has seen many failures due to
small faults in the software. For example, Ariane 5 failed due to small conversion/overflow error
in the software. Similarly small error in missile causes death of many soldiers in the war. Y2K
failure and other financial software failures are also examples of the software failure.
The failures that can affect the safety of human or that can have heavy losses or hardware
damages are very critical to be identified and removed. Hence, the safety critical software should
be adequately planned, assessed, monitored and tested.
The security of the data against accidental modifications or unauthorized access is a very
critical issue. The place where the software is deployed must also be secure and protected against
any damage or destruction. The data of the software should be protected from hackers, attackers
and viruses. If the software data becomes inaccurate, it affects the software behaviour and the
results obtained will not be correct.
The software quality professional must keep the management people aware of the security
concerns. There should also be provisions of recovery from a catastrophic failure.

8.2 Software Quality Models

Many quality models are available in literature. Some popular models are discussed in subsequent
sections.

8.2.1 McCall’s Software Quality Model

McCall proposed a software quality model in 1997 which included many quality factors (McCall
1977). The aim of this software quality model is to reduce the gap between users and the
developers. The model is divided into two levels of quality attributes: quality factors and quality
criteria. The model covers quality factors from three levels of perspective: product operation
(operation characteristics of the software), product revision (the extent to which the software can
be modified), and product transition (the quality of the software to adapt to new environment)
as shown in Figure 8.5.

Figure 8.5 McCall’s software quality factors.

 Software Quality and Metrics  297
The quality of product operation depends upon correctness, efficiency, integrity, reliability,
and usability. Product revision includes maintainability, flexibility and testability. Product
transition includes portability, reusability and interoperability. Most of the quality factors are
explained in Table 8.1. The remaining quality factors are summarized in Table 8.5.

Table 8.5 Additional software quality factors

S. No. Quality factors Purpose
1 Integrity The extent to which access to software or
data by the unauthorized persons can be
controlled.
2 Flexibility The effort required to modify an operational
program.
3 Reusability The extent to which a program can be
reused in other applications.
4 Interoperability The effort required to couple one system
with another.

The second level of quality attributes is known as quality criteria and is shown in Figure 8.6.
McCall software quality management consists of 11 quality factors which are mapped into 23
quality criteria. However, users and developers are concerned with the quality factors only. The
quality criteria provide insight into the quality attributes of the system.
The quality metrics can be used to capture the aspects of the quality criteria. The subjective
assessment of the quality criteria can be made by rating them on a scale from 0 (very bad) to
10 (very good). However, the use of such assessment is difficult as different people may rate the
same criterion differently. This makes correct quality assessment almost impossible.

8.2.2 Boehm’s Software Quality Model

The second basic software quality model is given by Barry W. Boehm in 1978 (Boehm, 1978). It
is similar to McCall’s software quality model in the sense that it also presents software quality
attributes in the form of hierarchy: primitive characteristics, intermediate-level characteristics
and high-level characteristics. The levels of characteristics are shown in Figure 8.7.
The high-level characteristics represent primary use of the system. The following primary
level factors are addressed by the high-level characteristics:
 As a utility: The ease with which the software can be used in its present form.
 Maintainability: The ease with which the software can be understood, modified and
tested.
 Portability: The ease with which the software can be used by changing it from one
platform to another platform.
298  Object-Oriented Software Engineering

Figure 8.6 Software quality factors mapped into quality criteria.

The intermediate levels represent the quality that is expected from the software. The lowest
level represents the primitive metrics that will define and measure the quality of the model.
Boehm includes the characteristics of the hardware performance that are not present in McCall’s
model (Pfleeger, 2001). The human engineering aspect is sometimes very critical. The software
must be easy to access, use and understand no matter how good it is in performance. Boehm also
gives special focus on maintainability of the software.
 Software Quality and Metrics  299

Figure 8.7 Boehm’s software quality model

8.2.3 ISO 9000

The International Organization for Standardization (ISO) made different attempts to improve the
quality with ISO 9000 series. It is a well-known and widely used series. The ISO 9000 series of
standards is not only for software, but it is a series of five related standards that are applicable
to a wide range of applications such as industrial tasks including design, production, installation
and servicing. ISO 9001 is the standard that is applicable to software quality. The aim of
ISO 9001 is to define, understand, document, implement, maintain, monitor, improve and control
the following processes:
1. Management responsibility
2. Quality system
3. Contract review
4. Design control
5. Document control
6. Purchasing
7. Purchaser-supplied product
8. Product identification and traceability
9. Process control
10. Inspection and testing
11. Inspection, measuring and test equipment
12. Inspection and test status
13. Control of nonconforming product
14. Corrective action
15. Handling, storage, packaging and delivery
16. Quality records
300  Object-Oriented Software Engineering

17. Internal quality audits

18. Training
19. Servicing
20. Statistical techniques
In order to obtain ISO certification, a formal audit on the above 20 clauses is to be done and the
result of the audit should be positive for all the 20 clauses. The failure of software companies
during initial audit ranges from 60% to 70%.

8.2.4 ISO 9126

ISO 9126 is an international standard that is guided by ISO/IEC. It consists of six characteristics
given below and shown in Figure 8.8:
1. Functionality: It is an essential feature of any software product that achieves the basic
purpose for which the software is developed. For example, the LMS should be able to
maintain book details, maintain member details, issue book, return book, reserve book,
etc. Functionality includes the essential features that a product must have. It includes
suitability, accuracy, interoperability and security.
2. Reliability: Once the functionality of the software has been completed, the reliability
is defined as the capability of defect-free operation of software for a specified period
of time and given conditions. One of the important features of reliability is fault
tolerance. For example, if the system crashes, then when it recovers the system should
be able to continue its normal functioning. Other features of reliability are maturity and
recoverability.
3. Usability: The ease with which the software can be used for each specified function
is another attribute of ISO 9126. The ability to learn, understand and operate the system
is the sub-characteristics of usability. For example, the ease with which the operation
of cash withdrawal function of an ATM system can be learned is a part of usability
attribute.
4. Efficiency: This characteristic concerns with performance of the software and
resources used by the software under specified conditions. For example, if a system
takes 15 minutes to respond, then the system is not efficient. Efficiency includes time
behaviour and resource behaviour.
5. Maintainability: The ability to detect and correct faults in the maintenance phase is
known as maintainability. Maintainability is affected by the readability, understandability
and modifiability of the source code. The ability to diagnose the system for identification
of cause of failures (analysability), the effort required to test a software (testability) and
the risk of unexpected effect of modifications (stability) are the sub-characteristics of
maintainability.
6. Portability: This characteristic refers to the ability to transfer the software from one
platform or environment to another platform or environment.
 Software Quality and Metrics  301

Figure 8.8 ISO 9126 model.

The major difference between ISO 9126 and McCall and Boehm quality models is that
ISO 9126 follows a strict hierarchy. Each characteristic is related to one attribute only.

8.2.5 Capability Maturity Model

The initial version of the Capability Maturity Model (CMM) was developed at Software
Engineering Institute (SEI), Carnegie Mellon University, USA. The CMM provides a framework
which defines the key elements of an effective and efficient software process. The CMM defines
the growth path of an organization from an undisciplined, immature approach to a disciplined,
mature approach. The CMM covers key practices that help to plan, improve and manage
software development life cycle activities. These software development practices, when followed
by organizations, improve the resource utilization and quality of the software.
The CMM is categorized into five maturity levels as shown in Figure 8.9: initial, repeatable,
defined, managed and optimizing.

Figure 8.9 Levels of CMM.

Maturity Level 1: Initial

This is the lowest level and at this level, organizations do not have a stable environment for
following software engineering and management practices. This leads to ineffective planning
302  Object-Oriented Software Engineering

and management of systems. At this level, everything is carried out on an ad hoc basis. The
success of a project depends on a competent manager and a good software project team.
The absence of sound management principles cannot even be covered by strong engineering
principles. The capability of software process is undisciplined at this level as the processes
are continuously changing or being modified as the software development progresses. The
performance completely depends upon individuals rather than on the organization’s abilities. As
the process totally depends upon the individual, it changes when the staff changes. Thus, time
and cost of development are unpredictable.

Maturity Level 2: Repeatable

At level 2, procedures and policies for managing the software product are established. Planning
and managing of new software projects are not ad hoc rather they are based on the past similar
software projects. The aim is to develop effective software processes and practices that enable
the organization to repeat the successful past practices.
An effective process is one which is efficient, defined, documented and measured, and has
the ability for improvement. Unlike level 1, in this level, the managers identify problems and take
corrective actions to prevent these problems from converting into crisis. The project managers
keep track of cost and time. The standards are defined and the organizations ensure that these
standards are actually followed by the project team. Hence, the process maturity level 2 can
be described as disciplined because it is well planned, stable and past successful practices are
repeatable.

Maturity Level 3: Defined

At maturity level 3, the established processes are documented. Software processes established
at this level are used by project managers and technical staff to improve the performance more
effectively. These are known as standard software processes. The organizations also conduct a
training programme so that the staff and managers are well aware of the sources and understand
their assigned tasks.
Different projects in the organization modify the standard processes and practices to
construct their own defined software processes and practices. These defined software processes
are specific to the requirement of individual characteristics of the given project.
A well-defined process includes inputs, standards, practices and procedures to carry out the
work, verification procedures, outputs and criteria of completion. The maturity level of a process
at level 3 can be described as standard and completed.

Maturity Level 4: Managed

At this level, goals for quality of the software product are set. The organization’s measurement
program measures the quality of the software process and standards. Hence, the software
processes and standards are evaluated using measures and this helps in giving indication
of the trends of quality in processes and standards followed in the organization. The limits
specifying thresholds are established; when these limits are exceeded, then corrective action
is to be taken.
 Software Quality and Metrics  303

Maturity Level 5: Optimizing

At level 5, the focus of the organization is on continuous improvement of the software processes.
The software projects identify the causes of the software defects and evaluate software
processed to prevent defects from reoccurring. The process maturity at level 5 can be defined
as ‘continuously improving’. Improvement occurs due to advances in existing processes and
innovations using new technologies.
The maturity levels with their corresponding key process areas (KPAs) are shown in
Table 8.6.

Table 8.6 Key process areas of CMM

Maturity level Characterization Key process areas
1—Initial Ad hoc process No KPA
2—Repeatable Disciplined and mature process  Requirements management
 Software project planning
 Software project tracking and oversight
 Software subcontract management
 Software quality assurance
 Software configuration management
3—Defined Standard process  Organization process definition
 Training program
 Integrated software management
 Software product engineering
 Inter-group coordination
 Peer reviews
4—Managed Predictable process  Quantitative process management
 Software quality management
5—Optimizing Improving process  Defect prevention
 Technology change management
 Process change management

The past experience reports show that moving from level 1 to level 2 may take 3 to 5 years.
The CMM is becoming popular and many software organizations are aspiring to achieve CMM
level 5. The acceptability and pervasiveness of the CMM activities are helping the organizations
to produce a quality software.

8.3 Measurement Basics

A key element of any engineering process is measurement. Measures are used to better understand
the attributes of the model that we create. But, most important, we use measurements to assess
the quality of the engineered product or the process used to build it. Unlike other engineering
disciplines, software engineering is not grounded by the basic quantitative laws of physics.
Absolute measurements, such as voltage, mass, velocity or temperature, are uncommon in the
software world. Instead, we attempt to derive a set of indirect measures that lead to metrics that
provide an indication of the quality of some representation of software.
304  Object-Oriented Software Engineering

The following questions arise during software development:

1. How to measure the cost and development duration of the software?
2. How to estimate the size of the software?
3. How many faults can we expect?
4. What is the complexity of the module/class?
5. What is the reliability of the software?
6. Is the test suite weak or strong?
7. Are the processes appropriate?
8. Which technique is more effective?
9. When to stop testing?
10. When to release the software?
11. What about the cohesion and coupling of the module/class?
12. What is the reusability of the module/class?
The above information can only be gathered by employing metrics. These metrics will guide the
project managers in improving software product and process during the project development.

8.3.1 What are Software Metrics?

Software metrics are initiated with the belief that they will improve software engineering,
estimation and management practices. The rationale arises from the notion that “you cannot
control what you cannot measure” (DeMarco, 1982). Software measures can help address the
most critical issues in software development and provide support for planning, predicting,
controlling and evaluating the quality of both software products and processes.
Goodman (1993) defined software metrics as:
The continuous application of measurement-based techniques to the software development
process and its products to supply meaningful and timely management information, together
with the use of those techniques to improve that process and its products.

The above definition covers a lot in itself. Software metrics are related to measures which, in
turn, involve numbers for quantification. These numbers are used to produce a better product
and improve its related process. Software metrics should be gathered from the beginning, when
the cost and effort of the product is to be estimated, to the monitoring of the reliability and
maintainability of the end product.

8.3.2 Application Areas of Metrics

Software metrics have wide areas of applications. One of the most established areas of
measurement is cost and effort estimation. The project cost and effort are predicted in the early
phases of software development. There are many models available for this purpose and these
models include function point method (Albrecht and Gaffney, 1983), COCOMO81, COCOMOII
(Boehm, 1981), and Putnam resource allocation model (Putnam and Putnam, 1984). These
models are used to calculate effort (number of persons per month) or size (number of function
points or number of lines of code produced). There are various research investigations to derive
models in order to estimate the cost and effort of a project.
 Software Quality and Metrics  305
SRS is an important document produced during the software development life cycle. The
metrics can be used to measure the readability, faults found during SRS verification, change
request frequency, etc. In the design phase, the coupling and strength of modules/classes can also
be measured using metrics.
Managing and controlling software process and product is an important area of software
development. The measurement-based graphs and analysis provide customers and developers
the direction in which the software should move. Many software developers use metrics in early
phases of software development to measure the quality of the systems.
The need of prediction of software quality attributes has led to construction of various
quality models in order to measure reliability, maintainability, testability, complexity, etc. The
real benefits of these models are in large-scale systems where the testing persons are asked to
focus their attention and resources on problematic and critical areas of the system. From the
design phase, we can make software metrics captured in these models and then predict which
modules/classes will need extra attention during the remainder of development. This can help
management to focus resources on those modules/classes that cause most of the problems.
The use of metrics to provide measures of object-oriented constructs such as inheritance,
polymorphism, etc. is also a well-established area. A large number of object-oriented metrics
that are related with external software quality attributes have been designed and developed over
the last decade.
Statement coverage metrics are also available that calculate the percentage of statements in
the source code covered during testing. The effectiveness of test suite may be measured. The
testing metrics include the number of failures experienced per unit of time, the number of paths
in a control flow graph, the number of independent paths, percentage of statement coverage and
percentage of decision statements covered.
The metrics can also be used to provide meaningful and timely information to the management.
These metrics can help them to assess software quality, measure process effectiveness and
productivity of the software. Hence, this will aid the management in effective decision making.
The effective application of metrics can help the software developers to produce the quality
software within budget and on time.

8.3.3 Categories of Metrics

The metrics can be categorized by the entities we need to measure. In software development,
there are two entities that need to be measured:
1. Products are deliverables or documents produced during the software development.
2. Processes are set activities that are used to produce a product.
Processes use products produced from an activity and produce products that can be used
by another activity. For example, a requirement document is a deliverable produced by the
requirement phase and it serves as an input to the design activity. The metrics related to the
product are known as product metrics and the metrics related to the process are known as
process metrics. The process metrics measure the effectiveness of the process. These metrics
can be applied at all the phases of software development.
306  Object-Oriented Software Engineering

The process metrics can be used to:

1. measure the cost of the process.
2. measure the time taken to complete the process.
3. estimate the efficiency and effectiveness of the process in order to determine which one
is effective.
4. compare various processes in order to determine which one is effective.
5. guide future projects.
For example, during reviews we can measure the average cost consumed to find each fault by
computing the ratio of cost to the number of faults occurred in reviews.
The product metrics can be used to assess the document or a deliverable produced during
the software development life cycle. The examples of product metrics include size, functionality,
complexity and quality. Documents such as SRS, user manual, etc. can be measured for
correctness, readability and understandability.
The process and product metrics can be further categorized as internal or external attributes:
1. Internal attributes are those that are related to the internal structure of the product or the
process.
2. External attributes are those that are related to the behaviour of the product or the
process.
For example, the size of a class, structural attributes including complexity of the source code,
number of independent paths, number of statements, and number of branches can be determined
without executing the source code. These are known as internal attributes of a product or
process. When the source code is executed, the number of failures encountered, user-friendliness
of the forms and navigational items or response time of a module describe the behaviour of the
software. These are known as external attributes of a process or product. The external attributes
are related to the quality of the system. Figure 8.10 summarizes the categorization of metrics
along with their examples.

Figure 8.10 Categories of metrics.

 Software Quality and Metrics  307

8.3.4 Measurement Scale

There are two types of data—non-metric and metric. Non-metric type of data is of categorical
or discrete type. For example, gender of a person can be male or female. In contrast, metric type
of data represents amount or magnitude such as lines of source code.
Non-metric measurements can be measured either on a nominal scale or on an ordinal scale.
In the nominal scale, the categories or classes of a variable are described. A metric has nominal
scale when it can be divided into categories or classes and there is no ranking or ordering
amongst the categories or classes. Thus, the number indicates the presence or absence of the
attribute value. For example,
Ï 0, if not faulty
x=Ì
ÔÓ1, if faulty

Class x is faulty or not faulty. Thus, there are two categories of faults—either they are present
or they are not present.
Similar to nominal scales, a metric having ordinal scale can be divided into categories or
classes; however, it involves ranking or ordering. In the ordinal scale, each category can be
compared with another in terms of “higher than” or “lower than” relationship. For example, fault
impact can be categorized as high, medium, and low. Numbers can be used to represent each
category shown as follows:
Ï1, high
Ô
fault impact = Ì 2, medium
Ô
Ó3, low
The metric scale provides higher precision permitting various arithmetic operations to be
performed. Interval, ratio and absolute scales are of metric type. In the interval scale, on any
part of the scale, the difference between two adjacent points is equal. The interval scale has an
arbitrary zero point. Thus, on an interval scale, it is not possible to express any value in multiple
of some other value on the scale. For example, a day with 100°F temperature cannot be said as
twice as hot as a day with 50°F temperature. The reason is that on Celsius scale, 100°F is 37.8
and 50°F is 10. Thus, this relationship can be expressed as:
F - 32
C = 5¥
9
Ratio scales give more precision since they have all advantages of other scales plus an absolute
zero point. For example, if weight of a person is 100 kg, then he/she is twice heavier compared
to a person with 50 kg weight. Absolute scale simply represents counts. For example, the
number of faults encountered during inspections can only be measured in one way by counting
the faults encountered. Table 8.7 summarizes the differences between measurement scales with
examples.
308  Object-Oriented Software Engineering

Table 8.7 Summary of measurement scales

Measurement Measurement Characteristics Transformation Examples
type scale
Non-metric Nominal  Order not defined One-to-one Categorical classi-
 Arithmetic not involved mapping fications like type of
language (C++, Java)
Ordinal  Order defined Increasing function Student grades,
 Monotonic increasing P(x) > P(y) customer satisfaction
function (=, <, >) level, employee
 Arithmetic not involved capability levels
Metric Interval  =, <, > P = xP + y Temperatures, date
 No ratios and time
 Addition, subtraction
 Arbitrary zero point
Ratio  Absolute zero point P = xP Weight, height, length
 All arithmetic operations
possible
Absolute  Simple count values P = P Number of faults
encountered in testing

EXAMPLE 8.1 Consider the maintenance effort in terms of lines of source code added,
deleted, and changes during maintenance phase classified between 1 and 5, where 1 means very
high, 2 means high, 3 means medium, 4 means low and 5 means very low.
1. What is the measurement scale for this definition of maintenance effort?
2. Give an example to determine the criteria for estimating the maintenance effort levels for
a given class.
Solution
1. The measurement scale is ordinal since the variable maintenance effort is categorical
(consisting of classes) and involves ranking or ordering amongst categories.
2. For a given project, the following categorization may be used for maintenance effort:
Ï very high, SLOC > 10, 000
Ô
Ô high, 7000 £ SLOC < 10, 000
Ô
Maintenance effort = Ì medium, 5000 £ SLOC < 7000
Ô
Ô low, 1000 £ SLOC < 5000
ÔÓ very low, SLOC < 1000

where SLOC stands for source lines of code.

8.3.5 Axiomatic Evaluation of Metrics on Weyuker’s Properties

Several researchers recommend properties that software metrics should possess to increase
their usefulness. For instance, Basili and Reiter (1979) suggest that metrics should be sensitive
 Software Quality and Metrics  309
to externally observable differences in the development environment, and must correspond to
notions about the differences between the software artifacts being measured. However, most
recommended properties tend to be informal in evaluation of metrics. It is always desirable to
have a formal set of criteria with which the proposed metrics can be evaluated. Weyuker (1998)
has developed a formal list of properties for software metrics and has evaluated a number of
existing software metrics against these properties. Although many authors have criticized this
approach (Briand et al., 1999; Zuse, 1990), yet it is a widely known formal analytical approach.
Weyuker’s first four properties address how sensitive and discriminative the metric is. The
fifth property requires that when two classes are combined, their metric value should be greater
than the metric value of each individual class. The sixth property addresses the interaction
between two programs/classes. It implies that the interaction between program/class A and
program/class B is different than the interaction between program/class C and program/class
B given that the interaction between program/class A and program/class C is the same. The
seventh property requires that a measure to be sensitive to statement order within a program/
class is the same. The eighth property requires that renaming of variables does not affect the
value of a measure. The last property states that the sum of the metric values of a program/class
could be less than the metric value of the program/class when considered as a whole (Henderson-
Sellers, 1996).
Let u be the metric of program/class P and Q.
Property 1: This property states that
(P), (Q) [u(P)  u(Q)]
It ensures that no measure rates all programs/classes to be of the same metric value.
Property 2: Let c be a non-negative number. Then there are finite numbers of programs/
classes with metric c. This property ensures that there is sufficient resolution in the measurement
scale to be useful.
Property 3: There are distinct programs/classes P and Q such that u(P) = u(Q).
Property 4: For an object-oriented system, two programs/classes having the same functionality
could have different values.
(P) (Q) [P  Q and u(P)  (Q)]
Property 5: When two programs/classes are concatenated, their metric should be greater than
the metrics of each of the parts.
(P)(Q) [u(P)  u(P + Q) and u(Q)  u(P + Q)]
Property 6: This property suggests non-equivalence of interaction. If there are two program/
class bodies of equal metric value, they when separately concatenated to a same third program/
class, yield a program/class of different metric value.
For programs/classes P, Q, R
(P)(Q)(R) [u(P) = u(Q) and u(P + R)  u(Q + R)]
Property 7: This property is not applicable to object-oriented metrics (Chidamber and Kamerer,
1994).
310  Object-Oriented Software Engineering

Property 8: It specifies that “if P is a renaming of Q, then u(P) = u(Q)”.

Property 9: This property is not applicable to object-oriented metrics (Chidamber and Kamerer,
1994).

8.4 Analysing the Metric Data

The role of statistics is to function as a tool in analysing research data and drawing conclusions
from it. The research data must be suitably reduced so that the same can be read easily and
can be used for further analysis. Metric data can be analysed using one or many statistical
techniques and meaningful inferences can be drawn.

8.4.1 Summary Statistics for Preexamining Data

The role of statistics is to function as a tool in analysing research data and drawing conclusions
from it. The research data must be suitably reduced to be read easily and used for further
analysis. Descriptive statistics concern development of certain indices or measures to summarize
data. Data can be summarized by using measures of central tendency (mean, median and mode)
and measures of dispersion (standard deviation, variance, and quartile).

Measures of Central Tendency

Measures of central tendency include mean, median and mode. These measures are known as
measures of central tendency as they give us the idea about the central values of the data around
which all the other data points have a tendency to gather. Mean can be computed by taking
average values of the data set and is given as:
N
xi
Mean( m ) = Â
i =1 N

Median gives the middle value in the data set which means half of the data points are below
the median value and half of the data points are above the median value. It is calculated as
(1/2) (n + 1)th value of the data set, where n is the number of data points in the data set.
The most frequently occurring value in the data set is denoted by mode. The concept has
significance for nominal data.

EXAMPLE 8.2 Consider the following data set consisting of SLOC for a given project:
107, 128, 186, 222, 322, 466, 657, 706, 790, 844, 1129, 1280, 1411, 1532, 1824, 1882, 3442
Calculate mean, median and mode for it.
Solution Mean of SLOC (taking the sum of all the numbers and dividing by total data points)
= 995.7647
Median of SLOC = 790
Since each value occurs only once in the data set, there is no mode for SLOC.
 Software Quality and Metrics  311

Measures of Dispersion
Measures of dispersion include standard deviation, variance and quartiles. Measures of dispersion
tell us how the data is scattered or spread. Standard deviation calculates the distance of the
data point from the mean. If most of the data points are closer to the mean, then the standard
deviation of the variable is large. The standard deviation is calculated as given below:
2
 ( x - m)
sx =
N
Variance is a measure of variability and is the square of standard deviation.
The quartile divides the metric data into four equal parts. For calculating quartile, the data
is first arranged in ascending order. The 25% of the metric data is below the lower quartile
(25 percentile), 50% of the metric data is below the median value and 75% of the metric data is
below the upper quartile (75 percentile). Figure 8.11 shows the division of data set into four parts
by using quartiles.

Figure 8.11 Quartiles.

The lower quartile (Q1) is computed by:

1. finding the median of the data set
2. finding the median of the lower half of the data set.
The upper quartile (Q3) is computed by:
1. finding the median of the data set
2. finding the median of the upper half of the data set.
The interquartile range is calculated as the difference between the upper quartile and the lower
quartile and is given as
Interquartile range (IQR) = Q3 – Q1
EXAMPLE 8.3 Consider data set consisting of lines of the SLOC given in Example 8.2.
Calculate standard deviation, variance and quartile for it.
107, 128, 186, 222, 322, 466, 657, 706, 790, 844, 1129, 1280, 1411, 1532, 1824, 1882, 3442

1
Solution Lower quartile is the fifth value, i.e. (8 + 1)th = 322
2
Median = 790
Upper quartile is the thirteenth value = 1411.
312  Object-Oriented Software Engineering

8.4.2 Metric Data Distribution

In order to understand the metric data, the starting point is to analyse the shape of the distribution
of the data. There are a number of methods available to analyse the shape of the data. One of
them is histogram through which a researcher can gain insight into the normality of the data.
Histogram is a graphical representation of frequency of occurrences of the values of a given
variable.
Figure 8.12 shows the frequency of continuous metric variable LOC in the form of bar charts.
The bars show the frequency of values of LOC metric. The normal curve is superimposed on the
distribution of values to determine the normality of the data values of LOC. Most of the data is
left skewed or right skewed. These curves will not be applicable for discrete data (nominal or
ordinal). For example, the classes may be faulty or non-faulty. Thus, the distribution will not be
normal.

Figure 8.12 Normality curve for LOC variable.

The measures of central tendency such as mean, median and mode are all equal for normal
curves. The normal curve is like a bell-shaped curve and within three standard deviations of the
means, 96% of data occurs (Fenton and Pfleeger, 2004).

EXAMPLE 8.4 Consider the data sets given for three metric variables in Table 8.8. Determine
the normality of these variables.

Table 8.8 Data set

Fault count Cyclomatic complexity Branch count
470.00 26.00 826.00
128.00 20.00 211.00
268.00 14.00 485.00
19.00 10.00 29.00
(Contd.)
 Software Quality and Metrics  313
Table 8.8 Data set (Contd.)
Fault count Cyclomatic complexity Branch count
404.00 15.00 405.00
127.00 11.00 240.00
263.00 14.00 464.00
94.00 10.00 187.00
207.00 13.00 344.00
42.00 7.00 83.00
24.00 10.00 47.00
94.00 6.00 163.00
34.00 9.00 67.00
286.00 10.00 503.00
104.00 12.00 175.00
82.00 8.00 147.00
20.00 7.00 39.00

Solution Figure 8.13 shows the bar charts to check the normality of the variables. The mean,
median and standard deviation of the variables are given in Table 8.9. The normality of the data
can also be checked by calculating mean and median. The mean, median and mode should be
the same for a normal distribution. In Table 8.9, we compare the values of mean and median.
The values of median are less than those of mean for variables fault count and branch count.
Thus, these variables are not normally distributed. However, the mean and median of cyclomatic
complexity do not differ by a larger value.

8.4.3 Outlier Analysis

Data points, which are located in an empty part of the sample space, are called outliers. These
are the data values that are numerically distant from the rest of the data. For example, suppose
one calculates the average weight of 10 students in a class, where most are between 51 pounds
and 61 pounds, but the weight of one student is 210 pounds. In this case, the mean will be
72 pounds and the median will be 58 pounds. Hence, the median better reflects the weight of the
students than the mean. Thus, the data point with the value 210 is an outlier, that is, it is located
away from other values in the data set. Outlier analysis is done to find data points that are over
influential and removing them is essential.
Once the outliers are identified, the decision about the inclusion or exclusion of the outlier
must be made. The decision depends upon the reason why the case is identified as outlier.
There are three types of outliers: univariate, bivariate and multivariate. Univariate outliers are
those exceptional values that occur within a single variable. Bivariate outliers occur within the
combination of two variables and multivariate outliers are present within the combination of
more than two variables.
Box plots and scatter plots are two popular methods that are used for univariate and bivariate
outlier detections. Box plots are based on median and quartiles. The upper and lower quartile
statistics are used to construct a box plot. The median value is the middle value of the data
314  Object-Oriented Software Engineering

Figure 8.13 Normality curves.

Table 8.9 Descriptive statistics

Metric Mean Median Std. deviation
Fault count 156.8235 108 137.7599
Cyclomatic complexity 11.88235 10 5.035901
Branch count 259.7059 187 216.9976

set; half of the values are less than this value and half of the values are greater than this value
(Figure 8.14).

Figure 8.14 Example box plot.

 Software Quality and Metrics  315
The box starts at the lower quartile and ends at the upper quartile. The distance between the
lower quartile and the upper quartile is called box length. The tails of the box plot specify the
bounds between which all the data points must lie. The start of the tail is Q3 – 1.5 × IQR and the
end of the tail is Q3 + 1.5 × IQR. These values are truncated to the nearest values of the actual
data points in order to avoid negative values. Thus, the actual start of the tail is the lowest value
in the variable above (Q3 – 1.5 × IQR) and the actual end of the tail is the highest value below
(Q3 + 1.5 × IQR).
Any value outside the start of the tail and the end of the tail is outlier and these data points
must be identified as they are unusual occurrences of data values which must be considered for
inclusion or exclusion. The box plots also tell us whether the data is skewed or not. If the data is
not skewed, the median will lie in the centre of the box. If the data is left or right skewed, then
the median will be away from the centre. For example, consider the LOC values for a sample
project given below:
17, 25, 36, 48, 56, 62, 78, 82, 103, 140, 162, 181, 202, 251, 310, 335, 508
The box plot for the given data set is shown in Figure 8.15 with an outlier case number 17. The
median of the data set is 103, lower quartile is 56 and upper quartile is 202. The interquartile range
is 146. The start of the tail is 202 – 1.5 × 146 = –17 and end of the tail is 202 + 1.5 × 146 = 421.
The actual start of the tail is the lowest value above –17, i.e. 17 and the actual end of the tail is
the highest value below 421, i.e. 335, as shown in Figure 8.15. Thus, the case number 17 with
value 508 is above the end of the tail and hence is an outlier.

Figure 8.15 Box plot of LOC metric.

EXAMPLE 8.5 Consider the data set given in Example 8.3. Construct box plots and identify
univariate outliers for all the variables in the data set.
316  Object-Oriented Software Engineering

Solution The box plots for LOC, fault count, cyclomatic complexity and branch count using
univariate analysis are shown in Figures 8.16–8.19.

Figure 8.16 Box plot for LOC metric.

Figure 8.17 Box plot for fault count metric.

 Software Quality and Metrics  317

Figure 8.18 Box plot for cyclomatic complexity metric.

Figure 8.19 Box plot for branch count metric.

The outliers should be analysed by the researchers to make a decision about their inclusion
or exclusion in the data analysis. There may be many reasons for an outlier: (i) error in the entry
of the data, (ii) some extra information that represents extraordinary or unusual event and (iii)
an extraordinary event that is unexplained by the researcher.
Outlier values may be present due to the combination of data values present across more than
one variable. These outliers are called multivariate outliers. Scatter plot is another visualization
method to detect outliers. In scatter plots, we simply represent graphically all the data points. The
scatter plot allows us to examine more than one metric variable at a given time. The univariate
outliers can also be determined by calculating the z-score value of the data points of the variable.
The data values exceeding ±2.5 are considered to be outliers (Hair et al., 2006).
318  Object-Oriented Software Engineering

EXAMPLE 8.6 Consider the data set given in Example 8.3. Identify bivariate outliers between
dependent variable fault count and other variables.
Solution The scatter plots are shown in Figures 8.20–8.22.

Figure 8.20 Scatter plot for cyclomatic complexity metric.

Figure 8.21 Scatter plot for branch count metric.

 Software Quality and Metrics  319

Figure 8.22 Scatter plot for LOC metric.

EXAMPLE 8.7 Consider the data set given in Example 8.3. Identify outliers by computing
z-score values.
Solution After computing the z-score values for all the given metrics, the following case
numbers are found to be influential (Table 8.10).

Table 8.10 Influential case numbers

Variable Case number
Cyclomatic complexity 1
LOC 1
Fault count None
Branch count 1

8.4.4 Correlation Analysis

Correlation analysis studies the variation of two or more variables for determining the amount
of correlation between them. Hopkins (2003) calls a correlation coefficient value between 0.5
and 0.7 large, 0.7 and 0.9 very large, and 0.9 and 1.0 almost perfect. Correlation analysis can be
used to find the relationship among the metrics. This tells whether the metrics are independent
or contain redundant information.

8.4.5 Exploring Analysis

The metric variables can be of two types—independent variables and dependent (target)
variables. The effect of independent variables on the dependent variables can be explored by
320  Object-Oriented Software Engineering

using various statistical and machine learning methods. The choice of the method for analysing
the relationship between independent and dependent variables depends upon the type of the
dependent variable (continuous or discrete).
If the dependent variable is continuous, then the widely known statistical method (linear
regression method) may be used, whereas if the dependent variable is of discrete type, then
logistic regression method may be used for analysing relationships.

8.5 Metrics for Measuring Size and Structure

There are a range of metrics available to measure the size and structure of a software system.
Size metrics can be used to estimate the size of the software, input to estimation models and
can be used to monitor the progress during software development. The structural metrics helps
us to analyse the product and increase the understanding of the product. They may also provide
insight into the complexity of the software. In the below sections, we define size and structure
metrics.

8.5.1 Size Estimation

The measurement of size is a very important and difficult area in software development. Size
metrics give an indication about the length of the source code. The physical quantities such as
mass, velocity or temperature are easily measurable, but measuring the size of the software is
difficult. The most commonly used size metric is lines of source code (LOC). There are many
ways in which they can be counted. For example, many programs use comment lines and blank
lines to make their programs more understandable and readable.
In true sense, programming effort is required in order to include blank lines and comment
lines. Thus, these lines may be excluded from the count of lines of source code. Similarly,
unexecutable statements are also not included by some programmers in the LOC count. Hence,
the programmer must be careful while selecting the method for counting LOC. Consider the
operation to check the validity of a triangle given in Figure 8.23.

/*This function checks for validity of a triangle*/

int triangle(int a, int b, int c)
{
int valid;
if((a+b)>c)&&((c+a)>b)&&((b+c)>a)
//checks validity
{
valid=1;
}
else
{
valid=0;
}
return valid;
}
Figure 8.23 Operation to check validity of a triangle.
 Software Quality and Metrics  321
The function in Figure 8.23 consists of 15 LOC, if we simply count the number of LOC.
Most programmers and researchers exclude blank lines and comment lines as these lines do
not consume any effort and only give illusion of high productivity of the staff that is measured in
terms of LOC/PM (lines of source code/person month). The LOC count for the function shown
in Figure 8.23 after excluding the blank and comment lines is 13. This value of LOC follows the
definition of LOC given by Conte et al. (1986).
LOC can be used to provide estimation of programming time and also serves as input to
many estimation models such as COCOMO, COCOMO II, etc. However, their usefulness is
limited to other non-functional tasks such as reliability, efficiency, usability, etc. The number
of classes is also an important count for measuring size of object-oriented software. The size
metrics related to object-oriented software are described in Section 8.7.
The functional units can be counted in the early phases of software development. In object-
oriented software development, the functionality of a software can be depicted in terms of use
cases and classes. The use case point and class point method are used to count the functional
units in object-oriented software development and have been explained in Chapter 4 (refer to
Sections 4.3 and 4.4).

8.5.2 Halstead Software Science Metrics

Halstead developed a suite of software science measures in the early 1970s. These metrics see
a program in terms of tokens that are classified as operators or operands. Any keyword or
symbol in a program is considered as an operator, while any symbol used to represent data is
considered as an operand. Variables, constants and labels are considered to be operands, whereas
arithmetic operators such as +, –, /, * and keywords such as ‘int’, ‘printf’, ‘for’, ‘while’ and
function names are counted as operators. Operators also include braces, parameters and even
names of the operations (reserved keywords). The basic metrics to count the vocabulary of a
program are given as follows:
h1 = number of unique operators
h2 = number of unique operands
h = vocabulary of a program
h = h1 + h2
Program length is calculated in terms of the total number of tokens given as:
    N1 = total occurrences of operators
    N2 = total occurrences of operands
  Length: N = N1 + N2
Program length can also be expressed in terms of LOC as:
N = 2 × LOC
The volume of the program is interpreted as the number of mental comparisons needed to write
as the given program and is given as:
Volume: V = N × log2 (n1 + n2)
322  Object-Oriented Software Engineering

The unit of measurement of volume is ‘bits’. A program can be implemented in various ways,
potential volume (V*) represents the program with minimal value. The program level is given as:
Level: L = V*/V
The difficulty is the inverse of program level:
Difficulty: D = 1/L
The potential volume of an algorithm is implemented as a procedure call and is given below:
V* = (2 + n 1*) log2(2 + n 2*)
The first term is 2 which represents two unique operators for the procedure call. The second term
n 2* represents the number of conceptually unique input and output parameters of a procedure.
The estimated program level and volume are given as:
2 n
L= ¥ 2
        n1 N 2

1
   Difficulty: D=
L
h1 N 2
          =
2h2
V
    Effort: E =
L
E
Program time: T =
b
b is normally equal to 18. The metrics proposed by Halstead can also be applied to object-
oriented software.

EXAMPLE 8.8 Consider the function to check the validity of a triangle given in Figure 8.23.
List out the operators and operands and also calculate the values of software science metrics.
Solution The list of operators and operands is given in Table 8.11.

Table 8.11 Tokens for the program given in Figure 8.23

Operators Occurrences Operands Occurrences
int 4 triangle 1
{} 3 a 4
if 1 b 4
+ 3 c 4
> 3 valid 4
&& 2 1 1
= 2 0 1

(Contd.)
 Software Quality and Metrics  323
Table 8.11 Tokens for the program given in Figure 8.23 (Contd.)
Operators Occurrences Operands Occurrences
else 1
return 1
; 4
, 2
() 7
h1 = 12 N1 = 33 h2 = 7 N2 = 19

h = h1 + h2
= 12 + 7 = 19
N = N1 + N 2
= 33 + 19 = 52
V = N ¥ log2 (n1 + n2 )
= 52 ¥ log2 19
= 52 ¥ 4.249 = 220.96 bits
N = h1 log2 n1 + h2 log2 n2
= 12 log2 12 + 7 log2 7
= 43.02 + 19.65 = 62.67

V * = (2 + n1* ) log2 (2 + n2* )

= (2 + 4) log2 (2 + 4)
= 6 log2 6 = 15.5
2 n
L = ¥ 2
n1 N 2
2 7
= ¥ = 0.0614
12 19
1
D = = 16.29
L
E =V ¥D
= 220.96 ¥ 16.29 = 3599.44

E 3599.44
T = = = 199.97 s
b 18
= 3.33 min
324  Object-Oriented Software Engineering

8.5.3 Information Flow Metrics

Information flow metrics represent the coupling (degree of interdependence between classes) in
the system. A system is said to be highly coupled if its classes accept information from and/or
pass information to other classes. The aim of the developer should be to minimize coupling, as
high-coupled systems tend to be less reliable and maintainable. Fan-in and fan-out refer to the
number of classes collaborating with each other and are defined as follows:
1. Fan-in: It counts the number of other classes that call a given class A.
2. Fan-out: It counts the number of other classes called by a given class A.
Figure 8.24 shows values of fan-in and fan-out for a small system consisting of six classes.

Figure 8.24 Fan-in and fan-out metrics for six systems.

A low fan-out value is desirable since high fan-out values represent large amount of coupling
present in the system.

8.6 Measuring Software Quality

Software quality should be an essential practice in software development and thus arises the
need of measuring the aspects of software quality. Measuring quality attributes will guide the
software professionals about the quality of the software. Software quality must be measured
throughout the software development life cycle phase.

8.6.1 Software Quality Metrics Based on Defects

According to the IEEE/ANSI standard, defect can be defined as “an accidental condition that
causes a unit of the system to fail to function as required”. A fault can cause many failures; hence,
there is no one-to-one correspondence between fault and a failure. The defect-based metrics can
 Software Quality and Metrics  325
be classified at product and process levels. The difference of these two terms fault and defect
is unclear from the definitions. In practice, the difference in the terms is not significant and
these terms are used interchangeably. The defect density and defect rate are two popular product
metrics used for measuring defects.

Defect Density
Defect density can be measured as the ratio of the number of defects encountered to the size of
the software. Size of the software is usually measured in terms of thousands of lines of code
(KLOC) and is given as:
Number of defects
Defect density =
KLOC

The number of defects counts the defects detected during testing or by using any verification
technique.
Defect rate can be measured as the number of defects encountered over a period of time
such as per year. The defect rate may be useful in predicting the cost and resources that will be
utilized in maintenance phase of software development. Another useful metric is defect density
during testing. It measures the defect density during the formal testing, i.e. after the source code
has been formally completed and added in the software library. If the value of defect density
metric during testing is high, then the tester should ask the following questions:
1. Is the software not well designed or developed?
2. Is the testing technique effective in detecting defects?
If the reason of higher defects is the first one, then the software should be tested thoroughly so
that higher defects are revealed. If the reason of higher defects is the second one, then the quality
perspective of the software is good.

Phase-based Defect Density

It is an extension of defect density metric. The defect density can be tracked at various phases
of software development including verification activities such as reviews, inspections and formal
reviews before the start of validation testing. This metric provides an insight into the processes
and standards being used during software development. Some organizations even set ‘threshold
values’ for these metrics in order to monitor and assess the quality of the software.

Defect Removal Effectiveness

Defect removal effectiveness (DRE) is defined as:
Defects removed in a given life cycle phase
DRE =
Latent defects

Latent defects for a given phase is not known. Thus, they are estimated as the sum of defects
removed during a phase and defects detected later. The higher the value of the metric, the more
326  Object-Oriented Software Engineering

efficient and effective is the process followed in a particular phase. The ideal value of DRE is 1.
The DRE of a product can also be calculated by
DB
DRE =
DB + DA

where DB is defects encountered before software delivery and DA is defects encountered after
delivery.

8.6.2 Usability Metrics

Usability metrics measure the ease of use, learnability and user satisfaction for a given software.
Bevan (1995) measured usability under MUSIC project. In MUSIC project, a number of
performance measures are proposed. The task effectiveness is defined as follows:
1
Task effectiveness = ¥ (quantity ¥ quality)%
100
where quantity measures the amount of task completed by a user and quality measures the
degree to which the output produced by the user satisfies the goals of the task.
Both quantity and quality are represented in percentages. For example, consider a task of
proofreading a three-page document. The quantity specifies the percentage of ratio of the number
of words proofread to the total number of words. The quality is calculated as the percentage of
proportion of the correctly proofread document. If the quantity is 80% and the quality is 90%,
then task effectiveness is 72%.
The other measures of use defined in MUSIC project are (Bevan, 1995):
Effectiveness
Temporal efficiency =
Task time
Task time - Unproductive time
Productive period = ¥ 100
Task time
User efficiency
Relative user efficiency = ¥ 100
Expert efficiency

The other measures that can be used to measure the usability of the system are as follows:
1. Time required to learn a system
2. Total increase in productivity by the use of the system
3. Response time
Conducting a survey based on a questionnaire is an effective means to measure the satisfaction
of the customer. The questionnaire should be developed by experience persons having technical
knowledge. The sample size should be sufficient enough to build the confidence level on
the survey results. The results rated on scale (for example, very satisfied, satisfied, neutral,
dissatisfied, very dissatisfied) may be used for measuring satisfaction level of the customer.
 Software Quality and Metrics  327
The quality charts such as bar charts, scatter plots, line charts, etc. should be built to analyse
the satisfaction level of the customer. The customer satisfaction must be continuously monitored
over time.

8.6.3 Testing Metrics

The testing metrics can be used to monitor the status of testing and provides indication about
the quality of the product.
Testing coverage metrics can be used to monitor the amount of testing being done. These
include the following basic coverage metrics:
1. Statement coverage metric describes the degree to which statements are covered while
testing.
2. Branch coverage metric determines whether each branch in the source code has been
tested.
3. Operation coverage metric determines whether every operation of a class has been tested.
4. Condition coverage metric determines whether each condition is evaluated both for true
and for false.
5. Path coverage metric determines whether each path of the control flow graph has been
exercised or not.
6. Loop coverage metric determines how many times a loop is covered.
7. Multiple condition coverage metric determines whether every possible combination of
conditions is covered.
NASA has given a test focus metric which determines the amount of effort spent in finding and
fixing ‘real’ faults in the software versus the amount of effort spent in finding and fixing ‘fake’
faults in the software. The test focus (TF) metric is given as (Stark et al., 1992):
Number of STRs fixed and closed
TF =
Total number of STRs

where STR is software trouble report.

The fault coverage metric (FCM) is given as:
Number of faults addressed ¥ Severity of faults
FCM =
Total number of faults ¥ Severity of faults

Some of the basic process metrics are given below:

1. Number of test cases designed
2. Number of test cases executed
3. Number of test cases passed
4. Number of test cases failed
5. Test case execution time
6. Total execution time
7. Time spent for the development of a test case
8. Total time spent for the development of all test cases
328  Object-Oriented Software Engineering

On the basis of the above direct measures, we may design the following additional metrics so
that more useful information can be gained from the basic metrics:
1. Percentage of test cases executed
2. Percentage of test cases passed
3. Percentage of test cases failed
4. Total actual execution time/total estimated execution time
5. Average execution time of a test case

8.7 Object-Oriented Metrics

Object-oriented systems are rapidly increasing in the market. Object-oriented software
engineering leads to better design, higher quality and maintainable software. As the object-
oriented development is growing, the need for object-oriented metrics that can be used across the
software industry is also increasing. The traditional metrics, although applicable to object-oriented
systems, do not measure object-oriented constructs such as inheritance and polymorphism. This
need has led to the development of object-oriented metrics. In the following subsections, we
define coupling, cohesion, inheritance, reuse and size metrics for object-oriented systems.

8.7.1 Coupling Metrics

The degree of interdependence between classes is defined by coupling. During object-oriented
analysis and design phases, coupling is measured by counting the relationship a class has
with other classes or systems. Coupling increases complexity and decreases maintainability,
reusability and understandability. Hence, coupling should be reduced amongst classes and the
classes should be designed with the aim of weak coupling. The developer’s goal should be
to eliminate extraneous coupling (Henderson-Sellers, 1996). Chidamber and Kemerer (1994)
defined coupling as:
Two classes are coupled when methods declared in one class use methods or instance variables
of the other classes.

This definition also includes coupling based on inheritance. In 1994, Chidamber and Kemerer
defined coupling between objects (CBO). In their paper, they defined CBO as the count of the
number of other classes to which a class is coupled. The CBO definition given in 1994 includes
inheritance-based coupling. For example, consider Figure 8.25. Two variables of other classes
(class B and class C) are used in class A; hence, the value of CBO for class A is 2. Similarly, for
class B and class C, the value of CBO is zero.

Figure 8.25 Values of CBO metric for a small program.

 Software Quality and Metrics  329
Li and Henry (1993) used the data abstraction technique for defining coupling. Data
abstraction provides the ability to create user-defined data types called abstract data types
(ADTs). Li and Henry defined data abstraction coupling (DAC) as:
DAC = Number of ADTs defined in a class
In Figure 8.25, class A has two ADTs (i.e. two non-simple attributes) objB and objC. Li and
Henry defined another coupling metric known as message passing coupling (MPC) as “the
number of unique sent statements in a class”. Hence, if four different methods in class A access
the same method in class B, then MPC is 4 as shown in Figure 8.26.

Figure 8.26 Example of MPC metric.

Chidamber and Kemerer (1994) defined response for a class (RFC) metric as a set of methods
defined in a class and called by a class. It is given by RFC = | RS |, where RS, the response set
of the class, is given by:
RS = Mi  all j{Rij}
where Mi = set of all methods in a class (total n) and Ri = {Rij} = set of methods called by Mi.
For example, in Figure 8.27, the RFC value for class A is 9 and the method for calculating it is
explained in the given example.

Class consists of four functions: A1, A2, A3, A4

A1 calls B1 and B2 of class B
A2 calls C1 of class C
A3 calls D1 and D2 of class D
Thus, RFC = | RS |
Mi = {A1, A2, A3, A4}
Rij = {B1, B2, C1, D1, D2}
RS = {A1, A2, A3, A4, B1, B2, C1, D1, D2}
RFC = 9

Figure 8.27 Example for RFC metric.

A system level metric, coupling factor, is also defined by Harrison et al. (1998). In 1997,
Briand et al. (1997) gave a suite of 18 metrics that measured different types of interaction
between classes. These metrics may be used to guide software developers about which type of
coupling affects maintenance cost and reduces reusability. Briand et al. (1997) observed that the
coupling between classes can be divided into different facets:
330  Object-Oriented Software Engineering

1. Relationship: It refers to the type of relationship between classes—friendship,

inheritance, or other.
2. Export or import coupling: This identifies whether class A uses methods/variables of
other class B (import).
3. Type of interaction: Briand et al. identified three types of interaction between classes—
class-attribute, class-method and method-method.
(i) Class-attribute (CA) interaction: For example, consider Figure 8.28, class A
consists of two non-simple attributes objA and objB of type class B and class C,
respectively. Thus, if there is any change in class B and/or class C, class A will be
affected.
(ii) Class-method (CM) interaction: If the parameter of class B is passed as argument
to method of class A, the type of interaction is said to be class-method. For example,
consider class A given in Figure 8.28. There is a CM interaction between method
A1 and class B as method A1 uses the object of class B as parameter.
(iii) Method-method (MM) interaction: If a method Mi of class Ci calls method Mj of
class Cj or method Mi of class Ci consists of reference of method Mj of class Cj as
arguments, then there is MM type of interaction between class Ci and class Cj. For
example, as shown in Figure 8.28, the method of class B calls method A1 of class
A; hence, there is an MM interaction between class B and class A.

class A
{
B objB;
C objC;
public:
void A1(B obj1)
{
}
};
class B
{
public:
void B1()
{
A objA
A1();
}
};
class C
{
void A2(B::B1)
{
}
};

Figure 8.28 Example for computing type of interaction.

 Software Quality and Metrics  331
The metrics for CA are FCAIC, ACSIC, OCAIC, FCAEC, DCAEC and OCEEC. In these
metrics, the first one/two letters signify the type of relationship (IF signifies inverse friendship,
A signifies ancestors, D signifies descendant, F signifies friendship, and O signifies others).
The next two letters signify the type of interaction (CA, CM, MM). Finally, the last two letters
signify import coupling (IC) or export coupling (EC).
Lee et al. (1995) differentiate between inheritance-based and non-inheritance-based coupling
by the corresponding measures: Non-inheritance information flow-based coupling (NIH-ICP),
and information flow-based inheritance coupling (IH-ICP). Information flow-based coupling
(ICP) metric was the sum of NIH-ICP and IH-ICP metrics. Lee et al. emphasized that their ICP
metric, based on method invocation, take polymorphism into account.

8.7.2 Cohesion Metrics

Cohesion is a desirable property of a class and should be maximized as it supports the concept of
data hiding. Low cohesive class is more complex and is more prone to faults in the development
life cycle. Chidamber and Kemerer (1994) proposed lack of cohesion in methods (LCOM) metric
in 1994. The LCOM metric measures the dissimilarity of methods in a class by finding the
attributes used by the methods.
It calculates the difference between the number of methods that have similarity zero and
the number of methods that have similarity greater than zero. If the difference is negative, then
the value of LCOM is zero. The larger the similarity between methods, the more cohesive is the
class. For example, a class consists of four attributes (a1, a2, a3 and a4). The method usage of the
class is given is Figure 8.29.

M1 = {a1, a2, a3, a4}

M2 = {a1, a2}
M3 = {a3}
M4 = {a3, a4}
M1  M2 = 1
M1  M3 = 1
M1  M4 = 1
M 2  M3 = 0
M2  M4 = 0
M3  M4 = 1
LCOM = 2 – 4, hence, LCOM = 0

Figure 8.29 Example of LCOM metric.

Henderson-Sellers (1996) observed some problems in the definition of LCOM metric

proposed by Chidamber and Kemerer in 1994. The problems were as follows:
1. A number of real examples showed the value of LCOM as zero due to the presence
of dissimilarity amongst methods. Hence, while a large value of LCOM suggests low
cohesion, the zero value does not necessarily suggest high cohesion.
2. No guideline for interpretation of the value of LCOM was given by Chidamber and
Kemerer. Thus, Henderson-Sellers revised the LCOM value. Consider m methods
332  Object-Oriented Software Engineering

accessing a set of attributes Di (i = 1, ..., n). Let the number of methods that access each
datum be m(Di). The revised LCOM1 metric is given as:
n
1
N
 m (Di ) - m
i =1
LCOM1 =
1- m
Beiman and Kang (1995) defined two cohesion metrics: tight class cohesion (TCC) and loose
class cohesion (LCC). The TCC metric is defined as the percentage of pairs of directly connected
public methods of the class with common attribute usage. The LCC metric is the same as TCC,
except that it also considers indirectly connected methods. A method M1 is said to be indirectly
connected with method M3, if M1 is connected to method M2 and method M2 is connected
to method M3. Hence, indirectly connected methods represent transitive closure of directly
connected methods. Consider the source code of a queue class given in Figure 8.30 (Beiman
and Kang, 1995).

class queue
{
private:
int *a;
int rear;
int front;
int n;
public:
queue(int s)
{
n=s;
rear=0;
front=0;
a=new int[n];
}
int empty()
{
if(rear==0)
{
return 1;
}
else
{
return 0;
}
}
void insert(int);
int remove();
int getsize()

Figure 8.30 (Contd.)

 Software Quality and Metrics  333

{
return n;
}
void display();
};
void queue::insert(int data)
{
if(rear==n)
{
cout<<“Queue overflow”;
}
else
{
a[rear++]=data;
}
}
int queue::remove()
{
int element,i;
if(empty())
{
cout<<“Queue underflow”;
getch();
}
else
{
element=a[front];
for(i=0;i<rear-1;i++)
{
a[i]=a[i+1];
}
rear--;
}
return element;
}
void queue::display()
{
int i;
for(i=0;i<rear;i++)
{
cout<<a[i]<<“ “;
}
getch();
}

Figure 8.30 Source code for implementing queue class.

Figure 8.31 shows the attribute usage of methods. The pair of public functions with common
attribute usage is given below:
{(empty, insert), (empty, remove), (empty, display), (getsize, insert), (insert, remove),
   (insert, display), (remove, display)}
334  Object-Oriented Software Engineering

Thus,
7
TCC(Queue) = ¥ 100 = 70%
10
The methods empty and getsize are indirectly connected, since empty is connected to insert and
getsize is also connected to insert. Thus, by transitivity, empty is connected to getsize.
Thus,
10
LCC(Queue) = ¥ 100 = 100%
10

Figure 8.31 Attribute usage of methods of class queue.

Lee et al. (1995) proposed information flow-based cohesion (ICH) metric. ICH for a class is
defined as the weighted sum of the number of invocations of other methods of the same class,
weighted by the number of parameters of the invoked method. In Figure 8.31, the method remove
invokes the method empty which does not consist of any arguments. Thus, ICH (Queue) = 1.

8.7.3 Inheritance Metrics

The inheritance is measured in terms of depth of inheritance hierarchy by many authors in
the literature. The depth of a class within an inheritance hierarchy is measured by depth of
inheritance tree (DIT) metric given by Chidamber and Kemerer (1994). It is measured as the
number of steps from the class node to the root node of the tree. In the case of involving multiple
inheritances, the DIT will be the maximum length from the node to the root of the tree. Consider
Figure 8.32. The value of the DIT metric for class D is 2.

Figure 8.32 Inheritance hierarchy.

 Software Quality and Metrics  335
The average inheritance depth (AID) is calculated as (Yap and Henderson-Sellers, 1993):

AID =
 Depth of each class
Total number of classes
In Figure 8.32, the depth of subclass D is 1.5 [(2 + 1)/2].
The AID of overall inheritance structure is: 0(A) + 1(B) + 0(C) + D(1.5) + E(1) + 0(F) = 3.5.
Finally, dividing by the total number of classes, we get 3.5/6 = 0.58.
Number of children (NOC) metric counts the number of immediate subclasses of a class
in a hierarchy. In Figure 8.32, the NOC value for class A is 1 and for class E it is 2. Lorenz
and Kidd developed number of parents (NOP) metric which counts the number of classes
that a class directly inherits (i.e. multiple inheritance) and number of descendants (NOD) as
the number of subclasses of a class (both directly and indirectly). Number of ancestors (NOA)
given by Tegarden and Sheetz (1992) counts the number of base classes of a class (both directly
and indirectly). Hence, in Figure 8.32, NOA(D) = 3 (A, B, C), NOP(D) = 2 (B, C) and NOD(A)
= 2 (B, D).
Lorenz and Kidd (1994) gave three measures: number of methods overridden (NMO),
number of methods added (NMA) and number of methods inherited (NMI). When a method
in a subclass has the same name and type (signature) as in the superclass, then the method in
the superclass is said to be overridden by the method in the subclass. NMA counts the number
of new methods (neither overridden nor inherited) added in a class. NMI counts the number of
methods a class inherits from its superclasses. Finally, Lorenz and Kidd use NMO, NMA and
NMI metrics to calculate specialization index (SIX) as given below:
NMO ¥ DIT
SIX =
NMO + NMA + NMI

Consider the source code given in Figure 8.33. The class student overrides two methods of class
person—readperson() and displayperson(). Thus, the value of the NMO metric for class student
is two. One new method is added in this class (getaverage). Hence, the value of NMA metric is 1.
Similarly, for class GradStudent, the value of NMO is 2, NMA is 1 and NMI is 1
(getaverage( )). The value of SIX for class GradStudent is given by
2¥2 4
SIX = = =1
2 +1+1 4

The maximum number of levels in the inheritance hierarchy which is below the class is measured
through class to leaf depth (CLD). The value of CLD for class person is 2.

8.7.4 Reuse Metrics

An object-oriented development environment supports design and code reuse, the most
straightforward type of reuse being the use of a library class (of code), which perfectly suits the
requirements. Yap and Henderson-Sellers (1993) discuss two measures designed to evaluate the
level of reuse possible within classes.
336  Object-Oriented Software Engineering

class Person {
protected:
char name[25];
int age;
public:
void readperson();
void displayperson();
};
class Student extends Person{
protected:
roll _ no[10];
float average;
public:
void readstudent();
void displaystudent();
float getaverage();
};
class GradStudent extends Student{
private:
char subject[25];
char working[25];
public:
void readit();
void displaysubject();
void workstatus();
};

Figure 8.33 Source code to demonstrate use of inheritance.

The reuse ratio (U) is given by

Number of superclasses
U =
Total number of classes

Consider Figure 8.33, the value of U is 2/3. Another metric is specialization ratio (S), which is
given by
Number of subclasses
S=
Number of superclasses

In Figure 8.33, number of subclasses = {Student, GradStudent} and number of superclasses =

{Person, Student}. Thus, S = 1.
Aggarwal et al. (2009) proposed another set of metrics for measuring reuse by using generic
programming in the form of templates. The metric function template factor (FTF) is defined as
the ratio of the number of functions using function templates to the total number of functions as
shown below:
Number of functions using function templates
FTF =
Total number of functions
 Software Quality and Metrics  337
Consider a system, with methods F1, ..., Fn. Then,
n
 uses_FT(Fi )
i =1
FTF = n
 Fi
     i =1

Ï1, iff function uses function template ¸

where, uses_FT(Fi ) = Ì ˝
ÓÔ 0, otherwise ˛Ô

void function1(){
.........}
template<class T>
void function2(T &x, T &y){
.........}
void function3(){
........}
Figure 8.34 Source code for calculating metric FTF.

In Figure 8.34, the value of metric FTF = 1/3.

The metric class template factor (CTF) is defined as the ratio of the number of classes using
class templates to the total number of classes as shown below:
Number of classes using class templates
CTF =
Total number of classes

Consider a system, with classes C1, ..., Cn. Then,

n
 uses_CT(Ci )
i =1
CTF = n
 Ci
  i =1

Ï1, iff class uses class template ¸

where, uses_CT(Ci ) = Ì ˝
ÔÓ 0, otherwise Ô˛

class A{
.....};
template<class T, int size>
class B{
T arr[size];
....};
Figure 8.35 Source code for calculating metric CTF.

In Figure 8.35, the value of metric CTF = 1/2.

338  Object-Oriented Software Engineering

8.7.5 Size Metrics

Several traditional metrics are applicable to object-oriented systems. The traditional LOC metric
is a measure of the size of a class (refer to Section 8.3.1). Halstead’s software science and McCabe’s
measures for measuring size are also applicable to object-oriented systems; however, the object-
oriented paradigm defines a different way of doing things. This has led to the development of
size metrics applicable to object-oriented constructs. Chidamber and Kemerer defined weighted
methods per class (WMC) metric given by:
n
WMC = Â Ci
i=1

where M1, ..., Mn are methods defined in class K1 and C1, ..., Cn are the complexity of the methods.
The number of attributes (NOA), given by Lorenz and Kidd, is defined as the sum of the
number of instance variables and number of class variables. Number of methods (NOM) given
by Li and Henry (1993) is defined as the number of local methods defined in a class. They also
gave two additional size metrics SIZE1 and SIZE2 besides the LOC metric given as:
SIZE1 = number of semicolons in a class
SIZE2 = NOA + NOM

8.7.6 Popular Metric Suites

The number of recognized metric suites is limited in the literature. The object-oriented metrics
that have widely gained attention are summarized as follows:
1. Metric suite consisting of six metrics is proposed by Chidamber and Kemerer (1994).
This metric suite has received widest attention in the literature. The metric suite along
with the constructs it measures is summarized in Table 8.12.

Table 8.12 Chidamber and Kemerer metrics

Metric Definition Construct being measured
CBO Coupling between objects Coupling
WMC Weighted methods per class Size
RFC Response for a class Coupling
LCOM Lack of cohesion in methods Cohesion
NOC Number of children Inheritance
DIT Depth of inheritance Inheritance

2. Li and Henry (1993) investigated Chidamber and Kemerer metrics and proposed a suite
of five metrics. These metrics are summarized in Table 8.13.
 Software Quality and Metrics  339
Table 8.13 Li and Henry metric suite
Metric Definition Construct being measured
DAC Data abstraction coupling Coupling
MPC Message passing coupling
NOM Number of methods Size
SIZE1 Number of semicolons
SIZE2 Number of attributes + NOM

3. Beiman and Kang (1995) proposed two cohesion metrics LCC and TCC.
4. Lorenz and Kidd (1994) proposed a suite of 11 metrics. These metrics address size,
coupling, inheritance, etc. and are summarized in Table 8.14.

Table 8.14 Lorenz and Kidd metric suite

Metric Definition Construct being measured
NOP Number of parents Inheritance
NOD Number of descendants
NMO Number of methods overridden
NMI Number of methods inherited
NMA Number of methods added
SIX Specialization index

5. Briand et al. (1997) proposed a suite of 18 coupling metrics. These metrics are
summarized in Table 8.15.

Table 8.15 Briand et al. metric suite

IFCAIC These coupling metrics count the number of interactions between classes.
ACAIC The metrics distinguish the relationship between the classes (friendship, inheritance,
OCAIC none), different types of interactions, and the locus of impact of the interaction.
FCAEC The acronyms for the metrics indicate what interactions are counted:
DCAEC  The first or first two characters indicate the type of coupling relationship between
OCAEC classes [A: Ancestor, D: Descendants, F: Friend classes, IF: Inverse Friends
IFCMIC (classes that declare a given class a as their friend), O: Others, i.e. none of the
ACMIC other relationships].
DCMIC  The next two characters indicate the type of interaction:
FCMEC CA: There is a Class-Attribute interaction if class x has an attribute of type class y.
DCMEC CM: There is a Class-Method interaction if class x consists of a method that has
OCMEC parameter of type class y.
IFMMIC MM: There is a Method-Method interaction if class x calls method of another class
AMMIC y, or class x has a method of class y as a parameter.
OMMIC  The last two characters indicate the locus of impact:
FMMEC IC: Import coupling, counts the number of other classes called by class x.
DMMEC EC: Export coupling, counts the number of other classes using class y.
OMMEC
340  Object-Oriented Software Engineering

6. Teagarden and Sheetz have proposed a large suite of metrics.

7. Lee et al. (1995) have given four metrics: one for measuring cohesion and three metrics
for measuring coupling (see Table 8.16).

Table 8.16 Lee et al. metric suite

Metric Definition Construct being measured
ICP Information flow-based coupling Coupling
IHICP Information flow-based inheritance coupling
NIHICP Information flow-based non-inheritance coupling
ICH Information based cohesion Cohesion

8. The system level polymorphism metrics are measured by Benlarbi and Melo (1999). These
metrics are used to measure static and dynamic polymorphism and are summarized in
Table 8.17.

Table 8.17 Polymorphism metrics

Metric Definition
SPA Static polymorphism in ancestors
DPA Dynamic polymorphism in ancestors
SP Static polymorphism in inheritance relations; SP = SPA + SPD
DP Dynamic polymorphism in inheritance relations; DP = DPA + DPD
NIP Polymorphism in non-inheritance relations
OVO Overloading in stand-alone classes
SPD Static polymorphism in descendants
DPD Dynamic polymorphism in descendants

9. Yap and Henderson-Sellers (1993) have proposed a suite of metrics to measure cohesion
and reuse in object-oriented systems.
10. Aggarwal et al. (2006) have proposed a set of two metrics (FTF and CTF) to measure
reuse in object-oriented systems.

Review Questions
1. What is software quality? Explain the various software quality attributes.
2. Define the following software quality attributes:
(a) Functionality
(b) Reliability
(c) Maintainability
(d) Adaptability
3. Establish the relationship between reliability and maintainability. How does one affect
the effectiveness of the other?
 Software Quality and Metrics  341
4. Describe the elements of a quality system. Why should customer’s satisfaction be the
prime concern for developers?
5. Design the table of associations between elements of a quality system and life cycle
phases. Which life cycle phases require all elements of a quality system and why?
6. Explain the McCall’s software quality model. Discuss the significance and importance
of product quality factors.
7. Establish the relationship between quality factors and quality criteria in McCall’s
software quality model.
8. What is defect management and trend analysis of a quality system? Explain with the
help of a format for software defect report.
9. Define the following terms:
(a) Configuration management
(b) Risk management activities
(c) Reviews and audits
(d) Standards, processes and metrics
10. Explain the Boehm’s software quality model with software quality attributes in the form
of a hierarchy.
11. What is ISO 9000? List the processes which can be improved and better maintained by
the implementation of ISO 9000.
12. Discuss ISO 9126. How is it different from ISO 9000? Highlight a few characteristics
which are part of this model.
13. What is CMM? How does it encourage the continuous improvement of the software
processes?
14. Explain the various KPAs at different maturity levels. List some of the difficulties of
achieving CMM level 5.
15. Compare CMM and ISO 9126 models. Which is more popular and why?
16. What are software metrics? Discuss their areas of applications.
17. What are the various categories of software metrics? Explain each category with the
help of examples.
18. Define nominal scale and ordinal scale in the measurements and also discuss both the
concepts with examples.
19. Explain the role and significance of Weyuker’s properties in software metrics.
20. Describe the measures of central tendency. Discuss the concepts with examples.
21. Consider the following data set consisting of lines of source code for a given project:
100, 150, 156, 187, 206, 209, 235, 270, 275, 280, 305, 309, 351, 359, 375, 400,406, 410,
450, 475, 500
Calculate mean, median and mode.
342  Object-Oriented Software Engineering

22. Describe the measures of dispersion. Explain the concepts with examples.
23. Consider the data set consisting of lines of source code given in Question 21. Calculate
the standard deviation, variance and quartile.
24. Consider the following data sets given for three metric variables. Determine the
normality of these variables.

Fault count Cyclomatic complexity Branch count

302 21 605
278 20 570
206 16 210
110 14 98
98 12 91
90 11 86
65 11 82
36 10 40
18 8 36
11 9 32

25. What is outlier analysis? Discuss its importance in data analysis. Explain univariate,
bivariate and multivariate.
26. Consider the data set given in Question 24. Construct box plots and identify univariate
outliers for all variables in the data set.
27. Consider the data set given in Question 24. Identify bivariate outliers between the
dependent variable fault count and other variables.
28. Explain the various size estimation metrics. Which one is most popular and why?
29. Explain Halstead’s software science metrics. How can we estimate program length?
Highlight some advantages of these metrics.
30. Define the role of fan-in and fan-out in information flow metrics.
31. What are the various measures of software quality? Discuss any one with examples.
32. What are the various usability metrics? What is the role of customer satisfaction?
33. Define the following testing metrics:
(a) Statement coverage metric
(b) Branch coverage metric
(c) Condition and path coverage metrics
(d) Fault coverage metric
34. What is software coupling? Explain some coupling metrics with examples.
35. What is software cohesion? Explain some cohesion metrics with examples.
36. How do we measure inheritance? Explain inheritance metrics with examples.
 Software Quality and Metrics  343
37. Define the following inheritance metrics:
(a) DIT
(b) AID
(c) NOC
(d) NOP
(e) NOD
(f) NOA
38. Define the following:
(a) Reuse ratio
(b) Specialization ratio
(c) FTF and CTF
39. Define the following size metrics:
(a) Weighted methods per class (WMC)
(b) Number of attributes (NOA)
(c) Number of methods (NOM)
40. Explain the metric suite of Chidamber and Kemerer. Highlight the strengths and
weaknesses of this metric suite.

Multiple Choice Questions

Note: Select the most appropriate answer of the following questions:
1. A fault is nothing but a/an:
(a) Error (b) Defect
(c) Mistake (d) All of the above
2. A fault may generate:
(a) One failure (b) Two failures
(c) Many failures (d) All of the above
3. In terms of software quality, the software should conform to
(a) Functional requirements (b) Non-functional requirements
(c) Both (a) and (b) (d) Critical requirements only
4. Which is not a software quality attribute?
(a) Functionality (b) Accountability
(c) Maintainability (d) Reliability
5. Which is not an element of a quality system?
(a) Processes, metrics and standards (b) Quality of developers
(c) Reviews and audits (d) Safety and security
6. ANSI stands for:
(a) American National Standards Institute
(b) American National System Information
(c) American National Software Institute
(d) American National Safety Institute
344  Object-Oriented Software Engineering

7. McCall’s software quality model consists of:

(a) Product operation (b) Product transition
(c) Product revision (d) All of the above
8. Product operation may not include:
(a) Correctness (b) Efficiency
(c) Portability (d) Reliability
9. Product revision may include:
(a) Maintainability (b) Flexibility
(c) Testability (d) All of the above
10. Product transition may include:
(a) Portability (b) Reusability
(c) Interoperability (d) All of the above
11. McCall has designed a:
(a) Quality model (b) Design model
(c) Test model (d) Maintenance model
12. Intermediate constructs of Boehm’s software quality model may include:
(a) Portability (b) Reliability
(c) Testability (d) All of the above
13. How many levels of characteristics are designed in Boehm’s software quality model?
(a) 1 (b) 2
(c) 3 (d) 4
14. Which is not a characteristic in ISO 9126?
(a) Safety (b) Portability
(c) Reliability (d) Usability
15. The total number of maturity levels in CMM is:
(a) 1 (b) 3
(c) 5 (d) 7
16. CMM stands for:
(a) Cost maturity model (b) Capability maturity model
(c) Confident maturity model (d) Condition maturity model
17. Characteristic of CMM level 5 (optimizing) is:
(a) Process control (b) Process measurement
(c) Process definition (d) Process management
18. KPA in CMM stands for:
(a) Key product areas (b) Key process areas
(c) Key program areas (d) Key person areas
19. Measures of central tendency include:
(a) Mean (b) Median
(c) Mode (d) All of the above
 Software Quality and Metrics  345
20. Measures of dispersion include:
(a) Standard deviation (b) Variance
(c) Quartiles (d) All of the above
21. Which one is not a measure of size?
(a) LOC (b) Halstead’s program length
(c) Cyclomatic complexity (d) Function point
22. After the design of SRS, we may like to estimate:
(a) Cost (b) Development time
(c) Size (d) All of the above
23. Defect density is defined as:
Number of failures
(a) Number of defects (b)
KLOC KLOC
Number of undefined variables Number of variables
(c) (d)
KLOC KLOC
24. DRE is calculated by:
DA DB
(a) (b)
DB + DA DB + DA

DB + DA DB + DA
(c) (d)
DB DA

25. Reuse ratio is calculated by:

Number of superclasses Total number of classes
(a) (b)
Total number of classes Number of superclasses
Number of subclasses
(c) (d) All of the above
Total number of classes
26. Specialization ratio is calculated by:
Number of superclasses Number of subclasses
(a) (b)
Number of subclasses Number of superclasses
Number of subclasses Number of superclasses
(c) (d)
Total number of classes Total number of classes
27. Which one is not a Chidamber and Kemerer metric?
(a) CBO (b) WMC
(c) NOP (d) DIT
28. Which one is not a Lorenz and Kidd metric?
(a) NOD (b) NMO
(c) NMI (d) DIT
346  Object-Oriented Software Engineering

29. Select the best maturity level in CMM:

(a) CMM level 1 (b) CMM level 2
(c) CMM level 3 (d) CMM level 5
30. The CMM concept is designed at:
(a) Harvard University (b) Carnegie Mellon University
(c) City University (d) Oxford University

Further Reading
Hortch presents full account of the element of software quality system:
Horch, John W., Practical Guide to Software Quality Management. Norwood, MA: Artech
House, 2003.
An in-depth study of 18 different categories of software complexity metrics was provided by
Zuse, where he tried to give the basic definition of metrics in each category:
Zuse, H., Software Complexity: Measures and Methods. Berlin: Walter De Gryter, 1990.
Fenton and Pfleeger’s book is a classic and useful reference, and it gives detailed discussion on
measurement and key definition of metrics:
Fenton, N. and Pfleeger, S., Software Metrics: A Rigorous & Practical Approach. Boston: PWS
Publishing Company, 1997.
A detailed description on software reliability and contributions from many of the leading
researchers may be found in Lyu’s book:
Lyu, M., Handbook of Software Reliability Engineering. Los Angeles: IEEE Computer Press,
1996.
Aggarwal presents a good overview of software reliability models. Musa et al. provides a detailed
description particularly on software reliability models:
Aggarwal, K.K., Reliability Engineering. New Delhi: Kluwer, 1993.
Musa, J.D., Lannino, A. and Okumoto, K., Software Reliability: Measurement, Prediction and
Applications. New York: McGraw Hill, 1987.
The first significant OO design metrics suite was proposed by Chidamber and Kemerer in 1991.
Then came another paper by Chidamber and Kemerer defining and validating metrics suite
for OO design in 1994. This metric suite has received the widest attention in empirical
studies:
Chidamber, S., and Kemerer, C., A metrics suite for object-oriented design. IEEE Transactions
on Software Engineering, 20(6): 476–493, 1994.
There are several books on research methodology and statistics with their applications:
Kothari, C.R., Research Methodology: Methods and Techniques. New Delhi: New Age
International Limited, 2004.
Hopkins, W.G., A new view of statistics. Sport Science, 2003.
 Software Quality and Metrics  347
The details on outlier analysis can be obtained from:
Barnett, V. and Price, T., Outliers in Statistical Data. Chichester: John Wiley & Sons, 1995.
For a detailed account of the statistics needed for model prediction using logistic regression
(notably how to compute maximum likelihood estimates, R2, significance values), see the
following textbook and research paper:
Hosmer, D., and Lemeshow, S., Applied Logistic Regression. New York: John Wiley & Sons,
1989.
Basili, V., Briand, L., and Melo, W., “A validation of object-oriented design metrics as quality
indicators. IEEE Transactions on Software Engineering, 22(10): 751–761, 1996.
Detailed description on object-oriented metrics can be obtained from:
Lorenz, M. and Kidd, J., Object-Oriented Software Metrics. Englewood Cliff, NJ: Prentice-Hall,
1994.
Henderson-Sellers, B., Object-oriented Metrics: Measures of Complexity. Englewood Cliff, NJ:
Prentice-Hall, 1996.
Various object-oriented metrics are explained with real-life examples in:
Aggarwal, K.K., Singh, Y., Kaur, A. and Malhotra, R., Empirical study of object-oriented
metrics. Journal of Object Technology, 5(8): 149–173, 2006.
Relevant publications on object-oriented metrics can be obtained from:
http://www.sbu.ac.uk/~csse/publications/OOMetrics.html
Complete bibliography on object-oriented metrics can be obtained from:
Object-Oriented Metrics: An Annotated Bibliography, http://dec.bournemouth.ac.uk/ESERG/
bibliography.html
 9
Software Testing

Software testing is a very important, challenging and essential activity. It starts along with the
design of SRS document and ends at the delivery of software product to the customer. It consumes
significant effort and maximum time of software development life cycle (without including the
maintenance phase). The significant effort may be from one third to one half of the total effort
expended till the delivery of the software product. We cannot imagine to deliver a software
product without adequate testing. The existing testing techniques help us to do adequate testing.
However, adequate testing has different meaning to different software testers.

9.1 What is Software Testing?

The common perception about testing is to execute a program with given input(s) and note the
observed output(s). The observed output(s) is/are matched with expected output(s) of the program.
If it matches, the program is correct and if it does not match, the program is incorrect for the
given input(s). There are many definitions of testing and some of them are given as follows:
(i) The aim of testing is to show that a program performs its desired functions correctly.
(ii) Testing is the process of demonstrating that errors are not present.
(iii) Testing is the process of establishing confidence that a program does what it is supposed
to do.
The purpose of testing as per the above definitions is to show the correctness of the program. We
may select many inputs and execute the program and also demonstrate its correctness without
touching critical and complex portions of the program. During testing, our objective should be
to find faults and find them as early as possible. Hence, a more appropriate definition of testing
is given by Myers (2004) as:
Testing is the process of executing a program with the intent of finding faults.

348
 Software Testing  349
This definition motivates us to select those inputs which have higher probability of finding
faults, although the definition is also not complete because it focuses only on the execution of
the program. Nowadays, attention is also given to the activities like reviewing the documents
and programs. Reviewing the documents (like SRS and SDD) helps us to find a good number
of faults in the early phases of software development. Hence, testing is divided into two parts:
verification and validation. Therefore, the most appropriate definition of software testing is:
Software testing is the process of verifying the outcomes of every phase of software development
and validating the program by executing it with the intention of finding faults.

In the initial days of programming, testing was primarily validation oriented but nowadays both
are equally important and carried out in most of the software organizations.

9.1.1 Verification
Software verification is also known as static testing where testing activities are carried out
without executing the program. It may include inspections, walkthroughs and reviews where
documents and programs are reviewed with the purpose of finding faults. Hence, verification
is the process of reviewing (rechecking) documents and program with the intention of finding
faults. As per the IEEE (2001):
The verification is the process of evaluating the system or component to determine whether the
products of a given development phase satisfy the conditions imposed at the start of that phase.

9.1.2 Validation
Software validation is also known as dynamic testing where the program is executed with given
input(s). Hence, validation involves execution of the program and usually exposes symptoms of
errors. As per the IEEE (2001):
The validation is the process of evaluating a system or component during or at the end of
development process to determine whether it satisfies the specified requirements.

Validation activities are carried out with the execution of the program. We experience failures
and reasons of such failures are identified.
Software testing includes both verification and validation. Both are important and
complementary to each other. Effective verification activities find a good number of faults in
the early phases of software development. Removing such faults will definitely provide better
foundations for the implementation/construction phase. Validation activities are possible only
after the implementation of module/program, but verification activities are possible in every
phase of software development.

9.2 Software Verification Techniques

Software verification techniques are applicable in every phase of software development life
cycle. The purpose of such techniques is to review the outcomes of every phase of software
development life cycle, i.e. from requirements and analysis phase to testing phase. Most of
350  Object-Oriented Software Engineering

the software professionals are convinced about the importance and usefulness of verification
techniques. They also believe that a good quality software product can be produced only after the
effective implementation of verification techniques. Many verification techniques are commonly
used in practice and some of them are discussed in the following subsections.

9.2.1 Peer Reviews

This is the simplest, informal and oldest verification technique. It is applicable to every document
produced at any stage of software development. Programs are also reviewed using this technique
without executing them. We give documents/programs to some one else and ask them to
review with an objective of finding faults. Some shortcomings or faults may be identified. This
technique may give very good results if the reviewer has domain knowledge, technical expertise,
programming skills and involvement in the reviewing work. A report may be prepared about
the faults in the documents and programs. Sometimes, faults are also reported verbally during
discussion. Reported faults are examined and appropriate corrections are made in the documents
and programs. Every reviewing activity improves the quality of the documents and programs.
Every reviewing activity improves the quality of the documents and programs without spending
significant resources. This is very effective and easily applicable to small-size documents and
programs. However, effectiveness reduces, as the size of the documents and programs increases.

9.2.2 Walkthroughs
Walkthrough is a group activity for reviewing the documents and programs. It is a more formal
and systematic technique than per reviews. A group of two to seven persons is constituted for
the purpose of reviewing. The author of the document presents the document to the group during
walkthroughs conducted in a conference room. The author may use any display mechanism (like
whiteboard, projector) for presentation. Participants are not expected to prepare anything prior
to such a meeting. Only the presenter who happens to be the author of the document prepares
for the walkthrough. Documents and/or programs are distributed to every participant and the
author presents the contents to all to make them understand. All participants are free to ask
questions and write their observations on any display mechanism in such a way that everyone
can see it. The observations are discussed thoroughly amongst the participants and changes
are suggested accordingly. The author prepares a detailed report as per suggested changes. The
report is studied, changes are approved and documents/programs are modified.
The limitations of such a technique are the non-preparation of participants prior to meeting
and presentation of documents by their author(s). The author(s) may unnecessarily highlight
some areas and hide a few critical areas. Participants may also not be able to ask critical and
penetrating questions. Walkthroughs may create awareness amongst participants and may also
find a few important faults. This technique is more expensive but systematic than peer reviews
and applicable to any size of software project.

9.2.3 Inspections
This technique is more formal, systematic and effective. There are many names for this
technique like formal reviews, formal technical reviews and inspections. The most popular
 Software Testing  351
name is inspection and is different from peer reviews and walkthroughs. A group of three to
six persons is constituted. The author of the document is not the presenter. An independent
presenter is appointed for this specific purpose who prepares and understands the document.
This preparation provides a second eye on the document(s) prior to meeting. The documents(s)
is/are distributed to every participant in advance to give sufficient time for preparation. Rules
of the meeting are prepared and circulated to all participants in advance to make them familiar
with the framework of the meeting. The group is headed by an impartial moderator who should
be a senior person to conduct the meetings smoothly. A recorder is also engaged to record the
proceedings of the meetings.
The presenter presents the document(s) in the meeting and makes everyone comfortable
with the document(s). Every participant is encouraged to participate in the deliberations as
per modified rules. Everyone gets time to express his/her views, opinions about quality of
document(s), potential faults and critical areas. The moderator chairs the meeting, enforces the
discipline as per prescribed rules and respects views of every participant. Important observations
are displayed in a way that is visible to every participant. The idea is to consider everyone’s
views and not to criticize them. Many times, a checklist is used to review the document. After
the meeting, the moderator along with the recorder prepares a report and circulates it to all
participants. Participants may discuss the report with the moderator and suggest changes. A
final report is prepared after incorporating changes. The changes should be approved by the
moderator. Most of the organizations use inspections as a verification technique and outcomes
are very good. Many faults are generally identified in the early phases of software development.
This is a popular, useful and systematic technique and is effective for every type of document
and program. The comparison of all the three techniques is given in Table 9.1.

Table 9.1 Verification techniques comparison

1 2 3
Technique Peer reviews Walkthrough Inspections
Presenter No one Author Someone other than the
author
Number of participants 1 or 2 2 to 7 participants 3 to 6 participants
Prior preparation Not required Only the presenter is All participants are
required to be prepared required to be prepared
Applicability Small-size software Any size software Any size software
projects projects projects
Report Optional Compulsory Compulsory
Advantages Inexpensive and always Makes people aware Useful and finds many
finds some faults about the project faults
Disadvantages Dependent on the ability May find few faults Skilled participants are
of reviewer needed and expensive

Verification is always more useful than validation due to its applicability in early phases
of software development. It finds those faults which may not be detected by any validation
technique. Verification techniques are becoming popular and more attention is given to such
techniques from the beginning of the software development.
352  Object-Oriented Software Engineering

9.3 Checklist: A Popular Verification Tool

A checklist is normally used which consists of a list of important information contents that a
deliverable must contain. A checklist may discipline the reviewing process and may identify
duplicate information, missing information, and unclear and wrong information. Every document
may have a different checklist which may be based on important, critical and difficult areas of
the document. A checklist may be applicable in all verification techniques but it is more effective
during inspections.

9.3.1 SRS Document Checklist

The SRS document is given in Chapter 3 (refer to Section 3.7) which is designed as per the
IEEE standard 830–1998. Characteristics of good requirements are also given in Section 3.6
of Chapter 3 which may include the characteristics such as correct, unambiguous, complete,
verifiable, modifiable, clear, feasible, necessary and understandable. Therefore, the SRS
document checklist should address the above-mentioned characteristics. The SRS document
is the source of many potential faults. It should be reviewed very seriously and thoroughly.
The effective reviewing process improves the quality of the SRS document and minimizes the
occurrence of many future problems. A properly designed checklist may help to achieve the
objective of developing good quality software. A checklist is given in Table 9.2 which may be
modified as per the requirement of the SRS document.

Table 9.2 Checklist for verifying SRS document

Part I

Reviewer name(s) Organization Review date Project title

Part II

S. No. Description Yes/No/NA Comments

Document overview
1. Are you satisfied with defined scope?
2. Are the objectives of the project clearly stated?
3. Has IEEE std-830-1998 been followed?
4. Is SRS document approved by the customer?
5. Is the layout of the screens well designed?
6. Are definitions, acronyms and abbreviations defined?
7. Do you suggest changes in the overall description?
8. Are user interfaces, hardware interfaces, software interfaces
and communication interfaces clearly described?
9. Are major product functions stated?
10. Are you satisfied with the list of constraints?
11. Do you want to add any field in any form?

(Contd.)
 Software Testing  353
Table 9.2 Checklist for a good quality software (Contd.)
S. No. Description Yes/No/NA Comments
12. Do you want to delete any field in any form?
13. Do you want to add/delete any validity check?
14. Is readability of the document satisfactory?
15. Are non-functional requirements specified?
Actors, use cases and use case description
16. Are all the actors identified?
17. Are all the use cases determined?
18. Does the name of the use case represent the function it is
required to perform?
19. Are all the actors included in the use case description of each
use case?
20. Are you ready to accept identified use cases and their
descriptions?
21. Does the use case description include precondition?
22. Does the use case description include postcondition?
23. Is the basic flow in the use case complete?
24. Are all the alternative flows of the use case stated?
25. Are related use cases stated?
Characteristics of requirements
26. Are all requirements feasible?
27. Are requirements non-feasible due to technical problems?
28. Are requirements non-feasible due to inadequate resources?
29. Are a few requirements difficult to implement?
30. Are all requirements conveying only one meaning?
31. Are there conflicts amongst requirements?
32. Are all functional and non-functional requirement defined?
33. Are all use cases clearly understandable?
34. Are all forms available with adequate validity checks?
35. Are all requirements specified at a consistent level of detail?
36. Is consistency maintained throughout the document?
37. Are there any conflicts amongst requirements?
38. Are all defined requirements verifiable?
39. Are all stated requirements understandable?
40. Are redundant requirements identified?
41. Do you want to add a requirement?
42. Are all stated requirements written in a simple language?

(Contd.)
354  Object-Oriented Software Engineering

Table 9.2 Checklist for a good quality software (Contd.)

S. No. Description Yes/No/NA Comments
43. Are there any non-verifiable words in any requirement?
44. Are all assumptions and dependencies defined?
45. Are the requirements consistent with other documents of the
project?
General
46. Are you satisfied with the depth of the document?
47. Is logical database requirements specified?
48. Are design constraints described?
49. Is site adaptation requirement clearly defined?
50. Is product perspective written with adequate details?

9.3.2 Object-Oriented Analysis Checklist

The checklist for OOA is given in Table 9.3 which may be used to verify the documents produced
after OOA phase.

Table 9.3 Checklist for verifying OOA

Part I

Reviewer name(s) Organization Review date Project title

Part II

S. No. Description Yes/No/NA Comments

1. Are all the classes—entity, interface and control—identified
correctly?
2. Is any class missing per use case?
3. Is relationship between classes identified correctly?
4. Are entity classes persistent even after the end of use case?
5. Do control classes model flow of control in the system?
6. Does the name of the class convey the function it is intended
to perform?
7. In case of association relationship, is multiplicity between
classes identified correctly?
8. Are role names in case of association relationship between
classes identified correctly?
9. Are all attributes identified correctly?
10. Does the name of the attribute convey the function it is
intended to perform?
(Contd.)
 Software Testing  355

Table 9.3 Checklist for OOA (Contd.)

S. No. Description Yes/No/NA Comments

11. Is UML syntax of each class correct?
12. Are the control classes necessary?
13. Is naming convention followed by the attributes?
14. Are classes identified for each use case?
15. Are all attributes defined clearly?

9.3.3 Object-Oriented Design Checklist

The OOD checklist is given in Table 9.4 which may be used to verify the documents produced
after the OOD phase.

Table 9.4 Checklist for verifying OOD

Part I

Reviewer name(s) Organization Review date Project title

Part II

S. No. Description Yes/No/NA Comments

1. Are all the objects in the interaction diagram the identified
correctly?
2. Are all the classes in the interaction diagram identified
correctly?
3. Are interaction diagrams created for each use case scenario?
4. Are all messages shown at right places in the interaction
diagram?
5. Are all messages passing the parameters correctly?
Sequence diagram
6. Do the sequence diagrams have an initiating actor?
7. Does an actor send message to the system in the sequence
diagram?
8. Does the sequence diagram depict the order in which
messages are sent?
9. Are the objects in the sequence diagram destroyed when not
required?
10. Is the focus of control for each object identified correctly?
11. Are all the return messages identified correctly?
12. Are all the parameters of the messages identified correctly?
13. Are all the parameter types of the message parameters
identified correctly?

(Contd.)
356  Object-Oriented Software Engineering

Table 9.4 Checklist for OOD (Contd.)

S. No. Description Yes/No/NA Comments
14. Do the messages follow the naming convention?
15. Is the order of the messages identified correctly?
16. Are all swimlanes defined properly?
17. Are all states identified correctly in statechart diagrams?
18. Are all guard conditions used at proper places?
19. Are activity diagrams used to model the working of all
processes?
20. Are all stated notations used in all activity diagrams and
statechart diagrams?

9.4 Functional Testing

Functional testing techniques are validation techniques because execution of the program is
essential for the purpose of testing. Inputs are given to the program during execution and the
observed output is compared with the expected output. If the observed output is different than
the expected output, the situation is treated as a failure of the program. Functional testing
techniques may design those test cases which have higher chances of making the program fail.
These test cases are designed as per functionality and internal structure of the program is not at
all considered. The program is treated as a black box and only functionality of the program is
considered. Functional testing is also called black box testing because internal structure of the
program is completely ignored and is shown in Figure 9.1.

Figure 9.1 Functional (black box) testing.

Every dot of the input domain represents input(s) and every dot of the output domain
represents output(s). Every dot of the input domain has a corresponding dot in the output
domain. We consider valid and invalid inputs for the purpose of program execution and note the
behaviour in terms of observed outputs. Functional testing techniques provide ways to design
effective test cases to find errors in the program.

9.4.1 Boundary Value Analysis

The boundary value analysis technique focuses upon on or close to boundary values of input
domain. We feel that the inputs on or close to boundary values have more chances to make the
program fail after execution. Hence, test cases with input values on or close to boundary should
 Software Testing  357
be designed. We consider a program ‘square root’ which takes a as an input value and prints the
square root of a. The range of input value a is from 100 to 1000. We may execute the program
for all input values from 100 to 1000 and observe the outputs of the program 900 times to see
the output for every possible valid input. We may not like to execute the program for every
possible valid input due to time and resource constraints. The boundary value analysis technique
helps us to reduce the number of test cases by focusing only upon on or close to boundary
values. On or close to boundary values cover the following:
 Minimum value
 Just above the minimum value
 Maximum value
 Just below the maximum value
 Nominal (average) value
These values are represented in Figure 9.2 for the program ‘square root’ with input value ranging
from 100 to 1000.

Figure 9.2 Input to the program of ‘square root’.

The technique selects only five values instead of 900 values to test the program. These
values of a are 100, 101, 550, 999, 1000 which cover the boundary portions of the input value
except one nominal value (say 550). The nominal value represents those values which are neither
on the boundary nor close to boundary. The number of test cases designed by this technique
is 4n + 1, where n is the number of input values. The test cases generated for the ‘square root’
program are shown in Table 9.5.

Table 9.5 Test cases of ‘square root’ program test cases

Test case Input a Expected output
1 100 10
2 101 10.05
3 550 23.45
4 999 31.61
5 1000 31.62

We consider a program ‘subtraction’ with two input values a and b and the output is the
subtraction of a and b. The ranges of input values are shown as:
100  a  1000
200  b  1200
The selected values for a and b are given as:
a = (100, 101, 550, 999, 1000)
b = (200, 201, 700, 1199, 1200)
358  Object-Oriented Software Engineering

Both inputs (a and b) are required for the execution of the program. The input domain is
shown in Figure 9.3 where any point within the rectangle is a legitimate input of the program.
The test cases are generated on the basis of ‘single fault’ assumption theory of reliability.
This theory assumes that failures are rarely the result of simultaneous occurrence of two (or
more) faults. Generally one fault is responsible for a failure. The implication of this theory is
that we select one input for any of the defined states (minimum, just above minimum, just below
maximum, maximum, nominal) and other input(s) as nominal values.
The test cases are 4n + 1 (i.e. 8 + 1 = 9) which are given in Table 9.6. The input values are
also shown graphically in Figure 9.3.

Figure 9.3 Graphical representation of inputs.

Table 9.6 Test cases for ‘subtraction’ program

Test case a b Expected output
1 100 700 –600
2 101 700 –599
3 550 700 –150
4 999 700 299
5 1000 700 300
6 550 200 350
7 550 201 349
8 550 1199 –649
9 550 1200 –650

EXAMPLE 9.1 Consider a program to multiply and divide two numbers. The inputs may be
two valid integers (say a and b) in the range of [0, 100]. Generate boundary value analysis test
cases.
Solution Boundary value analysis test cases are given in Table 9.7.
 Software Testing  359
Table 9.7 Boundary value analysis test cases for Example 9.1
Test case a b Expected output
1 0 50 0 0
2 1 50 50 0
3 50 50 2500 1
4 99 50 4950 1
5 100 50 5000 2
6 50 0 0 Divide by zero error
7 50 1 50 50
8 50 99 4950 0
9 50 100 5000 0

EXAMPLE 9.2 Consider a program which takes a date as an input and checks whether it is
a valid date or not. Its input is a triple of day, month and year with the values in the following
ranges:
1  month  12
1  day  31
2000  year  2070
Generate boundary value analysis test cases.
Solution Boundary value analysis test cases are given in Table 9.8.

Table 9.8 Boundary value test cases for program determining validity of date
Test case Month Day Year Expected output
1 1 15 2035 Valid date (1/15/2035)
2 2 15 2035 Valid date (2/15/2035)
3 6 15 2035 Valid date (6/15/2035)
4 11 15 2035 Valid date (11/15/2035)
5 12 15 2035 Valid date (12/15/2035)
6 6 1 2035 Valid date (6/1/2035)
7 6 2 2035 Valid date (6/2/2035)
8 6 30 2035 Valid date (6/30/2035)
9 6 31 2035 Invalid date
10 6 15 2000 Valid date (6/15/2000)
11 6 15 2001 Valid date (6/15/2001)
12 6 15 2069 Valid date (6/15/2069)
13 6 15 2070 Valid date (6/15/2070)

There are three extensions of boundary value analysis technique and are given below:
(i) Robustness testing
Two additional states ‘just below minimum’ and ‘just above maximum’ are added to see the
behaviour of the program with invalid input values. Invalid inputs are equally important and
may make the program fail when such inputs are given.
360  Object-Oriented Software Engineering

There are seven states in robustness testing and are given as:
1. Just below minimum (minimum–)
2. Minimum
3. Just above minimum (minimum+)
4. Nominal (average value)
5. Just below maximum (maximum–)
6. Maximum
7. Just above maximum (maximum+)
The total number of test cases generated for robustness testing is 6n + 1, where n is the number
of input values. Test cases for ‘subtraction’ program using robustness testing are 13 as given in
Table 9.9.

Table 9.9 Robustness test cases for ‘subtraction’ program

Test case a b Expected output
1 99 700 Invalid input
2 100 700 –600
3 101 700 –599
4 550 700 –150
5 999 700 299
6 1000 700 300
7 1001 700 Invalid input
8 550 199 Invalid input
9 550 200 350
10 550 201 349
11 550 1199 –649
12 550 1200 –650
13 550 1201 Invalid input

The input domain has four test cases which are outside; the other test cases lie in the
legitimate input domain as shown in Figure 9.4.

Figure 9.4 Input domain of ‘subtraction’ program for robustness test cases.
 Software Testing  361
(ii) Worst case testing
This is another form of boundary value analysis where the single fault assumption theory of
reliability is rejected. Hence, a failure may also be the result of the occurrence of more than one
fault simultaneously. The result of this rejection is that one, two or all input values may have one
of the following states:
 Minimum
 Minimum+
 Nominal (average value)
 Maximum–
 Maximum
In the worst case testing, the restriction of one input value at the above-mentioned states
and other input values nominal is removed. The implication is that the number of test cases
will increase from 4n + 1 test cases to 5n test cases, where n is the number of input values. The
‘subtraction’ program will have 52 = 25 test cases which are shown in Table 9.10.

Table 9.10 Worst test cases for ‘subtraction’ program

Test case a b Expected output
1 100 200 –100
2 100 201 –101
3 100 700 –600
4 100 1199 –1099
5 100 1200 –1100
6 101 200 –99
7 101 201 –100
8 101 700 –599
9 101 1199 –1098
10 101 1200 –1099
11 550 200 350
12 550 201 349
13 550 700 –150
14 550 1199 –649
15 550 1200 –650
16 999 200 799
17 999 201 798
18 999 700 299
19 999 1199 –200
20 999 1200 –201
21 1000 200 800
22 1000 201 799
23 1000 700 300
24 1000 1199 –199
25 1000 1200 –200
362  Object-Oriented Software Engineering

The inputs given in Table 9.10 are graphically represented in Figure 9.5.

Figure 9.5 Graphical representation of inputs.

In the worst case testing, we select more number of test cases for completeness and
thoroughness. This is a more effort and time-consuming technique.
(iii) Robust worst case testing
Two more states are added to check the behaviour of the program with invalid inputs. These
two states are ‘just below minimum’ and ‘just above maximum’. The total number of test cases
generated by this technique is 7n. The subtraction program has 72 = 49 test cases which are given
in Table 9.11.

Table 9.11 Robust worst test cases for ‘subtraction’ program

Test case a b Expected output
1 99 199 Invalid input
2 99 200 Invalid input
3 99 201 Invalid input
4 99 700 Invalid input
5 99 1199 Invalid input
6 99 1200 Invalid input
7 99 1201 Invalid input
8 100 199 Invalid input
9 100 200 –100
10 100 201 –101
11 100 700 –600
12 100 1199 –1099
13 100 1200 –1100
14 100 1201 Invalid input
15 101 199 Invalid input

(Contd.)
 Software Testing  363
Table 9.11 Robust worst test cases for ‘subtraction’ program (Contd.)

Test case a b Expected output

16 101 200 –99
17 101 201 –100
18 101 700 –599
19 101 1199 –1098
20 101 1200 –1099
21 101 1201 Invalid input
22 550 199 Invalid input
23 550 200 350
24 550 201 349
25 550 700 –150
26 550 1199 –649
27 550 1200 –650
28 550 1201 Invalid input
29 999 199 Invalid input
30 999 200 799
31 999 201 798
32 999 700 299
33 999 1199 –200
34 999 1200 –201
35 999 1201 Invalid input
36 1000 199 Invalid input
37 1000 200 800
38 1000 201 799
39 1000 700 300
40 1000 1199 –199
41 1000 1200 –200
42 1000 1201 Invalid input
43 1001 199 Invalid input
44 1001 200 Invalid input
45 1001 201 Invalid input
46 1001 700 Invalid input
47 1001 1199 Invalid input
48 1001 1200 Invalid input
49 1001 1201 Invalid input
364  Object-Oriented Software Engineering

The graphical representation of the input domain of ‘subtraction’ program is given in

Figure 9.6.

Figure 9.6 Graphical representation of inputs.

Boundary value analysis is a useful technique and may generate effective test cases. There
is a restriction that input values should be independent. It is not applicable for Boolean variables
because of only two available states—true and false. The technique is also easy to understand
and implement for any size of program.

EXAMPLE 9.3 Consider a program to multiply and divide two numbers as explained in
Example 9.1. Design the robust test cases and worst test cases for this program.
Solution Robust test cases are given in Table 9.12.

Table 9.12 Robust test cases for a program to multiply and divide two numbers
Test case a b Expected output
1 –1 50 Input values are out of range
2 0 50 0 0
3 1 50 50 0
4 50 50 2500 1
5 99 50 4950 1
6 100 50 5000 2
7 101 50 Input values are out of range
8 50 –1 Input values are out of range
9 50 0 0 Divide by zero error
10 50 1 50 50
11 50 99 4950 0
12 50 100 5000 0
13 50 101 Input values are out of range
 Software Testing  365
Worst test cases are given in Table 9.13.

Table 9.13 Worst test cases for a program to multiply and divide two numbers
Test case a b Expected output
Multiply Divide
1 0 0 0 Undefined*
2 0 1 0 0
3 0 50 0 0
4 0 99 0 0
5 0 100 0 0
6 1 0 0 Divide by zero error
7 1 1 1 1
8 1 50 50 1
9 1 99 99 1
10 1 100 100 1
11 50 0 0 Divide by zero error
12 50 1 50 50
13 50 50 2500 1
14 50 99 4950 0
15 50 100 5000 0
16 99 0 0 Divide by zero error
17 99 1 99 99
18 99 50 4950 1
19 99 99 9801 1
20 99 100 9900 0
21 100 0 0 Divide by zero error
22 100 1 100 100
23 100 50 5000 2
24 100 99 9900 1
25 100 100 10,000 1

*0/0 is still undefined.

EXAMPLE 9.4 Consider the program for the determination of validity of the date as explained
in Example 9.2. Design the robust and worst test cases for this program.
Solution Robust test cases and worst test cases are given in Tables 9.14 and 9.15, respectively.
366  Object-Oriented Software Engineering

Table 9.14 Robust test cases for program for determining the validity of the date
Test case Month Day Year Expected output
1 0 15 2035 Invalid date
2 1 15 2035 Valid date (1/15/2035)
3 2 15 2035 Valid date (2/15/2035)
4 6 15 2035 Valid date (6/15/2035)
5 11 15 2035 Valid date (11/15/2035)
6 12 15 2035 Valid date (12/15/2035)
7 13 15 2035 Invalid date
8 6 0 2035 Invalid date
9 6 1 2035 Valid date (6/1/2035)
10 6 2 2035 Valid date (6/2/2035)
11 6 30 2035 Valid date (6/30/2035)
12 6 31 2035 Invalid date
13 6 32 2035 Invalid date
14 6 15 1999 Invalid date (out of range)
15 6 15 2000 Valid date (6/15/2000)
16 6 15 2001 Valid date (6/15/2001)
17 6 15 2069 Valid date (6/15/2069)
18 6 15 2070 Valid date (6/15/2070)
19 6 15 2071 Invalid date (out of range)

Table 9.15 Worst test cases for the program determining the validity of the date
Test case Month Day Year Expected output
1 1 1 2000 Valid date (1/1/2000)
2 1 1 2001 Valid date (1/1/2001)
3 1 1 2035 Valid date (1/1/2035)
4 1 1 2069 Valid date (1/1/2069)
5 1 1 2070 Valid date (1/1/2070)
6 1 2 2000 Valid date (1/2/2000)
7 1 2 2001 Valid date (1/2/2001)
8 1 2 2035 Valid date (1/2/2035)
9 1 2 2069 Valid date (1/2/2069)
10 1 2 2070 Valid date (1/2/2070)
11 1 15 2000 Valid date (1/15/2000)
12 1 15 2001 Valid date (1/15/2001)
13 1 15 2035 Valid date (1/15/2035)
14 1 15 2069 Valid date (1/15/2069)
(Contd.)
 Software Testing  367
Table 9.15 Worst test cases for the program determining the validity of the date (Contd.)

Test case Month Day Year Expected output

15 1 15 2070 Valid date (1/15/2070)
16 1 30 2000 Valid date (1/30/2000)
17 1 30 2001 Valid date (1/30/2001)
18 1 30 2035 Valid date (1/30/2035)
19 1 30 2069 Valid date (1/30/2069)
20 1 30 2070 Valid date (1/30/2070)
21 1 31 2000 Valid date (1/31/2000)
22 1 31 2001 Valid date (1/31/2001)
23 1 31 2035 Valid date (1/31/2035)
24 1 31 2069 Valid date (1/31/2069)
25 1 31 2070 Valid date (1/31/2070)
26 2 1 2000 Valid date (2/1/2000)
27 2 1 2001 Valid date (2/1/2001)
28 2 1 2035 Valid date (2/1/2035)
29 2 1 2069 Valid date (2/1/2069)
30 2 1 2070 Valid date (2/1/2070)
31 2 2 2000 Valid date (2/2/2000)
32 2 2 2001 Valid date (2/2/2001)
33 2 2 2035 Valid date (2/2/2035)
34 2 2 2069 Valid date (2/2/2069)
35 2 2 2070 Valid date (2/2/2070)
36 2 15 2000 Valid date (2/15/2000)
37 2 15 2001 Valid date (2/15/2001)
38 2 15 2035 Valid date (2/15/2035)
39 2 15 2069 Valid date (2/15/2069)
40 2 15 2070 Valid date (2/15/2070)
41 2 30 2000 Invalid date
42 2 30 2001 Invalid date
43 2 30 2035 Invalid date
44 2 30 2069 Invalid date
45 2 30 2070 Invalid date
46 2 31 2000 Invalid date
47 2 31 2001 Invalid date
48 2 31 2035 Invalid date
49 2 31 2069 Invalid date
50 2 31 2070 Invalid date
(Contd.)
368  Object-Oriented Software Engineering

Table 9.15 Worst test cases for the program determining the validity of the date (Contd.)

Test case Month Day Year Expected output

51 6 1 2000 Valid date (6/1/2000)
52 6 1 2001 Valid date (6/1/2001)
53 6 1 2035 Valid date (6/1/2035)
54 6 1 2069 Valid date (6/1/2069)
55 6 1 2070 Valid date (6/1/2070)
56 6 2 2000 Valid date (6/2/2000)
57 6 2 2001 Valid date (6/2/2001)
58 6 2 2035 Valid date (6/2/2035)
59 6 2 2069 Valid date (6/2/2069)
60 6 2 2070 Valid date (6/2/2070)
61 6 15 2000 Valid date (6/15/2000)
62 6 15 2001 Valid date (6/15/2001)
63 6 15 2035 Valid date (6/15/2035)
64 6 15 2069 Valid date (6/15/2069)
65 6 15 2070 Valid date (6/15/2070)
66 6 30 2000 Valid date (6/30/2000)
67 6 30 2001 Valid date (6/30/2001)
68 6 30 2035 Valid date (6/30/2035)
69 6 30 2069 Valid date (6/30/2069)
70 6 30 2070 Valid date (6/30/2070)
71 6 31 2000 Invalid date
72 6 31 2001 Invalid date
73 6 31 2035 Invalid date
74 6 31 2069 Invalid date
75 6 31 2070 Invalid date
76 11 1 2000 Valid date (11/1/2000)
77 11 1 2001 Valid date (11/1/2001)
78 11 1 2035 Valid date (11/1/2035)
79 11 1 2069 Valid date (11/1/2069)
80 11 1 2070 Valid date (11/1/2070)
81 11 2 2000 Valid date (11/2/2000)
82 11 2 2001 Valid date (11/2/2001)
83 11 2 2035 Valid date (11/2/2035)
84 11 2 2069 Valid date (11/2/2069)
85 11 2 2070 Valid date (11/2/2070)
86 11 15 2000 Valid date (11/15/2000)
87 11 15 2001 Valid date (11/15/2001)
88 11 15 2035 Valid date (11/15/2035)
 Software Testing  369
Table 9.15 Worst test cases for the program determining the validity of the date (Contd.)

Test case Month Day Year Expected output

89 11 15 2069 Valid date (11/15/2069)
90 11 15 2070 Valid date (11/15/2070)
91 11 30 2000 Valid date (11/30/2000)
92 11 30 2001 Valid date (11/30/2001)
93 11 30 2035 Valid date (11/30/2035)
94 11 30 2069 Valid date (11/30/2069)
95 11 30 2070 Valid date (11/30/2070)
96 11 31 2000 Invalid date
97 11 31 2001 Invalid date
98 11 31 2035 Invalid date
99 11 31 2069 Invalid date
100 11 31 2070 Invalid date
101 12 1 2000 Valid date (12/1/2000)
102 12 1 2001 Valid date (12/1/2001)
103 12 1 2035 Valid date (12/1/2035)
104 12 1 2069 Valid date (12/1/2069)
105 12 1 2070 Valid date (12/1/2070)
106 12 2 2000 Valid date (12/2/2000)
107 12 2 2001 Valid date (12/2/2001)
108 12 2 2035 Valid date (12/2/2035)
109 12 2 2069 Valid date (12/2/2069)
110 12 2 2070 Valid date (12/2/2070)
111 12 15 2000 Valid date (12/15/2000)
112 12 15 2001 Valid date (12/15/2001)
113 12 15 2035 Valid date (12/15/2035)
114 12 15 2069 Valid date (12/15/2069)
115 12 15 2070 Valid date (12/15/2070)
116 12 30 2000 Valid date (12/30/2000)
117 12 30 2001 Valid date (12/30/2001)
118 12 30 2035 Valid date (12/30/2035)
119 12 30 2069 Valid date (12/30/2069)
120 12 30 2070 Valid date (12/30/2070)
121 12 31 2000 Valid date (12/31/2000)
122 12 31 2001 Valid date (12/31/2001)
123 12 31 2035 Valid date (12/31/2035)
124 12 31 2069 Valid date (12/31/2069)
125 12 31 2070 Valid date (12/31/2070)
370  Object-Oriented Software Engineering

9.4.2 Equivalence Class Testing

A program may have a large number of test cases. It may not be desirable to execute all test
cases due to time and resource constraints. Many test cases may execute the same lines of
source code again and again, and therefore, there is hardly any value addition. We may partition
input domain into various groups on the basis of some relationship. We expect that any test
case from that group will become the representative test case and produce the same behaviour.
If a test case makes the program fail, then other test cases of the same group will also make
the program fail. Similarly, if the output of the program is correct for one test case, the same
behaviour is expected from other test cases of the group. This assumption of similar behaviour
of the program for all test cases of the same group allows us to select only one test case from
each group. If groups are made properly, a few test cases (equal to the number of groups) may
give reasonable confidence about the correctness of the program. In this technique, each group
is called an equivalence class. We may also partition the output domain into equivalence classes
and generate one test case from each class.

Design of Equivalence Classes

In general, without considering any relationship, an input domain can be divided into at least two
equivalence classes, i.e. one class of all valid inputs and other class of all invalid inputs. We may
design many classes on the basis of relationships and logic of the program. The input domain
and output domain may generate a good number of classes and every class gives us a test case
which will represent all test cases of that class. We consider the program ‘square root’ which
takes a as an input in the range (100–1000) and prints the square root of a. We may generate the
following equivalence classes for the input domain:
I1 = {100  a  1000} (valid input range from 100 to 1000)
I2 = {a < 100} (any invalid input where a is less than 100)
I3 = {a > 1000} (any invalid input where a is more than 1000)
The above three equivalence classes are designed without considering any relationship. For
example, the first class I1 represents a valid input class where all inputs are within the specified
range {100  a  1000}. Three test cases are generated, one from every equivalence class, and
are given in Table 9.16.

Table 9.16 Test cases of ‘square root’ program for input domain
Test case Input a Expected output
I1 500 22.36
I2 10 Invalid input
I3 1100 Invalid input

The output domain is also partitioned to generate equivalence classes. We generate the
following output domain equivalence classes:
O1 = {Square root of input value a}
O2 = {Invalid value}
 Software Testing  371
The test cases for the output domain are given in Table 9.17. Some of the input and output
domain test cases may be the same.

Table 9.17 Test cases of ‘square root’ program for output domain
Test case Input a Expected output
O1 500 22.36
O2 1100 Invalid input

We consider the ‘subtraction’ program which takes two inputs a (range 100–1000) and b
(range 200–1200) and performs the subtraction of these two input values. On the basis of the
input domain, we generate the following equivalence classes:
(i) I1 = {100  a  1000 and 200  b  1200} (Both a and b are valid values)
(ii) I2 = {100  a  1000 and b < 200} (a is valid and b is invalid)
(iii) I3 = {100  a  1000 and b > 1200} (a is valid and b is invalid)
(iv) I4 = {a < 100 and 200  b  1200} (a is invalid and b is valid)
(v) I5 = {a > 1000 and 200  b  1200} (a is invalid and b is valid)
(vi) I6 = {a < 100 and b < 200} (Both inputs are invalid)
(vii) I7 = {a < 100 and b > 1200} (Both inputs are invalid)
(viii) I8 = {a > 1000 and b < 200} (Both inputs are invalid)
(ix) I9 = {a > 1000 and b > 1200} (Both inputs are invalid)
The input domain test cases are given in Table 9.18.

Table 9.18 Test cases of ‘subtraction’ program for input domain

Test case a b Expected output
I1 600 300 300
I2 600 100 Invalid input
I3 600 1300 Invalid input
I4 10 300 Invalid input
I5 1100 300 Invalid input
I6 10 100 Invalid input
I7 10 1300 Invalid input
I8 1100 100 Invalid input
I9 1100 1300 Invalid input

The output domain equivalence classes are given as follows:

O1 = {subtraction of two values a and b}
O2 = {Invalid input}
372  Object-Oriented Software Engineering

The test cases for the output domain are given in Table 9.19.

Table 9.19 Test cases of ‘subtraction’ program for output domain

Test case a b Expected output
O1 600 300 300
O2 10 300 Invalid input

We have designed only one equivalence class for the valid input domain in both of the
above discussed examples. We could not partition the valid input domain due to simplicity of
the problem. However, programs are more complex and logic oriented. We may design more
valid input domain equivalence classes on the basis of logic and relationship. The design of
equivalence classes is subjective and two designers may design different classes. The objective
is to cover every functionality of the program which may further cover maximum portion of
the source code during testing. This technique is applicable at unit, integration system and
acceptance testing levels. This is a very effective technique if equivalence classes are designed
correctly and also reduces the number of test cases significantly.
EXAMPLE 9.5 Consider a program to multiply and divide two numbers. The inputs may be
two valid integers (say a and b) in the range of [0, 100]. Develop test cases using equivalence
class testing.
Solution The test cases are generated for output domain given in Table 9.20:

Table 9.20 Test cases for output domain

Test case a b Expected output
Multiply Divide
O1 50 50 2500 1
O2 101 50 Input values are out of range

The equivalence classes for input domain are shown below:

(i) I1 = {0  a  100 and 0  b  100} (Both a and b are valid values)
(ii) I2 = {0  a  100 and b < 0} (a is valid and b is invalid)
(iii) I3 = {0  a  100 and b > 100} (a is valid and b is invalid)
(iv) I4 = {a < 0 and 0  b  100} (a is invalid and b is valid)
(v) I5 = {a > 100 and 0  b  100} (a is invalid and b is valid)
(vi) I6 = {a < 0 and b < 0} (Both inputs are invalid)
(vii) I7 = {a < 0 and b > 100} (Both inputs are invalid)
(viii) I8 = {a > 100 and b < 0} (Both inputs are invalid)
(ix) I9 = {a > 100 and b > 100} (Both inputs are invalid)
The test cases for input domain are given in Table 9.21.
 Software Testing  373
Table 9.21 Test cases for input domain
Test case a b Expected output
I1 50 50 2500 1
I2 50 –1 Input values are out of range
I3 50 101 Input values are out of range
I4 –1 50 Input values are out of range
I5 101 50 Input values are out of range
I6 –1 –1 Input values are out of range
I7 –1 101 Input values are out of range
I8 101 –1 Input values are out of range
I9 101 101 Input values are out of range

EXAMPLE 9.6 Consider the program for determining whether the date is valid or not. Identify
the equivalence class test cases for output and input domains.
Solution Output domain equivalence classes are:
O1 = {< Day, Month, Year > : Valid}
O2 = {< Day, Month, Year > : Invalid date if any of the inputs is invalid}
O3 = {< Day, Month, Year > : Input is out of range if any of the inputs is out of range}
The output domain test cases are given in Table 9.22.

Table 9.22 Output domain equivalence class test cases

Test case Month Day Year Expected output
O1 6 11 1979 Valid date
O2 6 31 1979 Invalid date
O3 6 32 1979 Inputs out of range

The input domain is partitioned as given below:

(i) Valid partitions
M1: Month has 30 days
M2: Month has 31 days
M3: Month is February
D1: Days of a month from 1 to 28
D2: Day = 29
D3: Day = 30
D4: Day = 31
Y1: 1900  year  2058 and is a common year
Y2: 1900  year  2058 and is a leap year
(ii) Invalid partitions
M4: Month < 1
M5: Month > 12
D5: Day < 1
374  Object-Oriented Software Engineering

D6: Day > 31

Y3: Year < 1900
Y4: Year > 2058
We may have the following set of test cases which are based on input domain:
(a) Only for valid input domain
I1 = {M1 and D1 and Y1} (All inputs are valid)
I2 = {M2 and D1 and Y1} (All inputs are valid)
I3 = {M3 and D1 and Y1} (All inputs are valid)
I4 = {M1 and D2 and Y1} (All inputs are valid)
I5 = {M2 and D2 and Y1} (All inputs are valid)
I6 = {M3 and D2 and Y1} (All inputs are valid)
I7 = {M1 and D3 and Y1} (All inputs are valid)
I8 = {M2 and D3 and Y1} (All inputs are valid)
I9 = {M3 and D3 and Y1} (All inputs are valid)
I10 = {M1 and D4 and Y1} (All inputs are valid)
I11 = {M2 and D4 and Y1} (All inputs are valid)
I12 = {M3 and D4 and Y1} (All inputs are valid)
I13 = {M1 and D1 and Y2} (All Inputs are valid)
I14 = {M2 and D1 and Y2} (All inputs are valid)
I15 = {M3 and D1 and Y2} (All inputs are valid)
I16 = {M1 and D2 and Y2} (All inputs are valid)
I17 = {M2 and D2 and Y2} (All inputs are valid)
I18 = {M3 and D2 and Y2} (All inputs are valid)
I19 = {M1 and D3 and Y2} (All inputs are valid)
I20 = {M2 and D3 and Y2} (All inputs are valid)
I21 = {M3 and D3 and Y2} (All inputs are valid)
I22 = {M1 and D4 and Y2} (All inputs are valid)
I23 = {M2 and D4 and Y2} (All inputs are valid)
I24 = {M3 and D4 and Y2} (All inputs are valid)
(b) Only for invalid input domain
I25 = {M4 and D1 and Y1} (Month is invalid, Day is valid and Year is valid)
I26 = {M5 and D1 and Y1} (Month is invalid, Day is valid and Year is valid)
I27 = {M4 and D2 and Y1} (Month is invalid, Day is valid and Year is valid)
I28 = {M5 and D2 and Y1} (Month is invalid, Day is valid and Year is valid)
I29 = {M4 and D3 and Y1} (Month is invalid, Day is valid and Year is valid)
I30 = {M5 and D3 and Y1} (Month is invalid, Day is valid and Year is valid)
I31 = {M4 and D4 and Y1} (Month is invalid, Day is valid and Year is valid)
I32 = {M5 and D4 and Y1} (Month is invalid, Day is valid and Year is valid)
I33 = {M4 and D1 and Y2} (Month is invalid, Day is valid and Year is valid)
I34 = {M5 and D1 and Y2} (Month is invalid, Day is valid and Year is valid)
 Software Testing  375

I35 = {M4 and D2 and Y2} (Month is invalid, Day is valid and Year is valid)
I36 = {M5 and D2 and Y2} (Month is invalid, Day is valid and Year is valid)
I37 = {M4 and D3 and Y2} (Month is invalid, Day is valid and Year is valid)
I38 = {M5 and D3 and Y2} (Month is invalid, Day is valid and Year is valid)
I39 = {M4 and D4 and Y2} (Month is invalid, Day is valid and Year is valid)
I40 = {M5 and D4 and Y2} (Month is invalid, Day is valid and Year is valid)
I41 = {M1 and D5 and Y1} (Month is valid, Day is invalid and Year is valid)
I42 = {M1 and D6 and Y1} (Month is valid, Day is invalid and Year is valid)
I43 = {M2 and D5 and Y1} (Month is valid, Day is invalid and Year is valid)
I44 = {M2 and D6 and Y1} (Month is valid, Day is invalid and Year is valid)
I45 = {M3 and D5 and Y1} (Month is valid, Day is invalid and Year is valid)
I46 = {M3 and D6 and Y1} (Month is valid, Day is invalid and Year is valid)
I47 = {M1 and D5 and Y2} (Month is valid, Day is invalid and Year is valid)
I48 = {M1 and D6 and Y2} (Month is valid, Day is invalid and Year is valid)
I49 = {M2 and D5 and Y2} (Month is valid, Day is invalid and Year is valid)
I50 = {M2 and D6 and Y2} (Month is valid, Day is invalid and Year is valid)
I51 = {M3 and D5 and Y2} (Month is valid, Day is invalid and Year is valid)
I52 = {M3 and D6 and Y2} (Month is valid, Day is invalid and Year is valid)
I53 = {M1 and D1 and Y3} (Month is valid, Day is valid and Year is invalid)
I54 = {M1 and D1 and Y4} (Month is valid, Day is valid and Year is invalid)
I55 = {M2 and D1 and Y3} (Month is valid, Day is valid and Year is invalid)
I56 = {M2 and D1 and Y4} (Month is valid, Day is valid and Year is invalid)
I57 = {M3 and D1 and Y3} (Month is valid, Day is valid and Year is invalid)
I58 = {M3 and D1 and Y4} (Month is valid, Day is valid and Year is invalid)
I59 = {M1 and D2 and Y3} (Month is valid, Day is valid and Year is invalid)
I60 = {M1 and D2 and Y4} (Month is valid, Day is valid and Year is invalid)
I61 = {M2 and D2 and Y3} (Month is valid, Day is valid and Year is invalid)
I62 = {M2 and D2 and Y4} (Month is valid, Day is valid and Year is invalid)
I63 = {M3 and D2 and Y3} (Month is valid, Day is valid and Year is invalid)
I64 = {M3 and D2 and Y4} (Month is valid, Day is valid and Year is invalid)
I65 = {M1 and D3 and Y3} (Month is valid, Day is valid and Year is invalid)
I66 = {M1 and D3 and Y3} (Month is valid, Day is valid and Year is invalid)
I67 = {M2 and D3 and Y3} (Month is valid, Day is valid and Year is invalid)
I68 = {M2 and D3 and Y4} (Month is valid, Day is valid and Year is invalid)
I69 = {M3 and D3 and Y3} (Month is valid, Day is valid and Year is invalid)
I70 = {M3 and D3 and Y4} (Month is valid, Day is valid and Year is invalid)
I71 = {M1 and D4 and Y3} (Month is valid, Day is valid and Year is invalid)
I72 = {M1 and D4 and Y4} (Month is valid, Day is valid and Year is invalid)
I73 = {M2 and D4 and Y3} (Month is valid, Day is valid and Year is invalid)
I74 = {M2 and D4 and Y4} (Month is valid, Day is valid and Year is invalid)
376  Object-Oriented Software Engineering

I75 = {M3 and D4 and Y3} (Month is valid, Day is valid and Year is invalid)
I76 = {M3 and D4 and Y4} (Month is valid, Day is valid and Year is invalid)
I77 = {M4 and D5 and Y1} (Month is invalid, Day is invalid and Year is valid)
I78 = {M4 and D5 and Y2} (Month is invalid, Day is invalid and Year is valid)
I79 = {M4 and D6 and Y1} (Month is invalid, Day is invalid and Year is valid)
I80 = {M4 and D6 and Y2} (Month is invalid, Day is invalid and Year is valid)
I81 = {M5 and D5 and Y1} (Month is invalid, Day is invalid and Year is valid)
I82 = {M5 and D5 and Y2} (Month is invalid, Day is invalid and Year is valid)
I83 = {M5 and D6 and Y1} (Month is invalid, Day is invalid and Year is valid)
I84 = {M5 and D6 and Y2} (Month is invalid, Day is invalid and Year is valid)
I85 = {M4 and D1 and Y3} (Month is invalid, Day is valid and Year is invalid)
I86 = {M4 and D1 and Y4} (Month is invalid, Day is valid and Year is invalid)
I87 = {M4 and D2 and Y3} (Month is invalid, Day is valid and Year is invalid)
I88 = {M4 and D2 and Y4} (Month is invalid, Day is valid and Year is invalid)
I89 = {M4 and D3 and Y3} (Month is invalid, Day is valid and Year is invalid)
I90 = {M4 and D3 and Y4} (Month is invalid, Day is valid and Year is invalid)
I91 = {M4 and D4 and Y3} (Month is invalid, Day is valid and Year is invalid)
I92 = {M4 and D4 and Y4} (Month is invalid, Day is valid and Year is invalid)
I93 = {M5 and D1 and Y3} (Month is invalid, Day is valid and Year is invalid)
I94 = {M5 and D1 and Y4} (Month is invalid, Day is valid and Year is invalid)
I95 = {M5 and D2 and Y3} (Month is invalid, Day is valid and Year is invalid)
I96 = {M5 and D2 and Y4} (Month is invalid, Day is valid and Year is invalid)
I97 = {M5 and D3 and Y3} (Month is invalid, Day is valid and Year is invalid)
I98 = {M5 and D3 and Y4} (Month is invalid, Day is valid and Year is invalid)
I99 = {M5 and D4 and Y3} (Month is invalid, Day is valid and Year is invalid)
I100 = {M5 and D4 and Y4} (Month is invalid, Day is valid and Year is invalid)
I101 = {M1 and D5 and Y3} (Month is valid, Day is invalid and Year is invalid)
I102 = {M1 and D5 and Y4} (Month is valid, Day is invalid and Year is invalid)
I103 = {M2 and D5 and Y3} (Month is valid, Day is invalid and Year is invalid)
I104 = {M2 and D5 and Y4} (Month is valid, Day is invalid and Year is invalid)
I105 = {M3 and D5 and Y3} (Month is valid, Day is invalid and Year is invalid)
I106 = {M3 and D5 and Y4} (Month is valid, Day is invalid and Year is invalid)
I107 = {M1 and D6 and Y3} (Month is valid, Day is invalid and Year is invalid)
I108 = {M1 and D6 and Y4} (Month is valid, Day is invalid and Year is invalid)
I109 = {M2 and D6 and Y3} (Month is valid, Day is invalid and Year is invalid)
I110 = {M2 and D6 and Y4} (Month is valid, Day is invalid and Year is invalid)
I111 = {M3 and D6 and Y3} (Month is valid, Day is invalid and Year is invalid)
I112 = {M3 and D6 and Y4} (Month is valid, Day is invalid and Year is invalid)
I113 = {M4 and D5 and Y3} (All inputs are invalid)
 Software Testing  377
I114 = {M4 and D5 and Y4} (All inputs are invalid)
I115 = {M4 and D6 and Y3} (All inputs are invalid)
I116 = {M4 and D6 and Y4} (All inputs are invalid)
I117 = {M5 and D5 and Y3} (All inputs are invalid)
I118 = {M5 and D5 and Y4} (All inputs are invalid)
I119 = {M5 and D6 and Y3} (All inputs are invalid)
I120 = {M5 and D6 and Y4} (All inputs are invalid)
The test cases generated on the basis of input domain are given in Table 9.23.

Table 9.23 Input domain equivalence class test cases

Test case Month Day Year Expected output
I1 6 15 2035 Valid date
I2 5 15 2035 Valid date
I3 2 15 2035 Valid date
I4 6 29 2035 Valid date
I5 5 29 2035 Valid date
I6 2 29 2035 Invalid date
I7 6 30 2035 Valid date
I8 5 30 2035 Valid date
I9 2 30 2035 Invalid date
I10 6 31 2035 Invalid date
I11 5 31 2035 Valid date
I12 2 31 2035 Invalid date
I13 6 15 2000 Valid date
I14 5 15 2000 Valid date
I15 2 15 2000 Valid date
I16 6 29 2000 Valid date
I17 5 29 2000 Valid date
I18 2 29 2000 Valid date
I19 6 30 2000 Valid date
I20 5 30 2000 Valid date
I21 2 30 2000 Invalid date
I22 6 31 2000 Invalid date
I23 5 31 2000 Valid date
I24 2 31 2000 Invalid date
I25 0 15 2035 Input(s) out of range
I26 13 15 2035 Input(s) out of range
I27 0 29 2035 Inputs(s) out of range
I28 13 29 2035 Input(s) out of range

(Contd.)
378  Object-Oriented Software Engineering

Table 9.23 Input domain equivalence class test cases (Contd.)

Test case Month Day Year Expected output
I29 0 30 2035 Input(s) out of range
I30 13 30 2035 Input(s) out of range
I31 0 31 2035 Input(s) out of range
I32 13 31 2035 Input(s) out of range
I33 0 15 2000 Input(s) out of range
I34 13 15 2000 Input(s) out of range
I35 0 29 2000 Input(s) out of range
I36 13 29 2000 Input(s) out of range
I37 0 30 2000 Input(s) out of range
I38 13 30 2000 Input(s) out of range
I39 0 31 2000 Input(s) out of range
I40 13 31 2000 Input(s) out of range
I41 6 0 2035 Input(s) out of range
I42 6 32 2035 Input(s) out of range
I43 5 0 2035 Input(s) out of range
I44 5 32 2035 Input(s) out of range
I45 2 0 2035 Input(s) out of range
I46 2 32 2035 Input(s) out of range
I47 6 0 2000 Input(s) out of range
I48 6 32 2000 Input(s) out of range
I49 5 0 2000 Input(s) out of range
I50 5 32 2000 Input(s) out of range
I51 2 0 2000 Input(s) out of range
I52 2 32 2000 Input(s) out of range
I53 6 15 1899 Input(s) out of range
I54 6 15 2059 Input(s) out of range
I55 5 15 1899 Input(s) out of range
I56 5 15 2059 Input(s) out of range
I57 2 15 1899 Input(s) out of range
I58 2 15 2059 Input(s) out of range
I59 6 29 1899 Input(s) out of range
I60 6 29 2059 Input(s) out of range
I61 5 29 1899 Input(s) out of range
I62 5 29 2059 Input(s) out of range
I63 2 29 1899 Input(s) out of range
I64 2 29 2059 Input(s) out of range
I65 6 30 1899 Input(s) out of range

(Contd.)
 Software Testing  379

Table 9.23 Input domain equivalence class test cases (Contd.)

Test case Month Day Year Expected output
I66 6 30 2059 Input(s) out of range
I67 5 30 1899 Input(s) out of range
I68 5 30 2059 Input(s) out of range
I69 2 30 1899 Input(s) out of range
I70 2 30 2059 Input(s) out of range
I71 6 31 1899 Input(s) out of range
I72 6 31 2059 Input(s) out of range
I73 5 31 1899 Input(s) out of range
I74 5 31 2059 Input(s) out of range
I75 2 31 1899 Input(s) out of range
I76 2 31 2059 Input(s) out of range
I77 0 0 2035 Input(s) out of range
I78 0 0 2000 Input(s) out of range
I79 0 32 2035 Input(s) out of range
I80 0 32 2000 Input(s) out of range
I81 13 0 2035 Input(s) out of range
I82 13 0 2000 Input(s) out of range
I83 13 32 2035 Input(s) out of range
I84 13 32 2000 Input(s) out of range
I85 0 15 1899 Input(s) out of range
I86 0 15 2059 Input(s) out of range
I87 0 20 1899 Input(s) out of range
I88 0 29 2059 Input(s) out of range
I89 0 30 1899 Input(s) out of range
I90 0 30 2059 Input(s) out of range
I91 0 31 1899 Input(s) out of range
I92 0 31 2059 Input(s) out of range
I93 13 15 1899 Input(s) out of range
I94 13 15 2059 Input(s) out of range
I95 13 29 1899 Input(s) out of range
I96 13 29 2059 Input(s) out of range
I97 13 30 1899 Input(s) out of range
I98 13 30 2059 Input(s) out of range
I99 13 31 1899 Input(s) out of range
I100 13 31 2059 Input(s) out of range
I101 5 0 1899 Input(s) out of range
I102 5 0 2059 Input(s) out of range

(Contd.)
380  Object-Oriented Software Engineering

Table 9.23 Input domain equivalence class test cases (Contd.)

Test case Month Day Year Expected output
I103 6 0 1899 Input(s) out of range
I104 6 0 2059 Input(s) out of range
I105 2 0 1899 Input(s) out of range
I106 2 0 2059 Input(s) out of range
I107 5 32 1899 Input(s) out of range
I108 5 32 2059 Input(s) out of range
I109 6 32 1899 Input(s) out of range
I110 6 32 2059 Input(s) out of range
I111 2 32 1899 Input(s) out of range
I112 2 32 2059 Input(s) out of range
I113 0 0 1899 Input(s) out of range
I114 0 0 2059 Input(s) out of range
I115 0 32 1899 Input(s) out of range
I116 0 32 2059 Input(s) out of range
I117 13 0 1899 Input(s) out of range
I118 13 0 2059 Input(s) out of range
I119 13 32 1899 Input(s) out of range
I120 13 32 2059 Input(s) out of range

9.4.3 Decision Table-Based Testing

Decision tables are commonly used in engineering disciplines to represent complex logical
relationships. They are effective to model situations where an output is dependent on many
input conditions. Software testers have also found their applications in testing and a technique is
developed which is known as decision table-based testing. There are four portions of a decision
table, namely, condition stubs, condition entries, action stubs and action entries. A typical
decision table is shown in Table 9.24.

Table 9.24 Portion of the decision table

Stubs Entries
Condition All conditions are Inputs are shown on the basis of conditions. There
shown. are columns and each column represents a rule.
Action All actions are shown. Represent the outputs on the basis of various input
conditions.

There are two types of decision tables. The first type is called the limited entry decision
table where input values represent only the true and false condition as shown in Table 9.25.
 Software Testing  381
Table 9.25 Limited entry decision table
Condition stub Condition entry
c1 T F F F F
c2 - T F F F
c3 - - T F F
- - - T F
a1 X X
a2 X X
a3 X X

Every column of the decision table represents a rule and generates a test case. A ‘-’ in the
condition entry represents a ‘do not care’ condition. An ‘X’ in the action entry represents the
action mentioned in the corresponding action stub. In Table 9.25, if condition c1 is true, then c2,
c3 and c4 become ‘do not care’ conditions and actions a1 and a3 are to be performed.
The second type of decision table is called extended entry decision table. In such a table,
multiple conditions are used instead of true and false conditions. A condition may have many
options instead of only true and false and such options are represented in the extended entry
decision table.
We consider a program which takes a date as an input and checks whether it is a valid date
or not. We prepare the following classes (options) and represent them in the extended entry
decision table as shown in Table 9.26.
I1 = {M1 : Month has 30 days}
I2 = {M2 : Month has 31 days}
I3 = {M3 : Month is February}
I4 = {M4 : Month <1}
I5 = {M5 : Month > 12}
I6 = {D1 : 1  Day  28}
I7 = {D2 : Day = 29}
I8 = {D3 : Day = 30}
I9 = {D4 : Day = 31}
I10 = {D5 : Day < 1}
I11 = {D6 : Day > 31}
I12 = {Y1 : 1900  Year  2058 and is a common year}
I13 = {Y2 : 1900  Year  2058 and is a leap year}
I14 = {Y3 : Year < 1900}
I15 = {Y4 : Year > 2058}
In the decision table, various combinations of conditions are considered and that may
sometimes result into an impossible action. In such a situation, we may incorporate an additional
action ‘impossible condition’ in the action stub. We may change the design of equivalence classes
to reduce the impossible conditions.
 Table 9.26 Decision table of date program
382
Test case 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20


c1 : Months in M1 M1 M1 M1 M1 M1 M1 M1 M1 M1 M1 M1 M1 M1 M1 M1 M1 M1 M2 M2
c2 : Days in D1 D1 D1 D1 D2 D2 D2 D2 D3 D3 D3 D3 D4 D4 D4 D4 D5 D6 D1 D1
c3 : Years in Y1 Y2 Y3 Y4 Y1 Y2 Y3 Y4 Y1 Y2 Y3 Y4 Y1 Y2 Y3 Y4 - - Y1 Y2
Rule count 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 4 4 1 1
a1 : Invalid date X X
a2 : Valid date X X X X X X X X
a3 : Input out of range X X X X X X X X X X

Test case 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37
c1 : Months in M2 M2 M2 M2 M2 M2 M2 M2 M2 M2 M2 M2 M2 M2 M2 M2 M3
Object-Oriented Software Engineering

c2 : Days in D1 D1 D2 D2 D2 D2 D3 D3 D3 D3 D4 D4 D4 D4 D5 D6 D1
c3 : Years in Y3 Y4 Y1 Y2 Y3 Y4 Y1 Y2 Y3 Y4 Y1 Y2 Y3 Y4 - - Y1
Rule count 1 1 1 1 1 1 1 1 1 1 1 1 1 1 4 4 1
a1 : Invalid date
a2 : Valid date X X X X X X X
a3 : Input out of range X X X X X X X X X X

Test case 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56
c1 : Months in M3 M3 M3 M3 M3 M3 M3 M3 M3 M3 M3 M3 M3 M3 M3 M3 M3 M4 M5
c2 : Days in D1 D1 D1 D2 D2 D2 D2 D3 D3 D3 D3 D4 D4 D4 D4 D5 D6 - -
c3 : Years in Y2 Y3 Y4 Y1 Y2 Y3 Y4 Y1 Y2 Y3 Y4 Y1 Y2 Y3 Y4 - - - -
Rule count 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 24 24
a1 : Invalid date X X X X X
a2 : Valid date X X
a3 : Input out of range X X X X X X X X X X X X
 Software Testing  383
Decision tables are used in situations where an output is dependent on many input conditions.
Complex relationships can also be easily represented in such tables. Every column may generate
a test case. The test cases of decision Table 9.26 are given in Table 9.27.

Table 9.27 Test cases of the program of date problem

Test case Month Day Year Expected output
1 6 15 1979 Valid date
2 6 15 2000 Valid date
3 6 15 1899 Input out of range
4 6 15 2059 Input out of range
5 6 29 1979 Valid date
6 6 29 2000 Valid date
7 6 29 1899 Input out of range
8 6 29 2059 Input out of range
9 6 30 1979 Valid date
10 6 30 2000 Valid date
11 6 30 1899 Input out of range
12 6 30 2059 Input out of range
13 6 31 1979 Invalid date
14 6 31 2000 Invalid date
15 6 31 1899 Input out of range
16 6 31 2059 Input out of range
17 6 0 1979 Input out of range
18 6 32 1979 Input out of range
19 5 15 1979 Valid date
20 5 15 2000 Valid date
21 5 15 1899 Input out of range
22 5 15 2059 Input out of range
23 5 29 1979 Valid date
24 5 29 2000 Valid date
25 5 29 1899 Input out of range
26 5 29 2059 Input out of range
27 5 30 1979 Valid date
28 5 30 2000 Valid date
29 5 30 1899 Input out of range
30 5 30 2059 Input out of range
31 5 31 1979 Valid date
32 5 31 2000 Valid date
33 5 31 1899 Input out of range
(Contd.)
384  Object-Oriented Software Engineering

Table 9.27 Test cases of the program of date problem (Contd.)

Test case Month Day Year Expected output
34 5 31 2059 Input out of range
35 5 0 1979 Input out of range
36 5 32 1979 Input out of range
37 2 15 1979 Valid date
38 2 15 2000 Valid date
39 2 15 1899 Input out of range
40 2 15 2059 Input out of range
41 2 29 1979 Invalid date
42 2 29 2000 Valid date
43 2 29 1899 Input out of range
44 2 29 2059 Input out of range
45 2 30 1979 Invalid date
46 2 30 2000 Invalid date
47 2 30 1899 Input out of range
48 2 30 2059 Input out of range
49 2 31 1979 Invalid date
50 2 31 2000 Invalid date
51 2 31 1899 Input out of range
52 2 31 2059 Input out of range
53 2 0 1979 Input out of range
54 2 32 1979 Input out of range
55 0 0 1899 Input out of range
56 13 32 1899 Input out of range

Decision tables are effectively applicable to small-size programs. As the size increases,
handling becomes difficult and time consuming. We can easily apply the decision table at the
unit level. System testing and integration testing do not find its applicability in any reasonable-
size program.

EXAMPLE 9.7 Consider a program to multiply and divide two numbers. The inputs may be
two valid integers (say a and b) in the range of [0, 100]. Develop the decision table and generate
test cases.
Solution The decision table is given in Table 9.28 and the test cases are given in Table 9.29.
 Software Testing  385
Table 9.28 Decision table for a program to multiply and divide two numbers
Input in valid range? F T T T T
a = 0? - T T F F
b = 0? - T F T F
Input values out of range X
Valid output X X
Output undefined X
Divide by zero error X

Table 9.29 shows the test cases generated from the above decision table.

Table 9.29 Test cases for decision table shown in Table 9.28
Test case a b Expected output
1 50 –1 Input values are out of range
2 0 0 Output undefined
3 0 50 0 0
4 30 0 Divide by zero error
5 50 50 2500 1

9.5 Structural Testing

Structural testing is complementary to functional testing where the source code is considered
for the design of test cases rather than specifications. We focus on the internal structure of the
source code and ignore the functionality of the program. Structural testing is also called white
box testing and attempts to examine the source code rigorously and thoroughly to understand it
correctly. The clear and correct understanding of the source code may find complex and weak
areas and test cases are generated accordingly.

9.5.1 Path Testing

It is a popular structural testing technique. The source code of the program is converted into a
program graph which represents the flow of control in terms of directed graphs. The program is
further converted into the decision to decision (DD) path graph. Both graphs are commonly used
in structural testing techniques for the generation of test cases.
A program graph is a graphical representation of the source code where statements of the
program are represented by nodes and flow of control by edges. Jorgenson (2007) has defined
program graph as:
A program graph is a directed graph in which nodes are either statements or fragments of a
statement and edges represent flow of control.

The program graph provides the graphical view of the program and may become the
foundation of many testing techniques. The fundamental constructs of the program graph are
given in Figure 9.7.
386  Object-Oriented Software Engineering

Figure 9.7 Basic constructs of a program graph.

A program can be converted into a program graph using fundamental constructs. We

consider a program to determine whether a number is even or odd. The program is given in
Figure 9.8 and its program graph is given in Figure 9.9. There are 16 statements in the program
and hence 16 nodes in the program graph corresponding to every statement.

#include<stdio.h>
#include<conio.h>
1 void main()
2 {
3 int num;
4 clrscr() ;
5 cout<<"Enter number" ;
6 cin>>num ;
Figure 9.8 (Contd.)
 Software Testing  387

7 if(num%2==0)
8 {
9 cout<<"Number is even";
10 }
11 else
12 {
13 cout<<"Number is odd";
14 }
15 getch();
16 }
Figure 9.8 Program to determine whether a number is even or odd.

A path in a graph is a sequence of adjacent nodes where nodes in sequence share a common
edge or sequence of adjacent pair of edges where edges in sequence share a common node. It is
clear from the program graph that there are two paths in the graph.

Figure 9.9 Program graph of source code given in Figure 9.8.

These paths are 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 15, 16 and 1, 2, 3, 4, 5, 6, 7, 11, 12, 13, 14, 15, 16.
Every program graph has one source node and one destination node. In the program graph given
in Figure 9.9, nodes 1 to 6 are in sequence, node 7 has two outgoing edges (predicate node) and
node 15 is a junction node.
A program graph can be converted into a DD program graph. There are many nodes in
the program graph which are in a sequence like nodes 1 to 6 of the program graph given in
Figure 9.9. When we enter into the sequence through the first node, we can exit only from the
last node of the sequence. In the DD path graph, all nodes which are in a sequence are combined
and represented by a single node. The DD path graph is a directed graph in which nodes are the
388  Object-Oriented Software Engineering

sequence of statements and edges are the control flow amongst the nodes. All DD path graphs have
a source node and a destination node similar to the program graph. A mapping table is prepared
to match the nodes of the DD path graph to the corresponding nodes of the program graph. All
sequential nodes are combined into a single node which reduces the size of the DD path graph.
Mapping table of the program graph given in Figure 9.9 is presented in Table 9.30.

Table 9.30 DD path graph

S. No. Program graph nodes DD path graph Comments
corresponding nodes
1 1 S Source node
2 2–6 N1 Sequential nodes
3 7 N2 Decision node
4 8–10 N3 Sequential nodes
5 11–14 N4 Sequential nodes
6 15 N5 Junction node
7 16 D Destination node

The corresponding DD path graph is given in Figure 9.10. There are two paths, namely, S,
N1, N2, N3, N5, D and S, N1, N2, N4, N5, D. Paths in the program are identified from the DD
path graph easily. We may like to see the behaviour of the program when every identified path
is executed. Hence, we may design test cases in such a way that at least every identified path is
executed during testing.

Figure 9.10 DD path graph.

Role of Independent Paths

The DD path graph is used to find independent paths. An independent path is a path through the
DD path graph that introduces at least one new node or edge in its sequence from initial node
to its final node. As we know, there are many paths in any program. If there are loops in the
program (which is very common), the number of paths may increase and the same set of nodes
 Software Testing  389
and edges may be traversed again and again. It may not be desirable to execute every path of
any reasonable size program due to the repetition of the same set of statements and consumption
of significant amount of time and resources. We may at least wish to execute every independent
path of the DD path graph to ensure the minimum level of coverage of the source code and
ascertain some confidence about the correctness of the program.
The number of independent paths can be found using a concept of graph theory which is
called cyclomatic number. The same concept was redefined by McCabe (1976) as cyclomatic
complexity for the identification of independent paths. There are three ways to calculate the
cyclomatic complexity which are given below:
(i) V(G) = e – n + 2P
where
V(G) = cyclomatic complexity
G = graph
n = number of nodes
e = number of edges
P = number of connected components
The graph (G) is a directed graph with a single entry node and a single exit node. If this
graph is a connected graph, the value of P will be 1. If there are parts of the graph, the
value of P will be the number of parts of the graph.
(ii) V(G) = number of regions of the program graph
(iii) V(G) = number of predicate nodes (p) + 1
This is applicable only when the predicate node has two outgoing edges (“true” or “false”). If
there are more than two outgoing edges, then this method is not applicable.
Properties of cyclomatic complexity:
 V(G) ≥ 1.
 V(G) is the maximum number of independent paths in the graph G.
 Addition or deletion of functional statements to graph G does not affect V(G).
 G has only one path if V(G) = 1.
 V(G) depends only on the decision structure of G.
The cyclomatic complexity of the DD path graph given in Figure 9.10 can be calculated as:
(i) V(G) = e – n + 2P
   = 7 – 7 + 2
   = 2
(ii) V(G) = No. of regions of the graph
Hence, V(G) = 2
One is the inner region constituted by nodes N2, N3, N4 and N5 and the second is the
outer region of the graph.
(iii) V(G) = p + 1
   = 1 + 1 = 2
The cyclomatic complexity is 2 which is calculated by all the three methods. Hence, there are
two independent paths of this graph, namely, S, N1, N2, N3, N5, D and S, N1, N2, N4, N5, D.
390  Object-Oriented Software Engineering

Cyclomatic complexity also provides some insight into the complexity of a module.
McCabe (1976) proposed an upper limit of cyclomatic complexity to 10 with significant
supporting evidence. We may go up to 15 in today’s scenario of new programming languages,
availability of CASE tools, effective validation and verification techniques, and implementation
of software engineering principles and practices. If the limit further exceeds, it is advisable to
redesign the module and maintain the cyclomatic complexity within prescribed limits.

Issues in Path Testing

In practice, we should test every path of the program. However, this number may be too large in
most of the programs due to the presence of loops and feedback connections. We may have
to set a lower objective which may be set to execute at least all independent paths. We consider
the program to determine “whether a number is even or odd” (given in Figure 9.8) along with its
program graph (given in Figure 9.9). We find that there are two independent paths as given below:
Path 1: S, N1, N2, N3, N5, D
Path 2: S, N1, N2, N4, N5, D
We may design test cases in such a way that both paths are executed. The test cases are given
in Table 9.31.

Table 9.31 Test cases for program given in Figure 9.8

S. No. Path ID Paths Inputs Expected output
1 Path 1 S, N1, N2, N3, N5, D 6 Number is even
2 Path 2 S, N1, N2, N4, N5, D 7 Number is odd

The program graph may generate a few paths which are impossible in practice. When we
give inputs, some paths may not be possible to traverse due to logic of the program. Hence, some
paths are impossible to create and traverse and cannot be implemented. Path testing ensures
100% statement and branch coverage and guarantees a reasonable level of confidence about the
correctness of the program.

Generation of Paths Using Activity Diagram

We may also generate paths from the activity diagram. The details of an activity diagram are
available in Chapter 7 (refer to Section 7.1). Activity diagram represents the flow of activities
and is similar to the program graph. It may be generated from the use cases or from the classes.
We may convert a source code into its activity diagram and may find the number of independent
paths. The concept of cyclomatic complexity is still applicable with slight modifications. Nodes
of the program graph are represented as branches/activities/initial state/end state of an activity
diagram. The edges of the program graph are represented as transitions of the activity diagram.
Cyclomatic complexity is modified as
Cyclomatic complexity = Transitions – Activities/branches + 2P
The cyclomatic complexity of the activity diagram given in Figure 7.2 is calculated as:
Cyclomatic complexity = 8 – 8 + 2 = 2
There are two independent paths which is also evident from the activity diagram.
 Software Testing  391
After the identification of independent paths, we design test cases to execute these paths.
This ensures that every transition and every activity/branch of an activity diagram are traversed,
at least once, during execution. An activity diagram provides the pictorial view of the class and
helps us to identify independent paths. This technique is effectively applicable to a class of any
reasonable size.
EXAMPLE 9.8 Write a program for finding the roots of a quadratic equation. Draw the
activity diagram and calculate the cyclomatic complexity. Generate the test cases on the basis of
cyclomatic complexity.
Solution The program for finding the roots of a quadratic equation is given below:

#include<stdio.h>
#include<conio.h>

1 void main()
2 {
3 int a,b,c,validInput=0,d;
4 clrscr();
5 cout<<"Enter values of a, b & c:\n";
6 cin>>a>>b>>c;
7 if((a>=0)&&(a<=100)&&(b>=0)&&(b<=100)&&(c>=0)&&(c<=100)){
8 validInput=1;
9 if(a==0){
10 validInput=-1;
11 }
12 }
13 if(validInput==1){
14 d=b*b-4*a*c;
15 if(d==0){
16 cout<<"Equal roots";
17 }
18 else if(d>0){
19 cout<<"Real roots";
20 }
21 else{
22 cout<<"Imaginary roots";
23 }
24 }
25 else if(validInput==-1){
26 cout<<"Not quadratic";
27 }
28 else {
29 cout<<"The inputs are out of range";
30 }
31 getch();
32 }
392  Object-Oriented Software Engineering

The activity diagram for finding the roots of a quadratic equation is given in Figure 9.11.

Figure 9.11 Activity diagram for finding the roots of a quadratic equation.

Cyclomatic complexity = 22 – 17 + 2 = 7
 Software Testing  393
The test cases for independent paths are given in Table 9.32.

Table 9.32 Test cases for independent paths

S. No. a b c Expected output
1 101 50 50 Input values not in range
2 - - - -
3 - - - -
4 0 50 50 Not quadratic
5 99 0 0 Equal roots
6 50 50 1 Real roots
7 50 50 50 Imaginary roots

9.6 Class Testing

A class is a fundamental entity in object-oriented software development activities. Developers
define the attributes and operations of a class with utmost care. Operations are also known as
methods of a class. The class is treated as a unit which is similar to the module/function of
conventional programming. During testing, we may like to generate test cases on the basis of
structure of a class. Therefore, implementation of a class is tested with respect to its specifications.
We create instances of a class for the purpose of testing and test the behaviour of such instances.
The classes cannot be tested in isolation. We may have to write additional source code which
is too expensive and consumes huge amount of effort. In such situations, only inspections of
classes are recommended which may find faults. Classes are usually tested by their developers
due to their familiarity and understandability of the source code. Developers write additional
source code (stubs and drivers) and make the classes executable. We test classes with respect to
their specifications. If some unspecified behaviour is implemented, we may not be able to test it.
Therefore, unspecified behaviour should never be implemented. If it is necessary to implement,
changes should first be made in the SRS document and subsequently in analysis and design
documents. The systematic approach may help us to know the deviations and incorporate them
at proper places without any confusion. Hence, a disciplined and systematic procedure may
generate test cases for additional specifications and further test them accordingly.
The most popular way to design test cases is from pre- and postconditions as specified
in the use cases. Every operation of a class may have pre- and postconditions. An operation
(method) will be initiated only when a precondition is true. After the successful execution of
the operation, one or more postconditions may be generated. In class testing, we identify pre-
and postconditions for every operation of the class and establish logical relationships amongst
them. We should establish logical relationships when a precondition is true and also when a
precondition is false. Every logical relationship (true and false) will generate a test case and
finally we may be able to test the behaviour of a class for every operation and all in also possible
conditions.
We consider a class ‘queue’ as given in Figure 9.12 with three attributes (x, front, rear) and
three operations (queue( ), insert(x), remove( )).
394  Object-Oriented Software Engineering

Queue
x: integer
front: integer
rear: integer
Queue( )
Insert(x)
Remove( )
Figure 9.12 Structure of the class ‘queue’.

We identify all pre- and postconditions for every operation of class ‘queue’. There are three
operations and their pre- and postconditions are given as:
(i) Operation Queue: The purpose of this operation is to create a queue
Queue::queue( )
(a) Pre = true
(b) Post: front = 0, rear = 0
(ii) Operation Insert(x): This operation inserts an item x into the queue.
Queue::insert(x)
(a) Pre: rear < MAX
(b) Post: rear = rear + 1
(iii) Operation Remove( ): This operation removes an item from the front side of the queue.
Queue::remove( )
(a) Pre: front > 0
(b) Post: front = front + 1
We establish logical relationships between identified pre- and postconditions for insert(x) and
remove() operations.
Insert(x):
1. (precondition: rear < MAX; postcondition: rear = rear + 1)
2. (precondition: not (rear < MAX); postcondition: exception)
Similarly for remove( ) operation, the following logical relationships are established:
3. (precondition: front > 0; postcondition: front = front + 1)
4. (precondition: not (front > 0); postcondition: exception)
Test cases are generated for every established logical relationship of pre- and postconditions.
Test cases for insert(x) and remove( ) operations are given in Table 9.33.

Table 9.33 Test cases for two operations of class queue

S. No. Operation Test input Condition Expected output
1 Insert(x) 23 Rear < MAX Element ‘23’ inserted successfully
2 Insert(x) 34 Rear = MAX Stack overflow
3 Remove( ) - Front > 0 23
4 Remove( ) - Front = rear Stack underflow
 Software Testing  395

9.7 State-Based Testing

Statechart diagrams (given in Chapter 7) are used in state-based testing. As explained earlier,
they model the behaviour of an object from its creation to the end of its life cycle. The flow
of control from one state to another state is also represented graphically. Binder (1994) has
recommended two additional states a (alpha) and w (omega) for representing constructor and
destructor of a class. He has emphasized his concept as:
The a state is a null state representing the declaration of an object before its construction. It
may accept only a constructor, new, or a similar initialization message. The w state is reached
after an object has been destructed or deleted, or has gone out of scope. It allows for explicit
modeling and systematic testing of destructors, garbage collection, and other termination
actions.

We should not confuse with the start state and end state of the statechart diagram. a and w
are additional states and are represented explicitly in the statechart diagram. We consider an
example of a class ‘queue’ with two operations—insert and remove. The queue is based on
the principle of FIFO (first in first out) and there are three states: empty, holding and full. In
addition to these three states, two additional states a and w are also used. There are four events,
namely, new, insert, remove and destroy with the following objectives:
 New: Creates an empty queue.
 Insert: Inserts an element in the queue, if space is available.
 Remove: Removes an element from the queue, if it is available.
 Destroy: Destroys the queue after the completion of its requirement, i.e. object of the
queue class is destroyed.
We may draw the statechart diagram of the queue class as given in Figure 9.13.

Figure 9.13 Statechart diagram of queue class.

396  Object-Oriented Software Engineering

The statechart diagram gives the graphical view of the behaviour of the system. All
transitions are shown along with self-loop type transitions. In the above statechart diagram, the
holding state has two self-loops for the following purposes:
(i) When [rear < MAX – 1], we insert an element x and the same state is maintained.
(ii) When [front > 1], we remove an element, the same state is maintained.
If the number of states increases, it becomes difficult to draw the statechart diagram and keep
track of various transitions. In practice, the number of states is very large (more than 100 also)
and it may not be possible to draw a statechart diagram. Another option is to represent the
statechart diagram’s information in tabular form and this table is known as state transition
table. The row of the table represents the present state and the column represents the resultant
state. The state transition table of ‘queue’ class is given in Table 9.34. The state transition table
incorporates every information of the statechart diagram such as transitions, events and actions,
and may become the basis to design the test cases.

Table 9.34 State transition table for queue class

State Event/method Resultant state
 Empty Holding Full w

 new √
insert(x)
remove()
destroy
Empty new
insert(x)
remove()
destroy √
Holding new
insert(x) √ √
remove() √ √
destroy √
Full new
insert(x)
remove() √
destroy √

9.7.1 Design of Test Cases

The state transition diagrams are used to identify paths and test cases may be generated for the
execution of every path. There may be a large number of paths and it may not be advisable to
execute all transitions which will further cover all events, all states and all actions. Statechart
diagrams and statechart tables help us to achieve this objective and generate a good number of
 Software Testing  397
test cases. The test cases for ‘queue’ class are given in Table 9.35 which are based on the state
transition table as given in Table 9.34.

Table 9.35 Test cases

Test case ID Test case input Expected result
Event (method) Test condition Action State
1.1 New Empty
1.2 Insert(x) Holding
1.3 Remove( ) Front = 1 Return x Empty
1.4 Destroy w
2.1 New Empty
2.2 Insert(x) Holding
2.3 Remove( ) Front > 1 Return x Holding
2.4 Destroy w
3.1 New Empty
3.2 Insert(x) Holding
3.3 Insert(x) Rear < MAX – 1 Holding
3.4 Destroy w
4.1 New Empty
4.2 Insert(x) Holding
4.3 Insert(x) Rear = MAX – 1 Full
4.4 Remove( ) Holding
4.5 Destroy w
5.1 New Empty
5.2 Insert(x) Holding
5.3 Insert(x) Rear = MAX – 1 Full
5.4 Destroy w
6.1 New Empty
6.2 Destroy w

These test cases are systematic and cover every functionality of the ‘queue’ class. The state-
based testing is simple, effective and systematically generates a good number of test cases.

9.8 Mutation Testing

Mutation testing is a useful testing technique to determine the effectiveness of an existing test
suite of any program. Generally, it is applicable at the unit level, but we can also apply it at
the system level without any difficulty. Why do we need such a technique? Why do we want
to understand the adequacy of our test cases? As we all know, there may be a large number of
test cases for any program. We normally do not execute large-size test suite completely due to
398  Object-Oriented Software Engineering

time and resource constraints. We attempt to reduce the size on the basis of some techniques.
However, if we execute all test cases and do not find any fault in the program, there are the
following possibilities:
(i) Test suite is effective, but there are no faults in the program.
(ii) Test suite is not effective, although there are faults in the program.
In both possibilities, we could not make our program fail, although reasons of non-failure of the
program are different. In the first case, the quality of the program is good and there are no faults
in the program. However, in the second case, there are faults in the program but test cases are
not able to find them. Hence, mutation testing helps us to know the effectiveness of an existing
test suite with reasonable level of accuracy.

9.8.1 Mutation Testing and Mutants

We prepare many copies of the program and make a change in every copy. The process of
making change in the program by one or more changes is called mutation and the changed
program is called a mutant. Each mutant is different than the original program by one or more
changes. This change should not make the program grammatically incorrect. The mutant must
be compiled and executed in the same way as the original program. A change should be a
logical change in the program. We may change an arithmetic operator (+, –, *, \) or may change
a Boolean relation with another one (replace > with >= or == with <=). There are many ways
to make a change in the program till it is syntactically correct. Each mutant will have a unique
change, which will make it different from other mutants. Consider a program to find the smallest
amongst three numbers as given in Figure 9.14. The two mutants of the same program are also
given in Figures 9.15 and 9.16.

#include<iostream.h>
#include<conio.h>
1 class smallest
2 {
3 private:
4 int a,b,c;
5 public:
6 void getdata()
7 {
8 cout<<"Enter first number: ";
9 cin>>a;
10 cout<<"\nEnter second number: ";
11 cin>>b;
12 cout<<"\nEnter third number: ";
13 cin>>c;
14 }

Figure 9.14 (Contd.)

 Software Testing  399

15 void compute();
16 };
17 void smallest::compute()
18 {
19 if(a<b)
20 {
21 if(a<c)
22 {
23 cout<<"\nThe smallest number is:"<<a;
24 }
25 Else
26 {
27 cout<<"\nThe smallest number is:"<<c;
28 }
29 }
30 Else
31 {
32 if(c<b)
33 {
34 cout<<"\nThe smallest number is:"<<c;
35 }
36 Else
37 {
38 cout<<"\nThe smallest number is:"<<b;
39 }
40 }
41 }
42 void main()
43 {
44 clrscr();
45 smallest s;
46 s.getdata();
47 s.compute();
48 getch();
49 }

Figure 9.14 Program to find the smallest amongst three numbers.

The mutant M1 is created by replacing the operator ‘<’ of line number 19 by the operator ‘=’. The
mutant M2 is created by replacing the operator ‘<’ of line number 32 by the operator ‘>’. These
400  Object-Oriented Software Engineering

changes are simple and both mutants are different than the original program. Both mutants are
also different than each other but are syntactically correct. The mutants are known as first-order
mutants. We may also get second-order mutants by making two changes in the program and
third-order mutants by making three changes and so on. The second-order and above mutants
are called higher-order mutants. However, in practice, we generally use only the first-order
mutants in order to simplify the process of mutation. The second-order mutants can be created
by making two changes in the program as shown in Figure 9.17.

19 if(a<b)  if(a=b) //mutated statement where ‘<’ is replaced by ‘=’

Figure 9.15 Mutant (M1) of program to find the smallest amongst three numbers.

32 if(c<b)  if(c>b) //mutated statement where operator ‘<’ is

replaced by operator ‘>’
Figure 9.16 Mutant (M 2) of program to find the smallest amongst three numbers.

19 if(a<b)  if(a>b) //mutated statement where ‘<’ is replaced

by ‘>’
32 if(c<b)  if(c=b) //mutated statement where operator ‘<’ is
replaced by operator ‘=’
Figure 9.17 Second-order mutant of program to find the
smallest amongst three numbers.

9.8.2 Mutation Operators

We use mutation operators to create mutants. Operators are used to change a grammatical
expression to another expression without making the changed expression incorrect as per syntax
of the implementation language. There are many ways to apply mutation operators and a large
number of mutants may be created. If an expression ‘a+6’ is changed to ‘a+10’, it is considered
as a lesser change as compared to an expression ‘b*6’, where both operator and operands are
changed. The first order mutants are more popular in practice as compared to the higher-order
mutants because they are easy to understand, implement, manage and control. Some of the
examples of mutation operators are given as follows:
(i) access modifier change like private to public
(ii) static modifier change
(iii) Change of arithmetic operator with another one like ‘\’ with ‘*’ or ‘!+’ with ‘–’
(iv) Change of Boolean relation with another one like ‘<’ with ‘>’ or ‘=’ with ‘==’
(v) Delete a statement
(vi) Change of argument order
(vii) Change of any operand by a numeric value
(viii) Type case operator insertion
(ix) Type case operator deletion
(x) Change of super keyword
 Software Testing  401

9.8.3 Mutation Score

We execute mutants with existing test suite and observe the behaviour. If the existing test suite
is able to make a mutant fail (any observed output is different than the actual output), the mutant
is treated as a killed mutant. If the test suite is not able to kill the mutant, the mutant is treated
as equivalent to the original program and such mutants are called equivalent mutants. Equivalent
mutants are also called live mutants. The mutation score of the test suite is calculated as:
Number of mutants killed
Mutation score =
Total number of mutants

The total number of mutants is equal to the number of killed mutants plus the number of live
mutants. A mutation score range is from 0 to 1. The higher value of a mutation score shows the
effectiveness of the test suite. If the mutation score is 0, it indicates that the test suite is not able
to detect any introduced fault in mutants and is useless for the program. The live mutants are
important and should be studied thoroughly. Special test cases should be designed to kill live
mutants. The new test cases which are able to kill live mutants should be added to the original
test suite to enhance its capability. The mutation testing not only assesses the capability of the
test suite but also enhances the capability by adding new test cases. Some of the popular tools
are insure++, Jester for Java, nester for C++, MuJava tool, Mothra, etc.
We consider the program given in Figure 9.14 to find the smallest of three numbers.
Table 9.36 shows the test suite available to test the program.

Table 9.36 Test suite to test the program given in Figure 9.14
S. No. A B C Expected output
1 3 1 5 1
2 6 2 8 2
3 4 5 7 4
4 8 6 3 3
5 9 10 6 6

Six mutants are created as per details given in Table 9.37.

Table 9.37 Mutants generated

Mutant No. Line No. Original line Modified line
M1 19 if(a<b) if(a=b)
M2 32 if(c<b) if(c>b)
M3 21 if(a<c) if(a!=c)
M4 32 if(c<b) if(c=b)
M5 19 if(a<b) if(a>b)
M6 32 if(c<b) if(c<(a+b))
402  Object-Oriented Software Engineering

The actual output of all mutants with existing test suite is given in Table 9.38.

Table 9.38 Actual output of all mutants

S. No. A B C Expected Actual Actual Actual Actual Actual Actual
output output of output of output of output of output of output of
M1 M2 M3 M4 M5 M6
1 3 1 5 1 1 5 1 1 3 1
2 6 2 8 2 2 8 2 2 6 2
3 4 5 7 4 5 4 4 4 5 4
4 8 6 3 3 3 6 3 6 3 3
5 9 10 6 6 6 6 9 6 6 6

The existing test suite kills five mutants (M1 to M5), but fails to kill mutant M6. Hence, a
mutation score is calculated as given below:
Number of mutants killed
Mutation score =
Total number of mutants
5
=
6
= 0.83

Effectiveness of a test suite is directly related to the mutation score. Mutant M6 is live here and
an additional test case is to be written to kill this mutant. The additional test case is created to
kill this mutant M6 and is given in Table 9.39.

Table 9.39 Additional test case to kill mutant M6

S. No. A B C Expected output
6 6 4 5 4

When we execute this test case, we get the observed behaviour of the program given in Table 9.40.

Table 9.40 Observed behaviour of the program

S. No. A B C Expected output Actual output
6 6 4 5 4 5

This additional test case is very important and must be added to the given test suite. Therefore,
the revised test suite is given as in Table 9.41.
 Software Testing  403
Table 9.41 Revised test suite
S. No. A B C Expected output
1 3 1 5 1
2 6 2 8 2
3 4 5 7 4
4 8 6 3 3
5 9 10 6 6
6 6 4 5 4

9.9 Levels of Testing

There are four levels in testing, namely, unit testing, integration testing, system testing and
acceptance testing. Software testers are responsible for the first three levels of testing and
customers are responsible for the last level (acceptance testing) of testing. Testing at each level is
important and has unique advantages and challenges. At the unit level, individual units are tested
using functional and/or structural testing technique. At the integration level, two or more units
are combined to test the issues related to integration of units. At the system level, the complete
system is tested using primarily functional testing techniques. Non-functional requirements such
as reliability, testability, performance, etc. can be tested at this level only. At the acceptance
level, customers test the system as per their expectations. Their testing strategy may range from
ad hoc testing to well-planned systematic testing.

9.9.1 Unit Testing

There are two ways to define a unit in object-oriented testing. We may consider either each class
as a unit or each operation of the class as a unit for the purpose of unit testing. How can we test a
class at the unit testing level which has a parent class? The operations and attributes of the parent
class will not be available which will prohibit class testing. The solution is to merge the parent
class and the class under test which will make all operations and attributes available for testing.
This type of merging is called flattening of classes. We may test such classes after flattening.
After completion of testing, we should redo flattening because the final product should not have
flattened classes. The issues of inheritance are to be handled carefully. If we decide to select a
method as a unit, these issues will be more challenging and difficult to implement. Hence, in
practice, classes are generally used as a unit at the level of unit testing.
We create instance of class (object) and pass the desired parameters to the constructor.
We may also call each operation of the object with appropriate parameters and note the actual
outputs. The encapsulation is important because attributes and operations are combined in a
class. We focus on the encapsulated class; however, operations within the classes are the
smallest available units for testing. Operations as a unit are difficult to test due to inheritance
and polymorphism. In unit testing, generally, classes are treated as unit, and functional and
structural testing techniques are equally applicable. Verification techniques such as peer reviews,
404  Object-Oriented Software Engineering

inspections and walkthroughs are easily applicable and may find a good number of faults. State-
based testing, path testing, class testing, boundary value analysis, equivalence class and decision
table-based testing techniques are also applicable.

9.9.2 Integration Testing

The objective of integration testing is to test the various combinations of different units and to
check that they are working together properly. We do not have hierarchical control structure in
object-oriented systems. Hence, conventional integration testing techniques such as top down,
bottom up and sandwitch integration may not be applicable in their true sense. The meaning
of integration testing is basically interclass testing. There are three ways to carry out interclass
testing. The most popular interclass testing is thread-based testing. In the thread-based testing,
we integrate classes that are required to respond to an input given to the system. When the input
is given to the software, one or more classes are needed for execution, and such classes make a
thread. There may be many such threads depending on the inputs. The expected output of every
thread is calculated and is compared with the actual output. This technique is simple and easy
to implement.
The second technique is the use case-based testing. We test every basic and alternative paths
of a use case. A path may require one or more classes for execution. Every use case scenario
(path) is tested and due to involvement of many classes, interclass issues are automatically tested.
The third technique is the cluster testing where classes are combined to show one collaboration.
In all approaches, classes are combined on the basic of logic and then executed to know the
outcome. The most popular and simple technique is the thread-based testing.

9.9.3 System Testing

The system testing is performed after the unit testing and integration testing. The complete
software within its expected environment is tested. We define a system as a combination of
software, hardware and other associated parts which work together to provide the desired
functionality. All functional testing techniques are effectively applicable. Structural testing
techniques may also be used technically but they are not very common due to the large size
of the software. Verification techniques are normally used for reviewing the source code and
documents. We test the functional requirements of the software under stated conditions. This is
the only level where non-functional requirements such as stress, load, reliability, usability and
performance are tested. A good number of testing tools are available to test the functional and
non-functional requirements.
We may like to ensure a reasonable level of correctness of the software before delivering it
to the customer. Whenever the source code is modified to remove an error, an impact analysis
of this modification is performed. If any error is not possible to remove due to lack of time
or is technically not possible in the present design, the best way is to document the error as a
limitation of the system. We would like to test every stated functionality of the software, keeping
in mind, the customer’s expectations. After completion of the system testing, the software is
ready for customers.
 Software Testing  405

9.9.4 Acceptance Testing

The acceptance testing is carried out by the customer(s) or their authorized persons for the purpose
of accepting the software. The place of testing may be the developer’s site or the customer’s site
depending on the mutual agreement. In practice, generally, it is carried out at the customer’s
site. Customers may like to test the software as per their expectations. They may do it in an
ad hoc way or in a well-planned systematic way in order to establish the confidence about the
correctness of the software.
When a software product is developed for anonymous customers (in case of operating
systems, compilers, CASE tools, etc.), potential customers are identified to use the software as
per their expectations. If they use the software at the developer’s site under the supervision of
the developers, it is known as alpha testing. Another approach is to distribute the software to
potential customers and ask them to use at their site in a free and independent environment and
this is known as beta testing. The purpose of the acceptance testing is to test the software with
an intention to accept it after getting reasonable confidence about its usage and correctness.

9.10 Software Testing Tools

Software testing tools are available for various applications. They help us to design and execute
test cases, analyse the program complexity, identify the non-coverage area of the source code
and ascertain the performance of the software. There are numerous similar applications during
testing which may be improved using a testing tool. The whole process of testing a software may
be automated and carried out without human involvement. Software tools are also very effective
for repeated testing where similar data set is to be given again and again. Many non-functional
requirements such as performance under load, efficiency, reliability and extreme stress conditions
are also tested using software testing tools. Broadly, these tools may be partitioned into three
categories—static, dynamic and process management. Most of the tools may fall into any one of
the categories and have specified scope with predefined applications.

9.10.1 Static Testing Tools

Static testing tools analyse the program without executing it. They may calculate program
complexity and also identify those portions of the program which are hard to test and maintain.
These tools may find a good number of faults prior to the execution of the program. The identified
faults may range from logical faults to syntax faults and may include non-declaration of a variable,
double declaration of a variable, divide by zero issue, unspecified inputs, etc. Some tools may
also examine the implementation of good programming guidelines and practices and highlight
the violations, if any, to improve the quality of the program. Many tools which calculate the
metrics are static analysis tools. Some of the popular tools are CMTJava (Complexity Measures
Tool for Java), Jenssoft’s Code Companion, Sun Microsystems’ JavaPureCheck, ParaSoft’s
Jtest, Rational Purify, CMT++ (Complexity Measures Tool for C++), ParaSoft CodeWizard,
ObjectSoftware’s ObjectDetail, Software Research’s STATIC (Syntac and Semantic Analysis
Tool), Eastern System’s TestBed, McCabe QA, etc.
406  Object-Oriented Software Engineering

9.10.2 Dynamic Testing Tools

Dynamic testing tools execute the programs for specified inputs. The observed output is
compared with the expected output and if they are different, the program is considered in a
failure condition. These tools also analyse the programs and the reasons of such failure may also
be found. Dynamic testing tools are also very effective to test the non-functional requirements
such as performance, reliability, efficiency and portability.

Performance Testing Tools

These tools are used to test the performance of the software under stress and load. The
performance testing is also called stress and load testing. Popular tools are Mercury Interactive’s
Load Runner, Apache JMeter, Rational’s Performance Tester, Compuware’s QALOAD, Auto
Tester’s Autocontroller, Quest Software’s Benchmark Factory, Sun Microsystems’ Java Load,
Minq Software’s PureLoad, Rational Software’s Test Studio, etc. These tools generate heavy
load on the system to test under extreme conditions.

Functional/Regression Testing Tools

These tools are used to test the functionality of the software. They may generate test cases
and execute them without human involvement. In regression testing, the software is retested
after modifications. Most of the tools are common for both groups. Some of the popular tools
are Junit, Test Manager, Rational’s Robot, Mercury Interactive’s Win Runner, Compuware’s QA
Centre, Segue Software’s Silktest, AutoTester for Windows, Qronus Interactive’s TestRunner,
Automated QA’s AQtest, Rational’s Visual Test, etc.

Coverage Analysis Tools

These tools are used to provide an idea about the level of coverage of the program. They also
indicate the effectiveness of the test cases. They may also highlight the untested portion of
the program which may help us to design special test cases for the coverage of that portion of
the program. Some popular source code coverage analysis tools are Rational’s Pure Coverage,
Quality Checked Software’s Cantata++, CentreLine Software’s QC/coverage, Vision Soft’s
Vision Soft, Plum Hall’s SQS, etc.
Some popular test coverage analysis tools are Software Research’s TCAT for Java, IBM’s
Visual Test Coverage, Bulseye Testing Technology’s C-Cover, Testwell’s CTC++, Testing
Foundation’s GCT, Parasoft’s TCA, Software Research’s TCAT C/C++, and McCabe’s Visual
Testing Tool Set.

9.10.3 Process Management Tools

The focus of process management tools is to improve the testing processes. They may help us to
allocate resources, prepare test plan and keep track of the status of testing. Some of the popular
tools are IBM Rational Test Manager, Mercury Interactive’s Test Director, Segue Software’s
Silk Plan Pro, Compuware’s QA Director, etc. Some configuration management tools are IBM
Rational Software clear DDTs Bugzilla, Samba’s Jitterbug. A few test management tools are
 Software Testing  407
Vector Software’s Vector CAST, Auto Tester’s Auto Advisor, Silver Mark’s Test Mentor, Test
Master’s TMS and TOOTSIE.
A software reliability measurement tool is used to estimate the reliability of the software.
It may also calculate the time needed to achieve an objective failure intensity. A popular tool is
SoftRel’s WhenToStop. Software testing tools not only reduce the testing effort but also make
testing a pleasant discipline. Moreover, some non-functional requirements (such as performance
and efficiency) cannot be tested without using a software testing tool.

Review Questions
1. What is software testing? Discuss issues, limitations, practices and future of software
testing.
2. “Testing is not related to only one phase of software development life cycle”. Comment
on the correctness of this statement.
3. Differentiate between verification and validation. Which one is more important and
why?
4. Which is the most popular verification technique? Explain with suitable examples.
5. Write short notes on the following verification techniques:
(a) Peer reviews
(b) Walkthroughs
(c) Inspections
6. Design an SRS document verification checklist. Highlight some important issues which
such a checklist must address.
7. What is a checklist? Discuss its significance and role in software testing.
8. Differentiate between walkthroughs and inspections. List the advantages and disadvantages
of both techniques.
9. Design checklists for OOA document and OOD document. Both checklists should cover
important issues of both documents.
10. Establish the relationship between verification, validation and testing along with suitable
examples.
11. What is functional testing? Discuss any one technique with the help of an example.
12. What is boundary value analysis? What are its extensions? List the advantages and
limitations of each extension.
13. Consider a program that determines the previous date and the next date. Its inputs are a
triple of day, month and year with its values in the following range:
1  month  12
1  day  31
1947  year  2011
The possible outputs are “next date”, “previous date” or “invalid input”. Design boundary
value analysis test cases, robust test cases, worst test cases and robust worst test cases.
408  Object-Oriented Software Engineering

14. Consider a program that calculates median of three numbers. Its input is a triple of
positive integers (say a, b and c) and values are from the interval [1, 1000]. Generate
boundary value and robust test cases.
15. Describe the equivalence class testing technique. How is it different from boundary
value analysis?
16. What is decision table-based testing? What is the role of a rule count? Discuss the
concept with an example.
17. Consider a program to sort a list in ascending order. Write test cases using equivalence
class testing and decision table-based testing.
18. What are the limitations of boundary value analysis? Highlight the situations in which
it is not effective.
19. Consider a program that counts the number of digits in a number. The range of input is
given as [1, 1000]. Design the boundary value analysis and equivalence class test cases.
20. What is structural testing? How is it different from functional testing?
21. What is path testing? How can we make it more effective and useful?
22. Show that a very high level of statement coverage does not guarantee a defect-free
program. Give an example to explain the concept.
23. What is mutation testing? What is the significance of mutation score? Why are higher-
order mutants not preferred?
24. Why is mutation testing becoming popular? List some significant advantages and
limitations.
25. What is a program graph? How can it be used in path testing?
26. Define the following:
(a) Program graph
(b) DD path graph
(c) Mapping table
(d) Independent paths
27. What is class testing? Why should unspecified behaviour not be implemented?
28. What is state-based testing? What are alpha and omega states? List the advantages and
limitations of the state-based testing.
29. What are levels of testing? Which level is most popular and why?
30. Explain the concept of flattening of classes. How can it help in unit testing?
31. Discuss the importance of software testing tools. List some static, dynamic and process
management tools.
32. Differentiate between static and dynamic testing tools. Which one is more effective and
why?
33. “Some non-functional requirements cannot be tested without using a software testing
tools”. Comment on this statement and justify with an example.
 Software Testing  409
34. Differentiate between black box testing and white box testing. Consider a program to
find the smallest number amongst three numbers. Generate test cases using one of the
testing techniques.
35. Write short notes on:
(a) Software testing tools
(b) State-based testing
(c) Class testing

Multiple Choice Questions

Note: Select the most appropriate answer of the following questions:
1. What is the purpose of testing?
(a) To show the correctness of a program
(b) To calculate the reliability of a program
(c) To find faults in a program
(d) To know the limitations of a program
2. Software testing primarily focuses on:
(a) Verification activities only
(b) Validation activities only
(c) Verification and validation activities
(d) None of the above
3. All validation activities are related to:
(a) Static testing (b) Dynamic testing
(c) Reviewing (d) Inspecting
4. All verification activities are related to:
(a) Static testing (b) Dynamic testing
(c) Functional testing (d) Structural testing
5. Which is not a verification activity?
(a) Peer review (b) Walkthrough
(c) Inspection (d) Path testing
6. Which is not a term for inspection?
(a) Peer review (b) Review
(c) Technical review (d) Formal technical review
7. Who is the presenter of documents in walkthroughs?
(a) Customer (b) User
(c) Author (d) Developer
8. Who is the presenter of documents in inspections?
(a) Customer (b) Developer
(c) Third party moderator (d) Author
410  Object-Oriented Software Engineering

9. Which verification technique accommodates maximum participants?

(a) Peer review (b) Walkthrough
(c) Inspection (d) None of the above
10. Identify the IEEE standard for SRS:
(a) IEEE std. 830-1998 (b) IEEE std. 829-1998
(c) IEEE std. 831-1998 (d) IEEE std. 1016-1998
11. Another name for peer review is:
(a) Inspection (b) Review
(c) Informal review (d) Walkthrough
12. Static testing may not be able to identify:
(a) Memory leaks (b) Non-declaration of a variable
(c) Wrong declaration of a variable (d) All of the above
13. Which are the defects easily identified in static testing than in dynamic testing?
(a) Requirements defects (b) Design defects
(c) Deviations from standards (d) All of the above
14. Functional testing is related to:
(a) Regression testing (b) Behaviour testing
(c) White box testing (d) Mutation testing
15. Boundary value analysis generates x test cases for n variables. The value of x is:
(a) 8n + 1 (b) 6n + 1
(c) 4n + 1 (d) 2n + 1
16. Which of the following is not related to black box testing?
(a) Boundary value analysis
(b) Decision table-based testing
(c) Equivalence class testing
(d) Slice-based testing
17. For a function of n variables, robust testing generates:
(a) 6n + 1 test cases (b) 8n + 1 test cases
(c) 9n + 1 test cases (d) 5n + 1 test cases
18. Functionality of a program is tested by:
(a) Black box testing (b) White box testing
(c) Regression testing (d) All of the above
19. The range of input x is between 100 and 200. Identify the values of x for invalid
equivalence classes:
(a) 99, 201 (b) 100, 200
(c) 99, 200 (d) 100, 201
20. How many minimum test cases are selected from an equivalence class?
(a) 1 (b) 2
(c) 3 (d) 4
 Software Testing  411
21. A column of a decision table generates:
(a) 1 test case (b) 2 test cases
(c) 3 test cases (d) None of the above
22. Binary condition decision table is called:
(a) Extended entry decision table
(b) Complex entry decision table
(c) Critical entry decision table
(d) Limited entry decision table
23. For boundary value analysis, inputs should be:
(a) Independent (b) Dependent
(c) Boolean (d) All of the above
24. Which is not related to structural testing?
(a) Data flow testing (b) Path testing
(c) Mutation testing (d) Equivalence class testing
25. Mutation testing is based on:
(a) Fault rejection (b) Fault seeding
(c) Fault propagatin (d) Fault analysis
26. Mutation score is not related to:
(a) Effectiveness of a test suite (b) Performance of a test suite
(c) Size of a test suite (d) Usefulness of a test suite
27. Which mutants are more popular in practice?
(a) First-order mutants (b) Second-order mutants
(c) Third-order mutants (d) Fourth-order mutants
28. White box testing technique may help to:
(a) Understand the program
(b) Generate test cases
(c) Look into internal structure of the source code
(d) All of the above
29. Which is not a specified level of testing?
(a) Unit testing (b) Integration testing
(c) System testing (d) Statement testing
30. Which is not an integration testing technique?
(a) Thread-based testing (b) Use case-based testing
(c) Cluster testing (d) Slice-based testing
31. Which is not a static testing tool?
(a) CMT Java (b) Rational purify
(c) Compuware’s QALOAD (d) McCabe QA
32. Which is not a dynamic testing tool?
(a) Apache JMeter (b) Mercury Interactive’s Load Runner
(c) Compuware’s QALOAD (d) CMT Java
412  Object-Oriented Software Engineering

33. Which is not a process management tool?

(a) Mercury Interactive’s Test Director (b) Compuware’s QA Director
(c) Auto Tester’s Auto Advisor (d) Rational’s Robot
34. Identify the functional testing tool:
(a) Rational’s Robot (b) Test Master’s TMS
(c) Apache JMeter (d) Mercury Interactive’s Load Runner
35. Which is not a functional testing tool?
(a) Rational’s Robot (b) Mercury Interactive’s Win Runner
(c) Seque Software’s Silktest (d) Samba’s Jitterbug

Further Reading
Fagan shows that by using inspection, the cost of errors may be reduced significantly in initial
phases of software development:
Fagan, M.E., Design and code inspections to reduce errors in program development. IBM Systems
Journal, 15(3): 182–211, 1976.
Strauss et al. provide a comprehensive guide to software inspections method that may reduce
program defects in the early phases of software design and development:
Strauss, S.H., Susan, H., and Ebenau, Robert G., Software Inspection Process. New York:
McGraw-Hill, 1994.
Yourdon’s book may provide a useful guidance to practitioners and programmers on group
walkthroughs:
Yourdon, E., Structured Walkthroughs. Englewood Cliffs, NJ: Prentice-Hall, 1989.
The below book is resource for pre-1981 literature and contains a huge bibliography up to and
including 1981:
Miller, E.F. and Howden, W.E., Tutorial: Software Testing and Validation Techniques.
New York: IEEE Computer Society, 1981.
A hands-on guide to the black box testing technique:
Beizer, B., Black-Box Testing: Techniques for Functional Testing of Software and Systems.
New York: John Wiley & Sons, 1995.
An introductory book on software testing with a special focus on functions testing is:
Jorgensen, P.C., Software Testing: A Craftsman Approach, 3rd ed. New York: Auerbach
Publications, 2007.
A useful guide for designing test cases for object-oriented applications. This book provides
comprehensive and detailed coverage of techniques to develop testable models from unified
modelling language and state machines:
Binder, R.V., Testing Object Oriented Systems: Models, Patterns and Tools. Reading,
MA: Addison-Wesley, 1999.
 Software Testing  413
Binder has significantly contributed in the area on object-oriented testing:
Binder, R., State-based testing. Object Magazine. 5(4): 75–78, July–Aug, 1995.
Binder, R., State-based testing: sneak paths and conditional transitions. Object Magazine, 5(6),
87–89, Nov–Dec, 1995.
Binder, R., Testing Object-Oriented Systems: A Status Report, Released online by RBSC
Corporation, 1995. Available at http://stsc.hill.af.mil/crosstalk/1995/April/testinoo.asp
McGregor and Sykes provide good differences of testing traditional and object-oriented software.
They also describe methods for testing of classes:
McGregor, J.D. and Sykes, David A., A Practical Guide to Testing Object Oriented Software.
Canada: Addison–Wesley, 2001.
A complete bibliographical list on object-oriented testing can be obtained from:
http://oo-testing.com/bib/
A study on mutation analysis on object-oriented programs can be found in:
Ma, Y.S. and Kwon, Y.R., A study on method and tool of mutation analysis for object-oriented
programs. Software Engineering Review, 15(2): 41–52, 2002.