Unit-1 (Marks-14)

Basics of Software Testing and Testing Methods

1.1 Software Testing, Objective of Testing.

Software Testing:
Testing is executing a system in order to identify any gaps,
errors, or missing requirements in contrary to the actual
requirements.

Objective of Testing:

• Software testing is required to identify the defects and errors

during the development phases.
• It is necessary for customer reliability and their satisfaction.
• It is necessary to verify the quality of the product.
• It is necessary to give the facilities to the customer’s i.e the delivery
of the quality product or software application that requires lower
maintenance cost as results are accurate, consistent and reliable.
• Testing is needed for an effective performance of the software
product.

1.2 Failure, Error, Fault, Defect, Bug Terminologies.

Failure:
It is the inability of a system or component to perform required
function according to its specification.

Error:
It is an issue identified internally or during unit testing.
Normally error occurs when human action produce
undesirable results.
 Fault:
It is a condition that causes the software to fail to perform its
required function.

Defect:
It is an issue Identified by customer.

Bug:
Bug is an initiation of error or problem because of which the
fault may occur in the system.

1.3 Test Case, when to start and Stop Testing of Software

(Entry and Exit Criteria).

Test Case:

• Test cases involve a set of steps, conditions, and inputs that can be
used while performing testing tasks. The main intent of this activity
is to ensure whether software passes or fails in terms of its
functionality and other aspects. There are many types of test cases
such as functional, negative, error, logical test cases, physical test
cases, UI test cases, etc.
• Furthermore, test cases are written to keep track of the testing
coverage of software. Generally, there are no formal templates that
can be used during test case writing. However, the following
components are always available and included in every test case −
• Test case ID
• Product module
• Product version
• Revision history
• Purpose
• Assumptions
• Pre-conditions
• Steps
• Expected outcome
• Actual outcome
 • Post-conditions
Many test cases can be derived from a single test scenario. In
addition, sometimes multiple test cases are written for a single
software which are collectively known as test suites.

# When to start and Stop Testing of Software (Entry and Exit

Criteria):

When to Start Testing?

It depends on the process and the associated stakeholders of the

project(s). In the IT industry, large companies have a team with
responsibilities to evaluate the developed software in context of the
given requirements. Moreover, developers also conduct testing
which is called Unit Testing. In most cases, the following
professionals are involved in testing a system within their
respective capacities −

• Software Tester
• Software Developer
• Project Lead/Manager
• End User

Different companies have different designations for people who test

the software on the basis of their experience and knowledge such
as Software Tester, Software Quality Assurance Engineer, QA
Analyst, etc.
It is not possible to test the software at any time during its cycle.
The next two sections state when testing should be started and
when to end it during the SDLC.

When to Stop Testing?

It is difficult to determine when to stop testing, as testing is a

never-ending process and no one can claim that software is 100%
tested. The following aspects are to be considered for stopping the
testing process −
 • Testing Deadlines
• Completion of test case execution
• Completion of functional and code coverage to a certain point
• Bug rate falls below a certain level and no high-priority bugs
are identified
• Management decision

1.4 Verification and Validation ( V Model), Quality Assurance

and Quality Control.

Verification and Validation ( V Model):

• V model is known as Verification and Validation model.

• This model is an extension of the waterfall model.
• In the life cycle of V-shaped model, processes are executed
sequentially.
• Every phase completes its execution before the execution of next
phase begins.
 These two terms are very confusing for most people, who use
them interchangeably. The following table highlights the
differences between verification and validation.

Sr. Verification Validation

No.

1 Verification addresses the concern: Validation addresses the concern:

"Are you building it right?" "Are you building the right thing?"

2 Ensures that the software system Ensures that the functionalities

meets all the functionality. meet the intended behavior.

3 Verification takes place first and Validation occurs after verification

includes the checking for and mainly involves the checking
documentation, code, etc. of the overall product.

4 Done by developers. Done by testers.

5 It has static activities, as it includes It has dynamic activities, as it

collecting reviews, walkthroughs, and includes executing the software
inspections to verify a software. against the requirements.

6 It is an objective process and no It is a subjective process and

subjective decision should be needed to involves subjective decisions on
verify a software. how well a software works.

Advantages of V-model

• V-model is easy and simple to use.

• Many testing activities i.e planning, test design are executed in the
starting, it saves more time.
• Calculation of errors is done at the starting of the project hence,
less chances of error occurred at final phase of testing.
• This model is suitable for small projects where the requirements
are easily understood.

Disadvantages of V-model

• V-model is not suitable for large and composite projects.

• If the requirements are not constant then this model is not
acceptable.

Quality Assurance and Quality Control:

Quality Assurance Quality Control Testing

QA includes activities It includes activities that It includes activities

that ensure the ensure the verification of a that ensure the
implementation of developed software with identification of
processes, procedures respect to documented (or bugs/error/defects in a
and standards in context not in some cases) software.
to verification of requirements.
developed software and
intended requirements.

Focuses on processes Focuses on actual testing Focuses on actual

and procedures rather by executing the software testing.
than conducting actual with an aim to identify
testing on the system. bug/defect through
implementation of
procedures and process.

Process-oriented Product-oriented activities. Product-oriented

activities. activities.

Preventive activities. It is a corrective process. It is a preventive

process.
It is a subset of Software QC can be considered as Testing is the subset of
Test Life Cycle (STLC). the subset of Quality Quality Control.
Assurance.

1.5 Method of Testing: Static and Dynamic Testing.

Static Testing:
• In static testing, testing and identification of defects is
carried out without executing the code.
• This testing is done in verification process. This testing
consists of static analysis and reviewing of documents. For
example, reviewing, walkthrough, inspection, etc.

Dynamic Testing:
• In this testing, the software code is executed for showing
the result of tests performed.
• Dynamic testing is done in validation process i.e. unit
testing, integration testing, system testing, etc.

Difference between Static and Dynamic testing:

Static Testing Dynamic Testing

Static testing is completed Dynamic testing is completed with the
without executing the execution of program.
program.
This testing is executed in This testing is executed in validation stage.
verification stage.
Static testing is executed Dynamic testing is executed after the
before the compilation. compilation.
This testing prevents the This testing finds and fixes the defects.
defects.
The cost is less for finding The cost is high for finding and fixing the
 the defects and fixes. defects.
It consists of Walkthrough, It consists of specification based, structure
Inspection, reviews etc. based, Experience based, unit testing,
integration testing etc.

Static Testing Techniques

In this we are going to discuss about the static testing technique

i.e. Informal review, Walkthrough, Inspection, Technical
Reviews. Reviews vary from informal to formal review.

1.6 The Box Approach: White Box Testing:

Inspection, Walkthroughs, Technical Review, Functional

Testing, Code Coverage Testing, Code Complexity Testing.

1. Inspection:

• The trained moderator guides the Inspection. It is most formal

type of review.
• The reviewers are prepared and check the documents before the
meeting.
• In Inspection, a separate preparation is achieved when the product
is examined and defects are found. These defects are documented
in issue log.
• In Inspection, moderator performs a formal follow-up by applying
exit criteria.

Goals of Inspection

• Assist the author to improve the quality of the document under

inspection.
• Efficiently and rapidly remove the defects.
• Generating the documents with higher level of quality and it helps
to improve the product quality.
• It learns from the previous defects found and prohibits the
occurrence of similar defects.
• Generate common understanding by interchanging information.
 2. Walkthroughs:

• In walkthrough, author guides the review team via the document

to fulfill the common understanding and collecting the feedback.
• Walkthrough is not a formal process.
• In walkthrough, a review team does not require to do detailed
study before meeting while authors are already in the scope of
preparation.
• Walkthrough is useful for higher-level documents i.e.
requirement specification and architectural documents.

Goals of walkthrough
• Make the document available for the stakeholders both
outside and inside the software discipline for collecting the
information about the topic under documentation.
• Describe and evaluate the content of the document.
• Study and discuss the validity of possible alternatives and
proposed solutions.

3. Technical Review:
• Technical review is a discussion meeting that focuses on
technical content of the document. It is a less formal
review.
• It is guided by a trained moderator or a technical expert.

Goals of technical review

• The goal is to evaluate the value of technical concept in the project

environment.
• Build the consistency in the use and representation of the
technical concepts.
• In early stages it ensures that the technical concepts are used
correctly.
• Notify the participants regarding the technical content of the
document.
4. Functional Testing:

• Functional testing is based on the specified behavior of the

software and it is referred to as black box testing.
• This testing focuses on suitability, interoperability, security,
accuracy and compliance.
• The techniques used for functional testing are frequently
specification based.

Following are the two aspects of testing functionality:

i) Requirement-based testing
ii) Business-process-based testing

i) Requirement-based testing
• In requirement based testing, the requirements are prioritized
depending on the risk criteria.
• It ensures that important and critical tests are included in the
testing efforts.
ii) Business-process-based testing
• In this testing, knowledge of the business processes is used.
• It describes the framework involved in everyday use of the system.

5. Code Coverage Testing:

Code Coverage testing is determining how much code is being

tested. It can be calculated using the formula:

Code Coverage = (Number of lines of code

exercised)/(Total Number of lines of code) * 100%

Following are the types of code coverage Analysis:

• Statement coverage and Block coverage
• Function coverage
 • Function call coverage
• Branch coverage
• Modified condition/decision coverage

The coverage measurement of code is completed by using tools.

Many tools are available for this task.

These tools help for following tasks:

• It helps to improve the quality and productivity of testing.

• The quality improves to verify more structural aspects that are
tested. This helps to find the defects on that structural path.
• It helps in testing the same structure with different data.

6. Code Complexity Testing:

Code complexity is a source code complexity measurement that is

being correlated to a number of coding errors. It is calculated by
developing a Control Flow Graph of the code that measures the
number of linearly-independent paths through a program module.

Lower the Program's code complexity, lower the risk to modify and
easier to understand. It can be represented using the below
formula:

Code complexity = E - N + 2*P

where,
E = number of edges in the flow graph.
N = number of nodes in the flow graph.
P = number of nodes that have exit points

Example :

IF A = 10 THEN
IF B > C THEN
A=B
 ELSE
A=C
ENDIF
ENDIF
Print A
Print B
Print C

Flow Graph:

The Code complexity is calculated using the above control flow

diagram that shows seven nodes(shapes) and eight edges (lines).
Hence the Code complexity is 8 - 7 + 2 = 3
1.7 Black Box Testing: Requirement Based Testing, Boundary
Value Analysis, Equivalence Partitioning.

1. Requirement Based Testing:

Requirements-based testing is a testing approach in which test

cases, conditions and data are derived from requirements. It
includes functional tests and also non-functional attributes such
as performance, reliability or usability.

Stages in Requirements based Testing:

• Defining Test Completion Criteria - Testing is completed
only when all the functional and non-functional testing is
complete.
• Design Test Cases - A Test case has five parameters namely
the initial state or precondition, data setup, the inputs,
expected outcomes and actual outcomes.
• Execute Tests - Execute the test cases against the system
under test and document the results.
• Verify Test Results - Verify if the expected and actual results
match each other.
• Verify Test Coverage - Verify if the tests cover both
functional and non-functional aspects of the requirement.
• Track and Manage Defects - Any defects detected during the
testing process goes through the defect life cycle and are
tracked to resolution. Defect Statistics are maintained which
will give us the overall status of the project.

Requirements testing process:

• Testing must be carried out in a timely manner.

• Testing process should add value to the software life cycle,

hence it needs to be effective.
• Testing the system exhaustively is impossible hence the
testing process needs to be efficient as well.
 • Testing must provide the overall status of the project, hence it
should be manageable.

2. Boundary Value Analysis:

• Boundary Value Analysis is the test case design technique to test

boundary value between partitions.
• Boundary value is an input or value on the border of an
equivalence partition.
• It consists of start-end, lower-upper, maximum-minimum on
inside and outside boundaries.
• Boundary Value Analysis (BVA) checks the boundary values of
Equivalence Class Partitioning (ECP), hence BVA comes after
ECP.
• For example, A tool consists of user name and password field. It
accesses minimum 6 and maximum 10 characters to work with
this tool. Valid range is 6-10 characters, Invalid range is 5 or less
than 5 characters and more than 10 characters.

3. Equivalence Partitioning:
• In equivalence partitioning, software testing technique
divides the input data of a software unit into the partitions of
equivalent data and test cases are derived from the partitions
of equivalent data.
• Equivalence Partitioning is applied at any level of testing.
• The software treats all the conditions in one partition as the
same. Hence, equivalence partitioning needs to check only
one condition from each partition.
• Since, all the conditions in one partition are same, if one
condition in partition works then we can assume that all the
conditions in that partition work or otherwise.