1. UNIT-I
CS E71 SQA & TESTING Page 1
INTRODUCTION-SOFTWARE TESTING
Software testing is a process, or a series of processes, designed to make sure computer
code does what it was designed to do and that it does not do anything unintended. Software
should be predictable and consistent, offering no surprises to users.
OVERVIEW
Software testing is a technical task, but it also involves some important considerations of
economics and human psychology.
In an ideal world, we would want to test every possible permutation of a program. In
most cases, however, this simply is not possible. Even a seemingly simple program can have
hundreds or thousands of possible input and output combinations. Creating test cases for all of
these possibilities is impractical. Complete testing of a complex application would take too long
and require too many human resources to be economically feasible.
SCOPE OF SOFTWARE TESTING
The function of software testing is to detect bugs in order to correct and uncover it.
Software Testing is classified into two types of software testing: Manual Scripted Testing and
Automated Testing
The software testing have different goals and objectives which include:
1. Finding defects.
2. Gaining confidence in and providing information about the level of quality.
3. Preventing defects.
Objectives of testing
 Executing a program with the intent of finding an error.
 To check if the system meets the requirements and be executed successfully in the
Intended environment.
 To check if the system is “ Fit for purpose”.
 To check if the system does what it is expected to do.
Objective of a Software Tester
 Find bugs as early as possible and make sure they get fixed.
 To understand the application well.
 Study the functionality in detail to find where the bugs are likely to occur.

2. UNIT-I
CS E71 SQA & TESTING Page 2
 Study the code to ensure that each and every line of code is tested.
 Create test cases in such a way that testing is done to uncover the hidden bugs and also
ensure that the software is usable and reliable
SOFTWARE DEVELOPMENT LIFE CYCLE PROCESS
Software Development Life Cycle (SDLC) is a procedural process in the development of
a software product. The Process is carried out in steps to explain the whole idea about how to go
through each product.
The classification of SDLC is follows:
1. Planning
2. Analysis
3. Design
4. Software Development
5. Implementation
6. Software Testing
7. Deployment
8. Maintenance

3. UNIT-I
CS E71 SQA & TESTING Page 3
 PLAN (P): Device a plan. Define your objective and determine the strategy and
supporting methods required to achieve that objective.
 DO (D): Execute the plan. Create the conditions and perform the necessary training to
execute the plan.
 CHECK (C): Check the results. Check to determine whether work is progressing
according to the plan and whether the results are obtained.
 ACTION (A): Take the necessary and appropriate action if checkup reveals that the
work is not being performed according to plan or not as anticipated.
PHASES of SDLC
 Requirement Specification and Analysis
 Design
 Coding
 Testing
 Implementation
 Maintenance
Requirement
Specification
and Analysis
User Requirement
Specification (USR)
Software
Requirement
Specification (SRS)

4. UNIT-I
CS E71 SQA & TESTING Page 4
Design
The output of SRS is the input of design phase.
Two types of design
High Level Design (HLD)
Low Level Design (LLD)
The Design process
Breaking down the product into independent modules to arrive at micro levels.
Two different approaches followed in designing
 Top Down Approach
 Bottom Up Approach

5. UNIT-I
CS E71 SQA & TESTING Page 5
Coding
Developers use the LLD document and write the code in the programming language
specified.
Testing
The testing process involves development of a test plan, executing the plan and
documenting the test results.
Implementation
Installation of the product in its operational environment.
Maintenance
After the software is released and the client starts using the software, maintenance phase
is started.
3 things happen - Bug fixing, Upgrade, Enhancement
Bug fixing – bugs arrived due to some untested scenarios.
Upgrade – Upgrading the application to the newer versions of the software.
Enhancement - Adding some new features into the existing software.

6. UNIT-I
CS E71 SQA & TESTING Page 6
SOFTWARE LIFE CYCLE MODELS
WATERFALL MODEL
V-PROCESS MODEL
SPIRAL MODELS
PROTOTYPE MODEL
INCREMENTAL MODEL
EVOLUTIONARY DEVELOPMENT MODEL
SOFTWARE TESTING TYPES
Manual testing
This type includes the testing of the Software manually i.e. without using any automated tool or
any script. In this type the tester takes over the role of an end user and test the Software to
identify any un-expected behavior or bug. There are different stages for manual testing like unit
testing, Integration testing, System testing and User Acceptance testing.
Testers use test plan, test cases or test scenarios to test the Software to ensure the completeness
of testing. Manual testing also includes exploratory testing as testers explore the software to
identify errors in it.
Automation testing
Automation testing which is also known as Test Automation, is when the tester writes scripts and
uses another software to test the software. This process involves automation of a manual process.
Automation Testing is used to re-run the test scenarios that were performed manually, quickly
and repeatedly.ss

7. UNIT-I
CS E71 SQA & TESTING Page 7
Apart from regression testing, Automation testing is also used to test the application from load,
performance and stress point of view. It increases the test coverage; improve accuracy, saves
time and money in comparison to manual testing.
THE PSYCHOLOGY OF TESTING
One of the primary causes of poor program testing is the fact that most programmers begin
with a false definition of the term. They might say:
“Testing is the process of demonstrating that errors are not present.”
“The purpose of testing is to show that a program performs its intended functions
correctly.”
“Testing is the process of establishing confidence that a program does what it is
supposed to do.”
These definitions are upside-down.
THE ECONOMICS OF TESTING
Given this definition of program testing, an appropriate next step is the determination of
whether it is possible to test a program to find all of its errors. We will show you that the answer
is negative, even for trivial programs. In general, it is impractical, often impossible, to find all
the errors in a program. This fundamental problem will, in turn, have implications for the
economics of testing, assumptions that the tester will have to make about the program, and the
manner in which test cases are designed.
To combat the challenges associated with testing economics, you should establish some
strategies before beginning. Two of the most prevalent strategies include black-box testing
and white-box testing techniques.
VERIFICATION AND VALIDATION
Software testing is one element of a broader topic that is often referred to as verification
and validation (V&V). Verification refers to the set of activities that ensure that software
correctly implements a specific function. Validation refers to a different set of activities that
ensure that the software that has been built is traceable to customer requirements.
Boehm states this another way:
Verification: "Are we building the product right?"
Validation: "Are we building the right product?"
The definition of V&V encompasses many of the activities that we have referred to as software
quality assurance (SQA).
Verification and validation encompasses a wide array of SQA activities that include formal
technical reviews, quality and configuration audits, performance monitoring, simulation,
feasibility study, documentation review, database review, algorithm analysis, development
testing, qualification testing, and installation testing.

8. UNIT-I
CS E71 SQA & TESTING Page 8
Quality is incorporated into software throughout the process of software engineering. Proper
application of methods and tools, effective formal technical reviews, and solid management
and measurement all lead to quality that is confirmed during testing.
Miller relates software testing to quality assurance by stating that "the underlying motivation
of program testing is to affirm software quality with methods that can be economically and
effectively applied to both large-scale and small-scale systems.
LEVELS OF SOFTWARE TESTING
Software Testing is carried out at different levels throughout the entire software
development life cycle.
Each and every component should be tested functionally and structurally.
Testing is essential during the integration of software components to ensure that each
combination of component is satisfactory.
System and acceptance testing are then followed.
The IEEE standard on software verification and validation identifies four levels of
testing.
TYPES OF SOFTWARE TESTING
Unit test:
In this phase, each unit is separately tested, and changes are done to remove the defects
found. Since each unit is relatively small and can be tested independently, they can be exercised
much more thoroughly than a large program.
Customer
Requirements
Acceptance Testing
Requirements System Testing
High level design Integration Testing
Detalied Design Component Testing

9. UNIT-I
CS E71 SQA & TESTING Page 9
Integration testing:
During integration, the units are gradually assembled and partially assembled subsystems
are tested. Testing subsystems allows the interface among modules to be tested. By
incrementally adding units to a subsystem, the unit responsible for a failure can be identified
more easily.
System testing:
The system as a whole is exercised during system testing. Debugging is continued until
some exit criterion is satisfied. The objective of this phase is to find defects as fast as possible. In
general the input mix may not represent what would be encountered during actual operation.
Acceptance testing:
The purpose of this test phase is to assess the system reliability and performance in the
operational environment. This requires collecting (or estimating) information about how the
actual users would use the system. This is also called alpha-testing. This is often followed by
beta-testing, which involves actual use by the users.
Regression testing:
When significant additions or modifications are made to an existing version,regression
testing is done on the new or "build" version to ensure that it still works and has not "regressed"
to lower reliability.
Unit Testing
This type of testing is performed by the developers before the setup is handed over to the testing
team to formally execute the test cases. Unit testing is performed by the respective developers on
the individual units of source code assigned areas. The developers use test data that is separate
from the test data of the quality assurance team.
The goal of unit testing is to isolate each part of the program and show that individual parts are
correct in terms of requirements and functionality.
Limitations of Unit Testing
Testing cannot catch each and every bug in an application. It is impossible to evaluate every
execution path in every software application. The same is the case with unit testing.
There is a limit to the number of scenarios and test data that the developer can use to verify the
source code. So after he has exhausted all options there is no choice but to stop unit testing and
merge the code segment with other units.

10. UNIT-I
CS E71 SQA & TESTING Page 10
System Testing
This is the next level in the testing and tests the system as a whole. Once all the components are
integrated, the application as a whole is tested rigorously to see that it meets Quality Standards.
This type of testing is performed by a specialized testing team.
System testing is so important because of the following reasons:
System Testing is the first step in the Software Development Life Cycle, where the
application is tested as a whole.
The application is tested thoroughly to verify that it meets the functional and technical
specifications.
The application is tested in an environment which is very close to the production
environment where the application will be deployed.
System Testing enables us to test, verify and validate both the business requirements as
well as the Applications Architecture.
Integration Testing
The testing of combined parts of an application to determine if they function correctly together is
Integration testing. There are two methods of doing Integration Testing Bottom-up Integration
testing and Top Down Integration testing.
S.N. Integration Testing Method
1 Bottom-up integration
This testing begins with unit testing, followed by tests of progressively higher-level
combinations of units called modules or builds.
2 Top-Down integration
This testing, the highest-level modules are tested first and progressively lower-level
modules are tested after that.
In a comprehensive software development environment, bottom-up testing is usually done first,
followed by top-down testing. The process concludes with multiple tests of the complete
application, preferably in scenarios designed to mimic those it will encounter in customers'
computers, systems and network.
TYPES OF SOFTWARE TESTING
There are different methods which can be use for Software testing. This chapter briefly
describes those methods.
Black Box Testing

11. UNIT-I
CS E71 SQA & TESTING Page 11
The technique of testing without having any knowledge of the interior workings of the
application is Black Box testing. The tester is oblivious to the system architecture and does not
have access to the source code.
Typically, when performing a black box test, a tester will interact with the system's user
interface by providing inputs and examining outputs without knowing how and where the inputs
are worked upon.
Advantages Disadvantages
Well suited and efficient for large code
segments.
Code Access not required.
Clearly separates user's perspective
from the developer's perspective
through visibly defined roles.
Large numbers of moderately skilled
testers can test the application with no
knowledge of implementation,
programming language or operating
systems.
Limited Coverage since only a selected
number of test scenarios are actually
performed.
Inefficient testing, due to the fact that
the tester only has limited knowledge
about an application.
Blind Coverage, since the tester cannot
target specific code segments or error
prone areas.
The test cases are difficult to design.
White Box Testing
White box testing is the detailed investigation of internal logic and structure of the code. White
box testing is also called glass testing or open box testing. In order to perform white box testing
on an application, the tester needs to possess knowledge of the internal working of the code.
The tester needs to have a look inside the source code and find out which unit/chunk of the code
is behaving inappropriately.
Advantages Disadvantages
As the tester has knowledge of the
source code, it becomes very easy to
find out which type of data can help in
testing the application effectively.
It helps in optimizing the code.
Extra lines of code can be removed
which can bring in hidden defects.
Due to the tester's knowledge about the
code, maximum coverage is attained
during test scenario writing.
Due to the fact that a skilled tester is
needed to perform white box testing,
the costs are increased.
Sometimes it is impossible to look into
every nook and corner to find out
hidden errors that may create problems
as many paths will go untested.
It is difficult to maintain white box
testing as the use of specialized tools
like code analyzers and debugging tools
are required.
Grey Box Testing

12. UNIT-I
CS E71 SQA & TESTING Page 12
Grey Box testing is a technique to test the application with limited knowledge of the internal
workings of an application. In software testing, the term the more you know the better carries a
lot of weight when testing an application.Mastering the domain of a system always gives the
tester an edge over someone with limited domain knowledge. Unlike black box testing, where
the tester only tests the application's user interface, in grey box testing, the tester has access to
design documents and the database. Having this knowledge, the tester is able to better prepare
test data and test scenarios when making the test plan.
Advantages Disadvantages
Offers combined benefits of black box
and white box testing wherever
possible.
Grey box testers don't rely on the
source code; instead they rely on
interface definition and functional
specifications.
Based on the limited information
available, a grey box tester can design
excellent test scenarios especially
around communication protocols and
data type handling.
The test is done from the point of view
of the user and not the designer.
Since the access to source code is not
available, the ability to go over the code
and test coverage is limited.
The tests can be redundant if the
software designer has already run a test
case.
Testing every possible input stream is
unrealistic because it would take an
unreasonable amount of time; therefore,
many program paths will go untested.
Black Box Vs Grey Box Vs White Box Testing
S.N. Black Box Testing Grey Box Testing White Box Testing
1 The Internal Workings of an
application are not required
to be known
Somewhat knowledge of the
internal workings are known
Tester has full knowledge
of the Internal workings of
the application
2 Also known as closed box
testing, data driven testing
and functional testing
Another term for grey box
testing is translucent testing
as the tester has limited
knowledge of the insides of
the application
Also known as clear box
testing, structural testing or
code based testing
3 Performed by end users and
also by testers and
developers
Performed by end users and
also by testers and
developers
Normally done by testers
and developers
4 Testing is based on external
expectations - Internal
behavior of the application
is unknown
Testing is done on the basis
of high level database
diagrams and data flow
diagrams
Internal workings are fully
known and the tester can
design test data accordingly
5 This is the least time
consuming and exhaustive
Partly time consuming and
exhaustive
The most exhaustive and
time consuming type of
testing

13. UNIT-I
CS E71 SQA & TESTING Page 13
6 Not suited to algorithm
testing
Not suited to algorithm
testing
Suited for algorithm testing
7 This can only be done by
trial and error method
Data domains and Internal
boundaries can be tested, if
known
Data domains and Internal
boundaries can be better
tested
WEYUKER'S ADEQUACY AXIOMS
An established principle; a self-evident truth (Concise Oxford). Choice of this term may
have been unfortunate.
(1) If the adequate test set is infinite (or even very large) it would be impossible to satisfy the
criterion. Weyuker does not explore the definition of “very large” any further.
(2) Exhaustive testing (testing every point in the domain) can be assumed to be adequate. An
important part of testing is identifying a subset of the test domain which represents the whole
domain.
3) The addition of more test cases to an already adequate set does not make it inadequate.
Therefore, the subset of the domain does not have to be the smallest possible subset. In some
instances a larger subset might be easier to identify.
(4) A program cannot be assumed to be adequate if it has not been tested at all.
Dynamic testing assumes that the program has at least one input.
(5) These axioms support program-based testing, not functionality or specification-based testing.
Therefore, two programs which perform the same function but are implemented differently
would require different test sets.
(6) Programs with the same shape (structure) may require different data sets to traverse their
structure.
The program P taken as a whole may not be able to stimulate all possible actions of component
Q. Q must be tested in its own right.
Example: component Q could be a sorting routine. What if program P always provides data
already sorted?
Testing must take into account the added complexity and interaction which occurs when two
programs are composed. Hence the traditional need for integration testing.