UNIT 3 CHAPTER 2

SOFTWARE TESTING
SOFTWARE TESTING LIFE CYCLE

Software Testing Life Cycle (STLC):

It is a sequence of different activities performed during the software testing process.

Characteristics of STLC:

 STLC is a fundamental part of Software Development Life Cycle (SDLC) but STLC
consists of only the testing phases.
 STLC starts as soon as requirements are defined or software requirement document is
shared by stakeholders.
 STLC yields a step-by-step process to ensure quality software.

In the initial stages of STLC, while the software product or the application is being
developed, the testing team analyzes and defines the scope of testing, entry and exit criteria
and also the test cases. It helps to reduce the test cycle time and also enhance the product
quality.
As soon as the development phase is over, testing team is ready with test cases and start the
execution. This helps in finding bugs in the early phase.

Phases of STLC:
 1. Requirement Analysis:
Requirement Analysis is the first step of Software Testing Life Cycle (STLC). In this
phase quality assurance team understands the requirements like what is to be tested. If
anything is missing or not understandable then quality assurance team meets with the
stakeholders to better understand the detail knowledge of requirement.
2. Test Planning:
Test Planning is most efficient phase of software testing life cycle where all testing
plans are defined. In this phase manager of the testing team calculates estimated effort
and cost for the testing work. This phase gets started once the requirement gathering
phase is completed.
3. Test Case Development:
The test case development phase gets started once the test planning phase is
completed. In this phase testing team note down the detailed test cases. Testing team
also prepare the required test data for the testing. When the test cases are prepared
then they are reviewed by quality assurance team.
4. Test Environment Setup:
Test environment setup is the vital part of the STLC. Basically test environment
decides the conditions on which software is tested. This is independent activity and
can be started along with test case development. In this process the testing team is not
involved. either the developer or the customer creates the testing environment.
5. Test Execution:
After the test case development and test environment setup test execution phase gets
started. In this phase testing team start executing test cases based on prepared test
cases in the earlier step.
6. Test Closure:
This is the last stage of STLC in which the process of testing is analyzed.

WHITE BOX TESTING:

White box testing is a testing technique, that examines the program structure and derives test
data from the program logic/code. The other names of glass box testing are clear box testing,
open box testing, logic driven testing or path driven testing or structural testing.

White Box Testing Process :

Step 1: Gather requirements, functional specifications, design documents, source code.

Step 2: Testing plan preparation

Step 3: Test case preparation

Step 4: Test case execution

Step 5: Defect Reporting & fixing issues

The types of white box testing are as follows:

Unit Testing

Unit Testing is one of the basic steps, which is performed in the early stages. Most of the
testers prefer performing to check if a specific unit of code is functional or not. Unit Testing
is one of the common steps performed for every activity because it helps in removing basic
and simple errors.

Types of unit testing:

1. Execution testing

2. Operation testing

3. Mutation testing

Execution Testing:
It is a white box testing type that is to test the code and compare the actual output with
the expected output.
This testing technique is again divided into different types
 Statement Coverage
  Branch Coverage
 Path Coverage
Operations Testing:
It is a wite box testing type that is to test the non-functional attributes such as
perfromance, load, usability, security etc., of the unit module.

Mutation Testing:
It is a white box testing type that is to change (mutate) certain statements in the source
code and verify if the tests are able to find the errors.

Integration testing:

It is defined as a type of testing where software modules are integrated logically and tested as
a group. A typical software project consists of multiple software modules, coded by different
programmers. The purpose of this level of testing is to expose defects in the interaction
between these software modules when they are integrated.
Types of Integration Testing:
1. Top-down approach
2. Bottom-up approach
3. Hybrid approach
Bottom-up Integration Testing:
It is a strategy in which the lower level modules are tested first. These tested
modules are then further used to facilitate the testing of higher level modules. The
process continues until all modules at top level are tested. Once the lower level
modules are tested and integrated, then the next level of modules are formed.

Top-down Integration Testing:

It is a method in which integration testing takes place from top to bottom
following the control flow of software system. The higher level modules are tested
first and then lower level modules are tested and integrated in order to check the
software functionality. Stubs are used for testing if some modules are not ready.

Sandwich Testing :
It is a strategy in which top level modules are tested with lower level modules
at the same time lower modules are integrated with top modules and tested as a
system. It is a combination of Top-down and Bottom-up approaches therefore it is
called Hybrid Integration Testing. It makes use of both stubs as well as drivers.
White Box 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 is covered.

Calculating Structural Testing Effectiveness:

Statement Testing = (Number of Statements Exercised / Total Number

of Statements) x 100 %

Branch Testing = (Number of decisions outcomes tested / Total Number

of decision Outcomes) x 100 %

Path Coverage = (Number paths exercised / Total Number of paths in

the program) x 100 %

Advantages of White Box 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 White Box Testing:

 Expensive as one has to spend both time and money to perform white box testing.
 Every possibility that few lines of code are missed accidentally.
  In-depth knowledge about the programming language is necessary to perform white
box testing.

BLACK BOX TESTING:

Black box testing is a technique of software testing which examines the functionality
of software without peering into its internal structure or coding. The primary source
of black box testing is a specification of requirements that is stated by the customer.

In this method, tester selects a function and gives input value to examine its
functionality, and checks whether the function is giving expected output or not. If the
function produces correct output, then it is passed in testing, otherwise failed. The
test team reports the result to the development team and then tests the next
function. After completing testing of all functions if there are severe problems, then it
is given back to the development team for correction.

Decision Table Decision Table Technique is a systematic approach where various

Technique input combinations and their respective system behavior are
captured in a tabular form. It is appropriate for the functions that
have a logical relationship between two and more than two inputs.

Boundary Value Boundary Value Technique is used to test boundary values,

Technique boundary values are those that contain the upper and lower limit of
a variable. It tests, while entering boundary value whether the
software is producing correct output or not.

State Transition State Transition Technique is used to capture the behavior of the
Technique software application when different input values are given to the
same function. This applies to those types of applications that
provide the specific number of attempts to access the application.

All-pair Testing All-pair testing Technique is used to test all the possible discrete
Technique combinations of values. This combinational method is used for
 testing the application that uses checkbox input, radio button input,
list box, text box, etc.

Cause-Effect Cause-Effect Technique underlines the relationship between a given

Technique result and all the factors affecting the result.It is based on a
collection of requirements.

Equivalence Equivalence partitioning is a technique of software testing in which

Partitioning input data divided into partitions of valid and invalid values, and it is
Technique mandatory that all partitions must exhibit the same behavior.

Error Guessing Error guessing is a technique in which there is no specific method

Technique for identifying the error. It is based on the experience of the test
analyst, where the tester uses the experience to guess the
problematic areas of the software.

Use Case Use case Technique used to identify the test cases from the
Technique beginning to the end of the system as per the usage of the system.
By using this technique, the test team creates a test scenario that
can exercise the entire software based on the functionality of each
function from start to end

SOFTWARE TESTING PRINCIPLES:

Software testing is a process of executing a program with the aim of finding the error. To
make our software perform well it should be error free. If testing is done successfully it will
remove all the errors from the software.

There are seven principles in software testing:

1. Testing shows presence of defects

2. Exhaustive testing is not possible
3. Early testing
4. Defect clustering
5. Pesticide paradox
6. Testing is context dependent
7. Absence of errors fallacy

 Testing shows presence of defects: The goal of software testing is to make the
software fail. Software testing reduces the presence of defects. Software testing talks
about the presence of defects and doesn’t talk about the absence of defects. Software
testing can ensure that defects are present but it can not prove that software is defects
free. Even multiple testing can never ensure that software is 100% bug-free. Testing
can reduce the number of defects but not removes all defects.
  Exhaustive testing is not possible: It is the process of testing the functionality of a
software in all possible inputs (valid or invalid) and pre-conditions is known as
exhaustive testing. Exhaustive testing is impossible means the software can never test
at every test cases. It can test only some test cases and assume that software is correct
and it will produce the correct output in every test cases. If the software will test every
test cases then it will take more cost, effort, etc. and which is impractical.
 Early Testing: To find the defect in the software, early test activity shall be started.
The defect detected in early phases of SDLC will very less expensive. For better
performance of software, software testing will start at initial phase i.e. testing will
perform at the requirement analysis phase.
 Defect clustering: In a project, a small number of the module can contain most of the
defects. Pareto Principle to software testing state that 80% of software defect comes
from 20% of modules.
 Pesticide paradox: Repeating the same test cases again and again will not find new
bugs. So it is necessary to review the test cases and add or update test cases to find
new bugs.
 Testing is context dependent: Testing approach depends on context of software
developed. Different types of software need to perform different types of testing. For
example, The testing of the e-commerce site is different from the testing of the
Android application.
 Absence of errors fallacy: If a built software is 99% bug-free but it does not follow
the user requirement then it is unusable. It is not only necessary that software is 99%
bug-free but it also mandatory to fulfill all the customer requirements.

AGILE SOFTWARE ENGINEERING:

Agile SDLC model is a combination of iterative and incremental process models with focus
on process adaptability and customer satisfaction by rapid delivery of working software
product. Agile Methods break the product into small incremental builds. These builds are
provided in iterations. Each iteration typically lasts from about one to three weeks. Every
iteration involves cross functional teams working simultaneously on various areas like −

 Planning
 Requirements Analysis
 Design
 Coding
 Unit Testing and
 Acceptance Testing.

At the end of the iteration, a working product is displayed to the customer and important
stakeholders.

What is Agile?
Agile model believes that every project needs to be handled differently and the existing
methods need to be tailored to best suit the project requirements. In Agile, the tasks are
divided to time boxes (small time frames) to deliver specific features for a release.

Iterative approach is taken and working software build is delivered after each iteration. Each
build is incremental in terms of features; the final build holds all the features required by the
customer.

Here is a graphical illustration of the Agile Model −

The Agile thought process had started early in the software development and started
becoming popular with time due to its flexibility and adaptability.

The most popular Agile methods include Rational Unified Process (1994), Scrum (1995),
Crystal Clear, Extreme Programming (1996), Adaptive Software Development, Feature
Driven Development, and Dynamic Systems Development Method (DSDM) (1995). These
are now collectively referred to as Agile Methodologies, after the Agile Manifesto was
published in 2001.

Following are the Agile Manifesto principles −

 Individuals and interactions − In Agile development, self-organization and

motivation are important, as are interactions like co-location and pair programming.
 Working software − Demo working software is considered the best means of
communication with the customers to understand their requirements, instead of just
depending on documentation.
 Customer collaboration − As the requirements cannot be gathered completely in the
beginning of the project due to various factors, continuous customer interaction is
very important to get proper product requirements.
 Responding to change − Agile Development is focused on quick responses to change
and continuous development.