Unit III

Test case design

TESTING AS AN ENGINEERING ACTIVITY

1. This is an exciting time to be a software developer.

2. Software systems are becoming more challenging to build.
3. They are playing an increasingly important role in society.
4. People with software development skills are in demand.
5. New methods, techniques, and tools are becoming available to support development and maintenance tasks.
6. Because software now has such an important role in our lives both economically and socially, there is pressure for
software professionals to focus on quality issues.
7. Poor quality software that can cause loss of life or property is no longer acceptable to society.
8. Failures can result in catastrophic losses.
9. Conditions demand software development staffs with interest and training in the areas of software product and
process quality.
10. Highly qualified staff ensure that software products are built on time, within budget, and are of the highest quality
with respect to attributes such as reliability, correctness, usability, and the ability to meet all user requirements.
11. In response to the demand for high-quality software, and the need for well-educated software professionals, there is
a movement to change the way software is developed and maintained, and the way developers and maintainers are
educated. In fact, the profession of software engineering is slowly emerging as a formal engineering discipline.
12. As a new discipline it will be related to other engineering disciplines, and have associated with it a defined body of
knowledge, a code of ethics, and a certification process.

The education and training of engineers in each engineering discipline is based on the teaching of related
scientific principles, engineering processes, standards, methods, tools, measurement and best practices as
shown in Figure

This text is based on the philosophy that software development should be viewed and taught as an
engineering discipline and that quality in both the process and the product are of prime importance to
professionals in this field.
Using an engineering approach to software development implies that:

1. The development process is well understood;

2. Projects are planned;
3. Life c ycle models are defined
4. Standards are in place for product and process;
5. Measurements are employed to evaluate product and process quality;
6. Components are reused
7. Validation and verification processes play a key role in quality determination;
8. engineers have proper education, training, and certification.
 UNIT III Testing fundamentals
Basic definitions

Errors
An error is a mistake, misconception, or misunderstanding on the part of a software
developer.
In the category of developer we include software engineers, programmers,
analysts, and testers.
For example, a developer may misunderstand a design notation, or a programmer
might type a variable name incorrectly.
Faults (Defects)
A fault (defect) is introduced into the software as the result of an error.
It is an anomaly in the software that may cause it to behave incorrectly, and not
according
to its specification. Faults or defects are also called “bugs.”
Failures
A failure is the inability of a software system or component to perform its required
functions within specified performance requirements.
During execution of a software component or system, a tester, developer, or user
observes that it does not produce the expected results.
In some cases a particular type of misbehavior indicates a certain type of fault is
present.
An experienced developer/tester will have a knowledge base of
fault/symptoms/failure cases
stored in memory.
During development failures are usually observed by testers, and faults are located
and repaired by developers.

The input to the software must cause the faulty statement to be executed.
2. The faulty statement must produce a different result than the correct statement.
This event produces an incorrect internal state for the software.
3. The incorrect internal state must propagate to the output, so that the result of
the fault is observable.
Software that easily reveals its’ faults as failures is said to be more testable
Test Cases
A test case in a practical sense is a test-related item which contains the following
information:
1. A set of test inputs: These are data items received from an external source by
the code under test.
The external source can be hardware, software, or human.
2. Execution conditions: These are conditions required for running the test, for
example, a certain state of a database, or a configuration of a hardware device.
3. Expected outputs: These are the specified results to be produced by the code
under test

Test
A test is a group of related test cases, or a group of related test cases and test
procedures (steps needed to carry out a test,)
A group of related tests is sometimes referred to as a test set. A group of related
tests that are associated with a database, and are usually run together, is
sometimes referred to as a Test Suite.
A test oracle is a document, or piece of software that allows testers to determine
whether a test has been passed or failed.
Test Bed
A test bed is an environment that contains all the hardware and software needed to
test a software component or a software system.
Software Quality
1.Quality relates to the degree to which a system, system component, or process
meets specified requirements.
2. Quality relates to the degree to which a system, system component, or process
meets customer or user needs, or expectations.
In order to determine whether a system, system component, or process is of high
quality we use what are called quality attributes. These are characteristics that
reflect quality
Metric:
A metric is a quantitative measure of the degree to which a system, system
component, or process possesses a given attribute . There are product and
process metrics.
A very commonly used example of a software product metric is software size,
usually measured in lines of code (LOC).
Two examples of commonly used process metrics are costs and time required for
a given task

Quality Metric
A quality metric is a quantitative measurement of the degree to which an item possesses
a given quality attribute.

Quality Attributes With Brief Explanations Are The Following:

1. correctness—the degree to which the system performs its intended function
2. reliability—the degree to which the software is expected to perform its
required functions under stated conditions for a stated period of time
3. usability—relates to the degree of effort needed to learn, operate, prepare
input, and interpret output of the software
4. integrity—relates to the system’s ability to withstand both intentional and
accidental attacks
5. portability—relates to the ability of the software to be transferred from one
environment to another
6. maintainability—the effort needed to make changes in the software
7. interoperability—the effort needed to link or couple one system to another.

Testers must work with analysts, designers and, developers throughout the
software life system to ensure that testability issues are addressed .
Software Quality Assurance Group

The software quality assurance (SQA) group is a team of people with the necessary
training and skills to ensure that all necessary actions are taken during the
development process so that the resulting software conforms to established
technical requirements.
The software quality assurance (SQA) group in an organization has ties to quality
issues.

They work with project managers and testers to develop quality-related policies
and quality assurance plans for each project. The group is also involved in
measurement collection and analysis, record keeping, and reporting.
Reviews

A review is a group meeting whose purpose is to evaluate a software artifact or a

set of software artifacts.
The composition of a review group may consist of managers, clients, developers,
testers and other personnel depending on the type of artifact under review.
A special type of review called an audit is usually conducted by a Software Quality
Assurance group

Software Testing Principles

Principle 1. Testing is the process of exercising a software component using a selected set of test cases,
with the intent of (i) revealing defects, and (ii) evaluating quality.
Principle 2. When the test objective is to detect defects, then a good test case is one that has a high
probability of revealing a yet undetected defect(s).
Principle 3. Test results should be inspected meticulously.
Principle 4. A test case must contain the expected output or result.
Principle 5. Test cases should be developed for both valid and invalid input conditions.
Principle 6. The probability of the existence of additional defects in a software component is proportional to the number of
defects already detected in that component.
Principle 7. Testing should be carried out by a group that is independent of the development group.
Principle 8. Tests must be repeatable and reusable.
Principle 9. Testing should be planned
Principle 10. Testing activities should be integrated into the software life cycle.
Principle 11. Testing is a creative and challenging task

Difficulties and challenges for the tester include the following:

1. A tester needs to have comprehensive knowledge of the software engineering discipline.
2. A tester needs to have knowledge from both experience and education as to how software is
specified, designed, and developed.
3. A tester needs to be able to manage many details.
4. A tester needs to have knowledge of fault types and where faults of a certain type might occur in
code constructs.
5. A tester needs to reason like a scientist and propose hypotheses that relate to presence of specific
types of defects.
6. A tester needs to design and record test procedures for running the tests.
7. A tester needs to plan for testing and allocate the proper resources.
8. A tester needs to execute the tests and is responsible for recording results.
9. A tester needs to learn to use tools and keep abreast of the newest test tool advances.
10. A tester needs to work and cooperate with requirements engineers, designers, and
developers, and often must establish a working relationship with clients and users.

Defects
1. A fault (defect) is introduced into the software as the result of an error.
2. It is an anomaly in the software that may cause it to behave incorrectly, and
not according
3. to its specification.
4. Faults or defects are also called “bugs.”
5. Defects have detrimental effects on software users, and software engineers
work very hard to produce high-quality software with a low number of defects.
6. But even under the best of development circumstances errors are made,
resulting in defects being injected in the software during the phases of the
software life cycle.

Education:
The software engineer did not have the proper educational background to prepare
the software design. She did not understand how to do something.
For example, a software engineer who did not understand the precedence order of
operators in a particular programming language could inject a defect in an equation
that uses the operators for a calculation.
Communication: The software engineer was not informed about something by a
colleague.
Oversight: The software engineer omitted to do something
Transcription: The software engineer knows what to do, but makes a mistake in
doing it.
A simple example is a variable name being misspelled when entering the code.
Process: The process used by the software engineer misdirected her actions.

When defects are present due to one or more of these circumstances, the software
may fail, and the impact on the user ranges from a minor to major problem.
Testers as doctors need to have knowledge about possible defects (illnesses) in
order to develop defect
hypotheses. They use the hypotheses to:
a. design test cases;
b. design test procedures;
c. assemble test sets;
d . select the testing levels (unit, integration, etc.) appropriate for the tests;
e.evaluate the results of the tests.
A successful testing experiment will prove the hypothesis is true—that is,
the hypothesized defect was present. Then the software can be repaired (treated).
A very useful concept related to defects, testing, and diagnosis is that of a fault
model.

Fault (defect) model

A fault (defect) model can be described as a link between the error made
(e.g., a missing requirement, a misunderstood design element, a typographical error), and
the fault/defect in the software.

Physical defects in the digital world may be due to manufacturing errors,

component wear-out, and/or environmental effects.
The fault models are often used to generate a fault list or dictionary.
From that dictionary faults can be selected, and test inputs developed for digital
components.

Although software engineers are not concerned with physical defects, and the
relationships between software failures, software defects, fault model concept and
fault lists accumulated in memory from years of experience to design tests and for
diagnosis tasks during fault localization (debugging) activities.

Example of a fault model is : a software engineer might have in memory is “an

incorrect value for a variable was observed because the precedence order for the
arithmetic operators used to calculate its value was incorrect. ” This could be called
“an incorrect operator precedence order” fault.

Defect Classes, the Defect Repository, and Test Design

Functional Description Defects

The overall description of what the product does, and how it should behave (inputs/outputs), is incorrect,
ambiguous, and/or incomplete.
2 . Feature Defects
Features may be described as distinguishing characteristics of a software component or system.
3 . Feature Interaction Defects
These are due to an incorrect description of how the features should interact.
4 . Interface Description Defects
These are defects that occur in the description of how the target software is to interface with external
software, hardware, and users.
 DesignDefects
Design defects occur when system components, interactions between system components, interactions
between the components and outside software/hardware, or users are incorrectly designed.
This covers defects in the design of algorithms, control, logic, data elements, module interface
descriptions, and external software/hardware/user interface descriptions .
1 . Algorithmic and Processing Defects
These occur when the processing steps in the algorithm as described by the pseudo code are incorrect
2 . Control, Logic, and Sequence Defects
Control defects occur when logic flow in the pseudo code is not correct.
3 . Data Defects
These are associated with incorrect design of data structures
4 . Module Interface Description Defects
These are defects derived from, for example, using incorrect, and/or inconsistent parameter types
5.Functional Description Defects
The defects in this category include incorrect, missing, and/or unclear design eleme nts.
CodingDefects
Coding defects are derived from errors in implementing the code.
Algorithmic and Processing Defects
Adding levels of programming detail to design, code-related algorithmic and processing defects
would now include unchecked overflow and underflow conditions, comparing inappropriate data
types, converting one data type to another,

Control, Logic and Sequence Defects

On the coding level these would include incorrect expression of case statements, incorrect iteration of
loops.

Typographical Defects
These are principally syntax errors, for example, incorrect spelling of a variable name, that are usually
detected by a compiler.
I n i t i a l i z a t i o n Defects
These occur when initialization statements are omitted or are incorrect.
External Hardware, Software Interfaces Defects
These defects arise from problems related to system calls, links to databases, input/output sequences,
memory usage, resource usage, interrupts and exception handling, data exchanges with hardware,
protocols, formats.
TestingDefects
Test plans, test cases, test harnesses, and test procedures can also contain defects. Defects in test
plans are best detected using review techniques.