SOFTWARE TESTING

Subject Code:17IS63

MODULE 1

Basics of Software Testing: Basic definitions, Software Quality , Requirements, Behaviour

and Correctness, Correctness versus Reliability, Testing and Debugging, Test cases, Insights
from a Venn diagram, Identifying test cases, Test-generation Strategies, Test Metrics, Error
and fault taxonomies , Levels of testing, Testing and Verification, Static Testing. Problem
Statements: Generalized pseudocode, the triangle problem, the NextDate function, the
commission problem, the SATM (Simple Automatic Teller Machine) problem, the currency
converter, Saturn windshield wiper

Basic definitions

What is Software Testing?

Software testing is defined as an activity to check whether the actual results match the
expected results and to ensure that the software system is Defect free. It involves execution of
a software component or system component to evaluate one or more properties of interest.

Software testing also helps to identify errors, gaps or missing requirements in contrary to the
actual requirements. It can be either done manually or using automated tools. Some prefer
saying Software testing as a White Box and Black Box Testing.

In simple terms, Software Testing means Verification of Application Under Test (AUT).

Why is Software Testing Important?

Testing is important because software bugs could be expensive or even dangerous. Software
bugs can potentially cause monetary and human loss, and history is full of such examples.

In April 2015, Bloomberg terminal in London crashed due to software glitch affected more
than 300,000 traders on financial markets. It forced the government to postpone a 3bn pound
debt sale.

Nissan cars have to recall over 1 million cars from the market due to software failure in the
airbag sensory detectors. There has been reported two accident due to this software failure.

Starbucks was forced to close about 60 percent of stores in the U.S and Canada due to
software failure in its POS system. At one point store served coffee for free as they unable to
process the transaction.

Some of the Amazon‘s third party retailers saw their product price is reduced to 1p due to a
software glitch. They were left with heavy losses.

Vulnerability in Window 10. This bug enables users to escape from security sandboxes
through a flaw in the win32k system.

1
In 2015 fighter plane F-35 fell victim to a software bug, making it unable to detect targets
correctly.

China Airlines Airbus A300 crashed due to a software bug on April 26, 1994, killing 264
innocent live

In 1985, Canada's Therac-25 radiation therapy machine malfunctioned due to software bug
and delivered lethal radiation doses to patients, leaving 3 people dead and critically injuring 3
others.

In April of 1999, a software bug caused the failure of a $1.2 billion military satellite launch,
the costliest accident in history

In may of 1996, a software bug caused the bank accounts of 823 customers of a major U.S.
bank to be credited with 920 million US dollars.

Basic Definitions

Error
People make errors. A good synonym is ―mistake‖. When people make mistakes while
coding, we call these mistakes ―bugs‖. Errors tend to propagate; a requirements error may be
magnified during design, and amplified still more during coding.

Fault
A fault is the result of an error. It is more precise to say that a fault is the representation of an
error, where representation is the mode of expression, such as narrative text, dataflow
diagrams, hierarchy charts, source code, and so on. ―Defect‖ is a good synonym for fault; so
is ―bug‖.

Failure
A failure occurs when a fault executes. Two subtleties arise here: one is that failures only
occur in an executable representation, which is usually taken to be source code, or more
precisely, loaded object code.

Incident
When a failure occurs, it may or may not be readily apparent to the user (or customer or
tester). An incident is the symptom(s) associated with a failure that alerts the user to the
occurrence of failure.

Test
Testing is obviously concerned with errors, faults, failures, and incidents. A test is the act
ofexercising software with test cases. There are two distinct goals of a test: either to find
failures, or to demonstrate correct execution.

Test Case
A test case has an identity, and is associated with a programbehaviour. A test case also has a
set of inputs, a list of expected outputs.

2
Software Quality
SOFTWARE QUALITY is the degree of conformance to explicit or implicit requirements
and expectations.
Explanation
 Explicit: clearly defined and documented
 Implicit: not clearly defined and documented but indirectly suggested
 Requirements: business/product/software requirements
 Expectations: mainly end-user expectations

The modern view of a quality associated with a software product several quality methods
such as the following:

Portability: A software device is said to be portable, if it can be freely made to work in

various operating system environments, in multiple machines, with other software products,
etc.

Usability: A software product has better usability if various categories of users can easily
invoke the functions of the product.

Reusability: A software product has excellent reusability if different modules of the product
can quickly be reused to develop new products.

Correctness: A software product is correct if various requirements as specified in the SRS

document have been correctly implemented.

Maintainability: A software product is maintainable if bugs can be easily corrected as and

when they show up, new tasks can be easily added to the product, and the functionalities of
the product can be easily modified, etc.

Requirements

What is Software Requirement?

It's a primary requirement needed in the development of a software product. These

requirements works as a base and is being used in developing a particular software product to
perform specifically for a targeted group or audience and for the specific environment.

These requirements are of very much importance as any sort of compromise to them may
produce undesirable final product and may fail to meet the needs & expectations of a client or
a user. Therefore, there exists a separate phase in a SDLC to gather, study and analyse the
software requirements so as to avoid such type of circumstances.

Types of Requirements In Software Testing

Business Requirements:

These requirements are specified from the business point of view. It generally involves the
specified objectives and goals of a particular project that needs to be fulfilled. It provides an

3
abstract of a project. These requirements are not meant for specifying the functionalities or
technicalities of a desired software product rather it outlines a general overview of a product,
such as its primary use, why it is needed, its scope & vision, what business benefits will be
gain, intended audience or users, etc. It generally involves the participation of the client,
stakeholders, business and project managers for gathering and analyzing the business
requirements.

Through business requirements, it is easy to assess the project cost, time required, business
risks involved and many such things associated with a software development project.

System Requirements:
Requirements to be incorporated in a software product under development to make a software
product perform and function in a specific manner to achieve a specific target and goal falls
under the category of system requirements. These system requirements may be broadly
classified in two types‘ functional requirements and non-functional requirements.

 Functional requirements:
Requirements encompassing the functional attributes and behaviour of a software
product are called functional requirements. These requirements reflect the working
and functionalities of an intended software product.
These requirements defines and describes the functions to be performed, and features
to be possessed by a software product. What and how does a product supposed to
perform on accepting inputs from the user, and what desirable output it should
provide to the users. These requirements should be complete and clearly well-defined
so as to meet all the specified feature and functionalities without misunderstanding or
leaving the requirement so as to achieve a desirable quality product.

 Non-Functional Requirements:
Requirements other than functional requirements which are essential and contribute
towards the performance of a software product under variant type of conditions and
multiple environments are commonly known as Non-functional requirements. These
requirements are used to evaluate and assess the software product behaviour other
than its specific or desired behaviour under unexpected conditions and environment,
contrary to what is favourable for its functioning. It also covers the standards, rules
and regulation that a software product must adhere and conform to it.

User Requirements:
Requirements generated from a user‘s point of view and scenarios of using a software
product in a multiple manner under real environment by a targeted user to execute a
particular task, specifies the user requirements. It defines the user's expectation from a
software product. As user‘s exhaustive needs may not be covered under the domain of system
requirement, it may be covered separately by business analysts through studying and
analysing the user requirements.

These types of requirements are generally gathered and documented using use cases, user
scenarios, and user stories. These requirements are documented in a user requirement
document (URD) format by making use of narrative text and are usually signed off by the
intended users.

4
Behaviour and Correctness
What is Correctness?
Correctness from software engineering perspective can be defined as the adherence to the
specifications that determine how users can interact with the software and how the software
should behave when it is used correctly.
If the software behaves incorrectly, it might take considerable amount of time to achieve the
task or sometimes it is impossible to achieve it.
Important rules:
Below are some of the important rules for effective programming which are consequences of
the program correctness theory.
 Defining the problem completely.
 Develop the algorithm and then the program logic.
 Reuse the proved models as much as possible.
 Prove the correctness of algorithms during the design phase.
 Developers should pay attention to the clarity and simplicity of your program.
 Verifying each part of a program as soon as it is developed.

Correctness versus Reliability

Correctness: The degree to which a system is free from [defects] in its specification, design,
and implementation.

Reliability: The ability of a system to perform its requested functions under stated conditions
whenever required - having a long mean time between failures.

Testing and Debugging

Differences between Testing and Debugging

Testing:
Testing is the process of verifying and validating that a software or application is bug free,
meets the technical requirements as guided by its design and development and meets the user
requirements effectively and efficiently with handling all the exceptional and boundary cases.

Debugging:
Debugging is the process of fixing a bug in the software. It can defined as the identifying,
analysing and removing errors. This activity begins after the software fails to execute
properly and concludes by solving the problem and successfully testing the software. It is

5
considered to be an extremely complex and tedious task because errors need to be resolved at
all stages of debugging.

TESTING DEBUGGING

Debugging is the process to correct

Testing is the process to find bugs and errors. the bugs found during testing.

It is the process to identify the failure of It is the process to give the

implemented code. absolution to code failure.

Testing is the display of errors. Debugging is a deductive process.

Debugging is done by either

Testing is done by the tester. programmer or developer.

There is no need of design knowledge in the Debugging can‘t be done without

testing process. proper design knowledge.

Testing can be done by insider as well as Debugging is done only by insider.

outsider. Outsider can‘t do debugging.

Debugging is always manual.

Testing can be manual or automated. Debugging can‘t be automated.

It is based on different testing levels i.e. unit

testing, integration testing, system testing Debugging is based on different
etc. types of bugs.

Test Case
A TEST CASE is a set of conditions or variables under which a tester will determine whether
a system under test satisfies requirements or works correctly.
The process of developing test cases can also help find problems in the requirements or
design of an application.
Test Case Template
A test case can have the following elements. Note, however, that a test management tool is
normally used by companies and the format is determined by the tool used.
Test Suite ID The ID of the test suite to which this test case belongs.
Test Case ID The ID of the test case.
Test Case Summary The summary / objective of the test case.
Related Requirement The ID of the requirement this test case relates/traces to.
Prerequisites Any prerequisites or preconditions that must be fulfilled prior
to executing the test.
Test Procedure Step-by-step procedure to execute the test.
Test Data The test data, or links to the test data, that are to be used while
conducting the test.
Expected Result The expected result of the test.
Actual Result The actual result of the test; to be filled after executing the test.
Status Pass or Fail. Other statuses can be ‗Not Executed‘ if testing is
not performed and ‗Blocked‘ if testing is blocked.
6
Remarks Any comments on the test case or test execution.
Created By The name of the author of the test case.
Date of Creation The date of creation of the test case.
Executed By The name of the person who executed the test.
Date of Execution The date of execution of the test.
Test Environment The environment (Hardware/Software/Network) in which the
test was executed.

Test Case Example / Test Case Sample

Test Suite ID TS001
Test Case ID TC001
Test Case Summary To verify that clicking the Generate Coin button generates
coins.
Related Requirement RS001
Prerequisites User is authorized.
Coin balance is available.
Test Procedure Select the coin denomination in the Denomination field.
Enter the number of coins in the Quantity field.
Click Generate Coin.
Test Data Denominations: 0.05, 0.10, 0.25, 0.50, 1, 2, 5
Quantities: 0, 1, 5, 10, 20
Expected Result Coin of the specified denomination should be produced if the
specified Quantity is valid (1, 5)
A message ‗Please enter a valid quantity between 1 and 10‘
should be displayed if the specified quantity is invalid.
Actual Result If the specified quantity is valid, the result is as expected.
If the specified quantity is invalid, nothing happens; the
expected message is not displayed
Status Fail
Remarks This is a sample test case.
Created By John Doe
Date of Creation 01/14/2020
Executed By Jane Roe
Date of Execution 02/16/2020
Test Environment OS: Windows Y
Browser: Chrome N

Insights from a Venn diagram

Insights from a Venn Diagram

Testing is fundamentally concerned with behavior, and behavior is orthogonal to the code-
based view common to software (and system) developers

A quick distinction is that: ‒ The code-based view focuses on what it is ‒ The behavioral
view considers what it does

7
Identifying Test Cases
There are two fundamental approaches to identifying test cases; these are known as
functional and structural testing. Each of these approaches has several distinct test case
identification methods, more commonly called testing methods.

8
What is Structural Testing ?
Structural testing, also known as glass box testing or white box testing is an approach where
the tests are derived from the knowledge of the software's structure or internal
implementation.
The other names of structural testing includes clear box testing, open box testing, logic
driven testing or path driven testing.
Structural Testing Techniques:
 Statement Coverage - This technique is aimed at exercising all programming
statements with minimal tests.
 Branch Coverage - This technique is running a series of tests to ensure that all
branches are tested at least once.
 Path Coverage - This technique corresponds to testing all possible paths which
means that each statement and branch are covered.
Advantages of Structural Testing:
 Forces test developer to reason carefully about implementation
 Reveals errors in "hidden" code
 Spots the Dead Code or other issues with respect to best programming practices.
Disadvantages of Structural Box Testing:
 Expensive as one has to spend both time and money to perform white box testing.
 Every possibility that few lines of code is missed accidentally.
 Indepth knowledge about the programming language is necessary to perform white
box testing.
What is Functional Testing?
Functional testing is a quality assurance (QA) process[1] and a type of black-box testing that
bases its test cases on the specifications of the software component under test. Functions are
tested by feeding them input and examining the output, and internal program structure is
rarely considered (unlike white-box testing).

Functional Testing is a testing technique that is used to test the features/functionality of the
system or Software, should cover all the scenarios including failure paths and boundary
cases.
It is basically defined as a type of testing which verifies that each function of the software
application works in conformance with the requirement and specification. This testing is not
concerned about the source code of the application. Each functionality of the software
application is tested by providing appropriate test input, expecting the output and comparing
the actual output with the expected output. This testing focuses on checking of user
interface, APIs, database, security, client or server application and functionality of the
Application Under Test.

9
The other major Functional Testing techniques include:
 Unit Testing
 Integration Testing
 Smoke Testing
 User Acceptance Testing
 Localization Testing
 Interface Testing
 Usability Testing
 System Testing
 Regression Testing
 Globalization Testing

Test-generation Strategies
Test generation Any form of test generation uses a source document. In the most
informal of test methods, the source document resides in the mind of the tester who
generates tests based on a knowledge of the requirements. In several commercial
environments, the process is a bit more formal. The tests are generated using a mix of
formal and informal methods either directly from the requirements document serving as
the source. In more advanced test processes, requirements serve as a source for the
development of formal models.

Test generation strategies Model based: require that a subset of the requirements be
modeled using a formal notation (usually graphical). Models: Finite State Machines,
Timed automata, Petri net, etc. Specification based: require that a subset of the
requirements be modeled using a formal mathematical notation. Examples: B, Z, and
Larch. Code based: generate tests directly from the code.

10
A 'Finite State Machine (FSM)' is a system that will be in different discrete states (like
―ready‖, ―not ready‖, ―open‖, ―closed‖,…) depending on the inputs or stimuli. The
discrete states that the system ends up with, depends on the rules of the transition of the
system.

For example, VM states from user perspective are like:

Statechart diagram is one of the five UML diagrams used to model the dynamic nature of a
system. They define different states of an object during its lifetime and these states are
changed by events. Statechart diagrams are useful to model the reactive systems.

11
Figure 2: Statechart diagram with an around advice on method Push.

Petri nets were designed for and are used mainly for modeling. Many systems, especially
those with independent components, can be modeled by a Petri net. The systems may be of
many different kinds: computer hardware, computer software, physical systems, social
systems, and so on. Petri nets are used to model the occurrence of various events and
activities in a system. In particular, Petri nets may model the flow of information or other
resources within a system.

The Petri net of Figure 3.1 is a Petri net model of the machine shop example given above. We
have labeled each transition and place with the corresponding event or condition.

12
Timed I/O automata

In theoretical computer science, automata theory is the study of abstract machines (or more
appropriately, abstract 'mathematical' machines or systems) and the computational problems
that can be solved using these machines. These abstract machines are called automata. This
automaton consists of
• states (represented in the figure by circles),
• and transitions (represented by arrows). As the automaton sees a symbol of input, it makes a
transition (or jump) to another state, according to its transition function (which takes the
current state and the recent symbol as its inputs). Uses of Automata: compiler design and
parsing.

Test Metrics
Software test metrics is to monitor and control process and product. It helps to drive the
project towards our planned goals without deviation.

Metrics answer different questions. It‘s important to decide what questions you want answers
to.

Software test metrics are classified into two types

1. Process metrics
2. Product metrics

The ideal example to understand metrics would be a weekly mileage of a car compared
to its ideal mileage

Why Test Metrics are Important?

"We cannot improve what we cannot measure" and Test Metrics helps us to do exactly the
same.

 Take decision for next phase of activities

 Evidence of the claim or prediction
 Understand the type of improvement required
 Take decision or process or technology change

13
Types of Test Metrics

 Process Metrics: It can be used to improve the process efficiency of the SDLC (
Software Development Life Cycle)
 Product Metrics: It deals with the quality of the software product
 Project Metrics: It can be used to measure the efficiency of a project team or any
testing tools being used by the team members

Identification of correct testing metrics is very important. Few things need to be considered
before identifying the test metrics

 Fix the target audience for the metric preparation

 Define the goal for metrics
 Introduce all the relevant metrics based on project needs
 Analyze the cost benefits aspect of each metrics and the project lifestyle phase in
which it results in the maximum output

Manual Test Metrics

In Software Engineering, Manual test metrics are classified into two classes

 Base Metrics
 Calculated Metrics

14
Base metrics is the raw data collected by Test Analyst during the test case development and
execution (# of test cases executed, # of test cases).

While calculated metrics are derived from the data collected in base metrics. Calculated
metrics is usually followed by the test manager for test reporting purpose (% Complete, %
Test Coverage).

Depending on the project or business model some of the important metrics are

Test Metrics Life Cycle

Different stages of Steps during each stage
Metrics life cycle

 Analysis  Identification of the Metrics

 Define the identified QA Metrics

 Communicate  Explain the need for metric to stakeholder and testing

team
 Educate the testing team about the data points to need to
be captured for processing the metric

 Evaluation  Capture and verify the data

 Calculating the metrics value using the data captured

 Report  Develop the report with an effective conclusion

 Distribute the report to the stakeholder and respective
representative
 Take feedback from stakeholder

Error and fault taxonomies

Error and Fault Taxonomies Process versus Product

process refers to how we do something, and

product is the end result of a process SQA is more concerned with reducing errors endemic in
the development process, while testing is more concerned with discovering faults in a product.

Faults can be classified in several ways:

• the development phase where the corresponding error occurred,
• the consequences of corresponding failures,

15
• difficulty to resolve,
• risk of no resolution, and so on.

16
17
Levels of testing

What are the levels of testing?

A level of software testing is a process where every unit or component of a software/system

is tested. The main goal of system testing is to evaluate the system's compliance with the
specified needs.

There are many different testing levels which help to check behavior and performance for
software testing. These testing levels are designed to recognize missing areas and
reconciliation between the development lifecycle states. In SDLC models there are
characterized phases such as requirement gathering, analysis, design, coding or execution,
testing, and deployment.

All these phases go through the process of software testing levels. There are mainly four
testing levels are:

1. Unit Testing
2. Integration Testing
3. System Testing
4. Acceptance Testing
5. Each of these testing levels has a specific purpose. These testing level provide value
to the software development lifecycle.

1) Unit testing:

A Unit is a smallest testable portion of system or application which can be compiled,

liked, loaded, and executed. This kind of testing helps to test each module separately.

18
 The aim is to test each part of the software by separating it. It checks that component
are fulfilling functionalities or not. This kind of testing is performed by developers.

2) Integration testing:

Integration means combining. For Example, In this testing phase, different software modules
are combined and tested as a group to make sure that integrated system is ready for system
testing.

Integrating testing checks the data flow from one module to other modules. This kind of
testing is performed by testers.

3) System testing:

System testing is performed on a complete, integrated system. It allows checking system's

compliance as per the requirements. It tests the overall interaction of components. It involves
load, performance, reliability and security testing.

System testing most often the final test to verify that the system meets the specification. It
evaluates both functional and non-functional need for the testing.

4) Acceptance testing:

Acceptance testing is a test conducted to find if the requirements of a specification or contract

are met as per its delivery. Acceptance testing is basically done by the user or customer.
However, other stockholders can be involved in this process.

Conclusion:

 A level of software testing is a process where every unit or component of a

software/system is tested.
 The primary goal of system testing is to evaluate the system's compliance with the
specified needs.
 In Software Engineering, four main levels of testing are Unit Testing, Integration
Testing, System Testing and Acceptance Testing.

A diagrammatic variation of the waterfall model, known as the V-Model in ISTQB parlance,
is given in Figure 1.8; this variation emphasizes the correspondence between testing and
design levels.

A practical relationship exists between levels of testing versus specification-based and code
based testing. Most practitioners agree that code-based testing is most appropriate at the unit
level, whereas specification-based testing is most appropriate at the system level.

This is generally true; however, it is also a likely consequence of the base information
produced during the requirements specification, preliminary design, and detailed design
phases.

19
The constructs defined for code-based testing make the most sense at the unit level, and
similar constructs are only now becoming available for the integration and system levels of
testing.

Testing and Verification

What is Verification?

The verifying process includes checking documents, design, code, and program.

What is Validation?

Validation is a dynamic mechanism of Software testing and validates the actual product.

Verification vs Validation: Key Difference

Verification Validation

 The verifying process includes checking  It is a dynamic mechanism of

documents, design, code, and program testing and validating the actual
product

 It does not involve executing the code  It always involves executing the
code

 Verification uses methods like reviews,  It uses methods like Black Box
walkthroughs, inspections, and desk- checking Testing, White Box Testing,
etc. and non-functional testing

20
  Whether the software conforms to  It checks whether the software
specification is checked meets the requirements and
expectations of a customer

 It finds bugs early in the development cycle  It can find bugs that the
verification process can not
catch

 Target is application and software architecture,  Target is an actual product

specification, complete design, high level, and
database design etc.

 QA team does verification and make sure that  With the involvement of testing
the software is as per the requirement in the team validation is executed on
SRS document. software code.

 It comes before validation  It comes after verification

Static Testing

Static Testing is a type of a Software Testing method which is performed to check the
defects in software without actually executing the code of the software application. Whereas
in Dynamic Testing checks the code is executed to detect the defects.
Static testing is performed in early stage of development to avoid errors as it is easier to find
sources of failures and it can be fixed easily. The errors that can‘t not be found using
Dynamic Testing, can be easily found by Static Testing.

Static Testing Techniques:

There are mainly two type techniques used in Static Testing:

21
1. Review:
In static testing review is a process or technique that is performed to find the potential defects
in the design of the software.
It is process to detect and remove errors and defects in thedifferent supporting documents like
software requirements specifications.
People examine the documents and sorted out errors, redundancies and ambiguities.

Review is of four types:

 Informal:
In informal review the creator of the documents put the contents in front of audience
and everyone gives their opinion and thus defects are identified in the early stage.
 Walkthrough:
It is basically performed by experienced person or expert to check the defects so that
there might not be problem further in the development or testing phase.
 Peer review:
Peer review means checking documents of one-another to detect and fix the defects. It
is basically done in a team of colleagues.
 Inspection:
Inspection is basically the verification of document the higher authority like the
verification of software requirement specifications (SRS).

2. Static Analysis:

Static Analysis includes the evaluation of the code quality that is written by developers.
Different tools are used to do the analysis of the code and comparison of the same with the
standard.

It also helps in following identification of following defects:

(a) Unused variables
(b) Dead code
(c) Infinite loops
(d) Variable with undefined value
(e) Wrong syntax

Static Analysis is of three types:

 Data Flow:

Data flow is related to the stream processing

 Control Flow:

Control flow is basically how the statements or instructions are executed.

 Cyclomatic Complexity:

Cyclomatic complexity is the measurement of the complexity of the program that is

basically related to the number of independent paths in the control flow graph of the
program.

22
Problem Statements:

A PROBLEM STATEMENT is a concise description of an issue to be addressed or a

condition to be improved upon. It identifies the gap between the current (problem) state and
desired (goal) state of a process or product. Focusing on the facts, the problem statement
should be designed to address the Five Ws.

The first condition of solving a problem is to understand the problem, which can be done by
way of a problem statement.

Problem statements are widely used by businesses and organizations to execute

process improvement projects. A simple and well-defined problem statement will be used by
the project team to understand the problem and work toward developing a solution.

It will also provide management with specific insights into the problem so that they can make
appropriate project-approving decisions. As such, it is crucial for the problem statement to be
clear and unambiguous.
The Five Ws are questions whose answers are considered basic in information
gathering or problem solving.

 Who
 What
 When
 Where
 Why

Generalized pseudocode,

Pseudocode is an informal high-level description of the operating principle of a computer

program or other algorithm. It uses the structural conventions of a normal programming
language, but is intended for human reading rather than machine reading. Pseudocode
typically omits details that are essential for machine understanding of the algorithm, such
as variable declarations, system-specific code and some subroutines. The programming
language is augmented with natural language description details, where convenient, or with
compact mathematical notation. The purpose of using pseudocode is that it is easier for
people to understand than conventional programming language code, and that it is an efficient
and environment-independent description of the key principles of an algorithm.

 Pseudocode provides a “language neutral” way to express program source code.

 Pseudocode given here is based on visual basic.

23
24
The triangle problem

The triangle problem is the most widely used example in software testing literature.

2.2.1 Problem Statement

Simple version: The triangle program accepts three integers, a, b, and c, as input. These are
taken to be sides of a triangle. The output of the program is the type of triangle determined by
the three sides: Equilateral, Isosceles, Scalene, or NotATriangle. Sometimes, this problem is
extended to include right triangles as a fifth type; we will use this extension in some of the
exercises.

Improved version: The triangle program accepts three integers, a, b, and c, as input. These
are taken to be sides of a triangle. The integers a, b, and c must satisfy the following
conditions:

c1. 1 ≤ a ≤ 200 c4. a<b+c

c2. 1 ≤ b ≤ 200 c5. b<a+c
c3. 1 ≤ c ≤ 200 c6. c<a+b

The output of the program is the type of triangle determined by the three sides: Equilateral,

25
Isosceles, Scalene, or NotATriangle. If an input value fails any of conditions c1, c2, or c3,
the program notes this with an output message, for example, ―Value of b is not in the range of
permitted values.‖ If values of a, b, and c satisfy conditions c4, c5, and c6, one of four
mutually exclusive outputs is given:

1. If all three sides are equal, the program output is Equilateral.

2. If exactly one pair of sides is equal, the program output is Isosceles.
3. If no pair of sides is equal, the program output is Scalene.
4. If any of conditions c4, c5, and c6 is not met, the program output is NotATriangle.

2.2.2 Discussion
Perhaps one of the reasons for the longevity of this example is that it contains clear but
complex logic. It also typifies some of the incomplete definitions that impair communication
among customers, developers, and testers. The first specification presumes the developers
know some details about triangles, particularly the triangle inequality: the sum of any pair of
sides must be strictly greater than the third side.

2.2.3 Traditional Implementation

The traditional implementation of this grandfather of all examples has a rather FORTRAN-
like style. The flowchart for this implementation appears in Figure 2.1. Figure 2.2 is a
flowchart for the improved version. The flowchart box numbers correspond to comment
numbers in the (FORTRANlike) pseudocode program given next.

The variable ―match‖ is used to record equality among pairs of the sides. A classic intricacy
of the FORTRAN style is connected with the variable ―match‖: notice that all three tests for
the triangle inequality do not occur. If two sides are equal, say a and c, it is only necessary to
compare a + c with b. (Because b must be greater than zero, a + b must be greater than c
because c equals a.) This observation clearly reduces the number of comparisons that must be
made. The efficiency of this version is obtained at the expense of clarity (and ease of testing).

26
The pseudocode for this is given next. [Simple version]

Program triangle1

Dim a, b, c, match As INTEGER

Output(―Enter 3 integers which are sides of a triangle‖)

Input(a, b, c)

Output(―Side A is‖,a)
Output(―Side B is‖,b)
Output(―Side C is‖,c)

match = 0
If a = b ‗(1)

27
Then match = match + 1 ‗(2)
EndIf

If a = c ‗(3)
Then match = match + 2 ‗(4)
EndIf

If b = c ‗(5)
Then match = match + 3 ‗(6)
EndIf

If match = 0 ‗(7)
Then If (a + b)≤ c ‗(8)
Then Output(―NotATriangle‖) ‗(12.1)
Else If (b + c) ≤ a ‗(9)
Then Output(―NotATriangle‖) ‗(12.2)
Else If (a + c) ≤ b ‗(10)
Then Output(―NotATriangle‖) ‗(12.3)
Else Output (―Scalene‖) ‗(11)

EndIf
EndIf
EndIf

Else If match = 1 ‗(13)

Then If (a + c) ≤ b ‗(14)
Then Output(―NotATriangle‖) ‗(12.4)
Else Output (―Isosceles‖) ‗(15.1)
EndIf

Else If match=2 ‗(16)

Then If (a + c) ≤ b
Then Output(―NotATriangle‖) (12.5)
Else Output (―Isosceles‖) ‗(15.2)
EndIf

Else If match = 3 ‗(18)

Then If (b + c) ≤ a ‗(19)
Then Output(―NotATriangle‖) ‗(12.6)
Else Output (―Isosceles‖) ‗(15.3)
EndIf

Else Output (―Equilateral‖) ‗(20)

EndIf
EndIf
EndIf
EndIf
‗
End Triangle1

28
2.2.4 Structured Implementations
The pseudocode for [Improved Version]

Step 1: Get Input

Output(―Enter 3 integers which are sides of a triangle‖)
Input(a,b,c)
Output(―Side A is‖,a)
Output(―Side B is‖,b)
Output(―Side C is‖,c)

Step 2: Is A Triangle?‘
If (a < b + c) AND (b < a + c) AND (c < a + b)
Then IsATriangle = True
Else IsATriangle = False
EndIf

Step 3: Determine Triangle Type

If IsATriangle
Then If (a = b) AND (b = c)
Then Output (―Equilateral‖)
Else If (a ≠ b) AND (a ≠ c) AND (b ≠ c)
Then Output (―Scalene‖)
Else Output (―Isosceles‖)
EndIf
EndIf
Else Output(―Not a Triangle‖)
EndIf
End triangle2

The pseudocode for [Final Version]

Third version
Program triangle3

Dim a, b, c As Integer
Dim c1, c2, c3, IsATriangle As Boolean
Step 1: Get Input
Do
Output(―Enter 3 integers which are sides of a triangle‖)
Input(a, b, c)
c1 = (1 ≤ a) AND (a ≤ 300)
c2 = (1 ≤ b) AND (b ≤ 300)
c3 = (1 ≤ c) AND (c ≤ 300)

If NOT(c1)
Then Output(―Value of a is not in the range of permitted values‖)
EndIf
If NOT(c2)
Then Output(―Value of b is not in the range of permitted values‖)
EndIf
If NOT(c3)

29
ThenOutput(―Value of c is not in the range of permitted values‖)
EndIf
Until c1 AND c2 AND c3
Output(―Side A is‖,a)
Output(―Side B is‖,b)
Output(―Side C is‖,c)
‗Step 2: Is A Triangle?
If (a < b + c) AND (b < a + c) AND (c < a + b)
Then IsATriangle = True
Else IsATriangle = False

2.3 T he NextDate Function

The complexity in the triangle program is due to the relationships between inputs and correct
outputs. We will use the NextDate function to illustrate a different kind of complexity—
logical relationships among the input variables.

2.3.1 Problem Statement

NextDate is a function of three variables: month, date, and year. It returns the date of the day
after the input date. The month, date, and year variables have integer values subject to these
conditions

(the year range ending in 2012 is arbitrary, and is from the first edition):
c1. 1 ≤ month ≤ 12
c2. 1 ≤ day ≤ 31
c3. 1812 ≤ year ≤ 2012

As we did with the triangle program, we can make our problem statement more specific. This
entails defining responses for invalid values of the input values for the day, month, and year.

We can also define responses for invalid combinations of inputs, such as June 31 of any year.

If any of conditions c1, c2, or c3 fails, NextDate produces an output indicating the
corresponding variable has an out-of-range value—for example, ―Value of month not in the
range 1...12.‖ Because numerous invalid day–month–year combinations exist, NextDate
collapses these into one message: ―Invalid Input Date.‖

2.3.2 Discussion
Two sources of complexity exist in the NextDate function: the complexity of the input
domain discussed previously, and the rule that determines when a year is a leap year. A year
is 365.2422 days long; therefore, leap years are used for the ―extra day‖ problem. If we
declared a leap year every fourth year, a slight error would occur.

The Gregorian calendar (after Pope Gregory) resolves this by adjusting leap years on century
years. Thus, a year is a leap year if it is divisible by 4, unless it is a century year. Century
years are leap years only if they are multiples of 400 (Inglis, 1961); thus, 1992, 1996, and
2000 are leap years, while the year 1900 is not a leap year. The NextDate function also
illustrates a sidelight of software testing.

30
2.3.3 Implementations
Program NextDate1 ‗Simple version

Dim tomorrowDay,tomorrowMonth,tomorrowYear As Integer

Dim day,month,year As Integer
Output (―Enter today‘s date in the form MM DD YYYY‖)

Input (month, day, year)

Case month Of
Case 1: month Is 1,3,5,7,8, Or 10: ‗31 day months (except Dec.)
If day < 31
Then tomorrowDay = day + 1
Else
tomorrowDay = 1
tomorrowMonth = month + 1
EndIf

Case 2: month Is 4,6,9, Or 11 ‗30 day months

If day < 30
Then tomorrowDay = day + 1
Else
tomorrowDay = 1
tomorrowMonth = month + 1
EndIf

Case 3: month Is 12: ‗December

If day < 31
Then tomorrowDay = day + 1
Else
tomorrowDay = 1
tomorrowMonth = 1
If year = 2012
Then Output (―2012 is over‖)
Else tomorrow.year = year + 1
EndIf

Case 4: month is 2: ‗February

If day < 28
Then tomorrowDay = day + 1
Else
If day = 28
Then If ((year is a leap year)
Then tomorrowDay = 29 ‗leap year
Else ‗not a leap year
tomorrowDay = 1
tomorrowMonth = 3
EndIf

31
Else If day = 29
Then If ((year is a leap year)
Then tomorrowDay = 1
tomorrowMonth = 3
Else ‗not a leap year
Output(―Cannot have Feb.‖, day)

EndIf
EndIf
EndIf
EndIf
EndCase

Output (―Tomorrow‘s date is‖, tomorrowMonth, tomorrowDay, tomorrowYear)

End NextDate

Program NextDate2 Improved version

Dim tomorrowDay,tomorrowMonth,tomorrowYear As Integer

Dim day,month,year As Integer
Dim c1, c2, c3 As Boolean

Do
Output (―Enter today‘s date in the form MM DD YYYY‖)

Input (month, day, year)

c1 = (1 ≤ day) AND (day ≤ 31)
c2 = (1 ≤ month) AND (month ≤ 12)
c3 = (1812 ≤ year) AND (year ≤ 2012)

If NOT(c1)
Then Output(―Value of day not in the range 1..31‖)
EndIf

If NOT(c2)
Then Output(―Value of month not in the range 1..12‖)
EndIf

If NOT(c3)
Then Output(―Value of year not in the range 1812..2012‖)
EndIf

Until c1 AND c2 AND c2

Case month Of
Case 1: month Is 1,3,5,7,8, Or 10: ‗31 day months (except Dec.)
If day < 31
Then tomorrowDay = day + 1

32
Else
tomorrowDay = 1
tomorrowMonth = month + 1
EndIf

Case 2: month Is 4,6,9, Or 11 ‗30 day months

If day < 30
Then tomorrowDay = day + 1
Else
If day = 30
Then tomorrowDay = 1
tomorrowMonth = month + 1
Else Output(―Invalid Input Date‖)
EndIf
EndIf

Case 3: month Is 12: ‗December

If day < 31
Then tomorrowDay = day + 1
Else
tomorrowDay = 1
tomorrowMonth = 1
If year = 2012
Then Output (―Invalid Input Date‖)
Else tomorrow.year = year + 1
EndIf
EndIf

Case 4: month is 2: ‗February

If day < 28
Then tomorrowDay = day + 1

Else

If day = 28
Then
If (year is a leap year)
Then tomorrowDay = 29 ‗leap day
Else ‗not a leap year
tomorrowDay = 1
tomorrowMonth = 3
EndIf

Else

If day = 29
Then

33
If (year is a leap year)
Then tomorrowDay = 1
tomorrowMonth = 3

Else

If day > 29
Then Output(―Invalid Input Date‖)
EndIf
EndIf
EndIf
EndIf
EndIf
EndCase
Output (―Tomorrow‘s date is‖, tomorrowMonth, tomorrowDay, tomorrowYear)

End NextDate2

2.4 T he Commission Problem

Our third example is more typical of commercial computing. It contains a mix of
computation and decision making, so it leads to interesting testing questions. Our main use of
this example will be in our discussion of data flow and slice-based testing.

2.4.1 Problem Statement

A rifle salesperson in the former Arizona Territory sold rifle locks, stocks, and barrels made
by a gunsmith in Missouri. Locks cost $45, stocks cost $30, and barrels cost $25. The
salesperson had to sell at least one lock, one stock, and one barrel (but not necessarily one
complete rifle) per month, and production limits were such that the most the salesperson
could sell in a month was 70 locks, 80 stocks, and 90 barrels. After each town visit, the
salesperson sent a telegram to the Missouri gunsmith with the number of locks, stocks, and
barrels sold in that town.

At the end of a month, the salesperson sent a very short telegram showing –1 lock sold. The
gunsmith then knew the sales for the month were complete and computed the salesperson‘s
commission as follows: 10% on sales up to (and including) $1000, 15% on the next $800, and
20% on any sales in excess of $1800.

2.4.2 Discussion
This example is somewhat contrived to make the arithmetic quickly visible to the reader. It
might be more realistic to consider some other additive function of several variables, such as
various calculations found in filling out a US 1040 income tax form. (We will stay with
rifles.)

This problem separates into three distinct pieces: the input data portion, in which we could
deal with input data validation (as we did for the triangle and NextDate programs), the sales
calculation, and the commission calculation portion. This time, we will omit the input data
validation portion. We will replicate the telegram convention with a sentinel-controlled while
loop that is typical of MIS data gathering applications.

34
2.4.3 Implementation
Program Commission (INPUT,OUTPUT)
‗
Dim locks, stocks, barrels As Integer
Dim lockPrice, stockPrice, barrelPrice As Real
Dim totalLocks,totalStocks,totalBarrels As Integer
Dim lockSales, stockSales, barrelSales As Real
Dim sales,commission : REAL
‗
lockPrice = 45.0
stockPrice = 30.0
barrelPrice = 25.0
totalLocks = 0
totalStocks = 0
totalBarrels = 0
‗
Input(locks)
While NOT(locks = -1) ‗Input device uses -1 to indicate end of data
Input(stocks, barrels)
totalLocks = totalLocks + locks
totalStocks = totalStocks + stocks
totalBarrels = totalBarrels + barrels
Input(locks)
EndWhile
‗
Output(―Locks sold:‖, totalLocks)
Output(―Stocks sold:‖, totalStocks)
Output(―Barrels sold:‖, totalBarrels)
‗
lockSales = lockPrice * totalLocks
stockSales = stockPrice * totalStocks
barrelSales = barrelPrice * totalBarrels
sales = lockSales + stockSales + barrelSales
Output(―Total sales:‖, sales)
‗
If (sales > 1800.0)
Then
commission = 0.10 * 1000.0
commission = commission + 0.15 * 800.0
commission = commission + 0.20 * (sales–1800.0)
Else If (sales > 1000.0)
Then
commission = 0.10 * 1000.0
commission = commission + 0.15*(sales–1000.0)
Else commission = 0.10 * sales
EndIf
EndIf
Output(―Commission is $‖,commission)
End Commission

35
2.5 T he SATM System
To better discuss the issues of integration and system testing, we need an example with larger
scope (Figure 2.3).

The ATM described here is minimal, yet it contains an interesting variety of functionality and
interactions that typify the client side of client–server systems.

2.5.1 Problem Statement

The SATM system communicates with bank customers via the 15 screens shown in Figure
2.4.

Using a terminal with features as shown in Figure 2.3, SATM customers can select any of
three transaction types: deposits, withdrawals, and balance inquiries. For simplicity, these
transactions can only be done on a checking account.

When a bank customer arrives at an SATM station, screen 1 is displayed. The bank customer
accesses the SATM system with a plastic card encoded with a personal account number
(PAN), which is a key to an internal customer account file, containing, among other things,
the customer‘s name and account information.

If the customer‘s PAN matches the information in the customer account file, the system
presents screen 2 to the customer. If the customer‘s PAN is not found, screen 4 is displayed,
and the card is kept.

At screen 2, the customer is prompted to enter his or her personal identification number
(PIN). If the PIN is correct (i.e., matches the information in the customer account file), the
system displays screen 5; otherwise, screen 3 is displayed.

The customer has three chances to get the PIN correct; after three failures, screen 4 is
displayed, and the card is kept.
36
On entry to screen 5, the customer selects the desired transaction from the options shown on
screen. If balance is requested, screen 14 is then displayed. If a deposit is requested, the status
of the deposit envelope slot is determined from a field in the terminal control file. If no
problem is known, the system displays screen 7 to get the transaction amount. If a problem
occurs with the deposit envelope slot,

The system displays screen 12. Once the deposit amount has been entered, the system
displays screen 13, accepts the deposit envelope, and processes the deposit. The system then
displays screen 14.

If a withdrawal is requested, the system checks the status (jammed or free) of the withdrawal
chute in the terminal control file. If jammed, screen 10 is displayed; otherwise, screen 7 is
displayed so the customer can enter the withdrawal amount. Once the withdrawal amount is
entered, the system checks the terminal status file to see if it has enough currency to dispense.

If it does not, screen 9 is displayed; otherwise, the withdrawal is processed. The system
checks the customer balance (as described in the balance request transaction); if the funds in
the account are insufficient, screen 8 is displayed. If the account balance is sufficient, screen
11 is displayed and the money is dispensed. The balance is printed on the transaction receipt
as it is for a balance request transaction.

37
After the cash has been removed, the system displays screen 14.

When the ―No‖ button is pressed in screens 10, 12, or 14, the system presents screen 15 and
returns the customer‘s ATM card. Once the card is removed from the card slot, screen 1 is
displayed.

When the ―Yes‖ button is pressed in screens 10, 12, or 14, the system presents screen 5 so the
customer can select additional transactions.

2.6 T he Currency Converter

The currency conversion program is another event-driven program that emphasizes code
associated with a GUI. A sample GUI is shown in Figure 2.5.

Problem Statement

The currency converter application converts U.S. dollars to any of four currencies: Brazilian
reals, Canadian dollars, European Community euros, and Japanese yen. The user can revise
inputs and perform repeated currency conversion.

System Functions
In the first step, sometimes called project inception, the customer/user describes the
application in very general terms. This might take the form of ―user stories,‖ which are
precursors to use cases.

From these, three types of system functions are identified: evident, hidden, and frill. Evident
functions are the obvious ones. Hidden functions might not be discovered immediately, and
frills are the ―bells and whistles‖ that so often occur. Table 15.3 lists the system functions for
the currency converter application.

38
Presentation Layer

Pictures are still worth a thousand words. The third step in Larman‘s approach is to sketch the
user interface; our version is in Figure 2.5. This much information can support a customer
walkthrough to demonstrate that the system functions identified can be supported by the
interface.

High-Level Use Cases

The use case development begins with a very high-level view. Notice, as the succeeding
levels of use cases are elaborated, much of the early information is retained.

It is convenient to have a short, structured naming convention for the various levels of use
cases. Here, for example, HLUC refers to high-level use case (where would we be without
acronyms?).

Very few details are provided in a high-level use case; they are insufficient for test case
identification.

The main point of high-level use cases is that they capture a narrative description of
something that happens in the system to be built.

39
Essential Use Cases

Essential use cases add ―actor‖ and ―system‖ events to a high-level use case. Actors in UML
are sources of system-level inputs (i.e., port input events). Actors can be people, devices,
adjacent systems, or abstractions such as time. Since the only actor is the User, that part of an
essential use case is omitted. The numbering of actor actions (port input events) and system
responses (port output events) shows their approximate sequences in time.

40
41
C PROGRAM FOR CONVERTING US DOLLARS TO FRANC, POUNDS, YEN, EUROS
AND CANADIAN DOLLAR

#include<stdio.h>
#include<stdlib.h>
#define Swiss_Franc_rate 0.6072; /*Swiss Franc rate*/
#define British_Pounds_rate 1.4320; /*British Pound rate*/
#define Japanese_Yen_rate 0.0081; /*Japanese Yen rate*/
#define Canadian_Dollar_rate 0.6556; /*Canadian Dollar rate*/
#define Euros_rate 0.8923;

int main(void){

/*Declare floaters*/

float Swiss_Franc; /*Swiss Franc*/

float British_Pounds; /*British pounds*/
float Japanese_Yen; /*Japanese Yen*/
float Canadian_Dollar; /*Canadian Dollar*/
float Euros; /*European Union Euro*/
float USD; /*US Dollar*/
int choice;

/*Title*/

printf(" Currency Conversion Program\n");

printf("----------------------------------------\n\n");

/*Menu*/

printf("1) Swiss Franc \n");

42
 printf("2) British Pound \n");
printf("3) Japanese Yen \n");
printf("4) Canadian Dollar \n");
printf("5) Euro \n");
printf("6) Exit the Program \n");

printf("\n");
printf("\n");

/*Input from User*/

printf("Please enter your choice (1-6): ");

scanf("%d",&choice);

while((choice<1) || (choice>6)){
printf("Invalid entry, please Enter 1-6: ");
scanf("%i",&choice);
}

if(choice==1){
printf("Please the amount: ");
scanf("%f",&Swiss_Franc);

/*Conversion Calculation 1*/

Swiss_Franc = USD / Swiss_Franc_rate;

if(choice==2){
printf("Please enter the amount: ");
scanf("%f",&British_Pounds);

/*Conversion Calculation 2*/

British_Pounds = USD / British_Pounds_rate;
}

if(choice==3){
printf("Please enter the amount: ");
scanf("%f",&Japanese_Yen);

/*Conversion Calculation 3*/

Japanese_Yen = USD / Japanese_Yen_rate
}

if(choice==4){
printf("Please enter the amount: ");
scanf("%f",&Canadian_Dollar);

43
 /*Conversion Calculation 4*/
Canadian_Dollar = USD / Canadian_Dollar_rate;
}

if(choice==5){
printf("Please enter the amount: ");
scanf("%f",&Euros);

/*Conversion Calculation 5*/

Euros = USD / Euros_rate;
}

if(choice==6){
printf("Exit the program: ");

while (getchar() != '\n')

continue;
goto top;
}
printf("Goodbye!\n");
return 0;

Saturn Windshield Wiper Controller

The windshield wiper on some Saturn automobiles is controlled by a lever with a dial. The
lever has four positions: OFF, INT (for intermittent occurring at irregular intervals; not
continuous or steady), LOW, and HIGH;

The dial has three positions, numbered simply 1, 2, and 3.

The dial positions indicate three intermittent speeds.

The dial position is relevant only when the lever is at the INT position.

The decision table below shows the windshield wiper speeds (in wipes per minute) for the
lever and dial positions.

44
Garage Door Controller

A system to open a garage door is composed of several components: a drive motor, a drive
chain, the garage door wheel tracks, a lamp, and an electronic controller. This much of the
system is powered by commercial 110 V electricity. Several devices communicate with the
garage door controller—a wireless keypad (usually in an automobile), a digit keypad on the
outside of the garage door, and a wall-mounted button.

In addition, there are two safety features, a laser beam near the floor and an obstacle sensor.
These latter two devices operate only when the garage door is closing. If the light beam is
interrupted (possibly by a pet), the door immediately stops, and then reverses direction until
the door is fully open. If the door encounters an obstacle while it is closing (say a child‘s
tricycle left in the path of the door), the door stops and reverses direction until it is fully open.

There is a third way to stop a door in motion, either when it is closing or opening. A signal
from any of the three devices (wireless keypad, digit keypad, or wall-mounted control
button).

The response to any of these signals is different—the door stops in place. A subsequent signal
from any of the devices starts the door in the same direction as when it was stopped. Finally,
there are sensors that detect when the door has moved to one of the extreme positions, either
fully open or fully closed. When the door is in motion, the lamp is lit, and remains lit for
approximately 30 seconds after the door reaches one of the extreme positions.

The three signaling devices and the safety features are optional additions to the basic garage
door opener. This example will be used in Chapter 17 in the discussion of systems of
systems. For now, a SysML context diagram of the garage door opener is given in Figure 2.6.

Figure 2.6 SysML diagram of garage door controller.

45