Quality

Quality means satisfaction of the customer to define good quality of Software, the
company people will concentrate on two (2) factors such as 1) Technical factor and
2) Non-technical factor.

1. Technical factor

a. Customer requirements in terms of functionalities.

b. Customer expectations (Look and feel, Ease of use, right output, speed of
processing, security)

2. Non-technical factor

a. Low cost to purchase

b. Time to market.

S.Q.A (Software Quality Assurance)

It means monitoring and measuring the strength of development process.

REQUIREMENTS GATHERINGS

Business Development People / Business Analyst

Business Requirement Specification (BRS) / User Requirement Specification (URS) / Customer

Requirement Specification CRS

FRS (Functional Requirement

Specification)
ANALYSIS – Analyst (Software Requirement
Specification)
SRS (System Requirement Specification)

HLD (High Level Design Document)

DESIGN – Designers (Design Document)
LLD (Low Level Design Document)

CODING (Programmers)

TESTING (Testers)

PROJECT MANAGEMENT (Release and

Maintenance)
1) REQUIREMENT GATHERINGS

In general software development starts with requirement gathering. In this stage

Business Development People (BDP) / Business Analyst People (BA)are preparing
Business Requirement Specification Document (BRS) / User Requirement
Specification Document (URS) / Customer Requirement Specification Document
(CRS), after gathering all required requirements from the user / customer. Business
Requirement Specification Document defines the requirement of the customer.

2) ANALYSIS

After completion of Business Requirement Specification Document , Analyst People

are preparing “Analysis Document”. This document is also called as “Software
Requirement Specification Document” (S/w RS). The document consists of (2) Sub
documents such as FRS & SRS

(i) FRS - It means “Function Requirement Specification”. It defines the required

functionality to be used in the project.

(ii) SRS - It means “System Requirement Specification”. It defines the required

Hardware to develop that functionality.

3) DESIGN

After completion of Analysis Document, Designers are preparing Design Document.

It consists of (2) sub documents, such as (i) HLD & (ii) LLD

(i) HLD (High Level Design Document)

It is also called as External Design Document. It defines the hierarchy of overall

application functionalities in terms of modules from root level to leaf level.
(ii) LLD (Low Level Design Document)

It is also known as Internal Design Document. It defines the internal logic of every
functionality or module in terms of ER Diagrams, Data Flow Diagrams.

Note: A Project will have one HLD and Multiple LLDs

4) CODING

A Physical construction of Software is called as “Coding”.

Build: An executable form of all integrated module set is called “Build”.

5) TESTING

In this stage, the testers are validating that developed Build with respective
Customer requirements and customer expectations.

6) RELEASE AND MAINTENANCE

After completion of software testing the Project Management will deliver that
software to customer for usage. During utilization of the software, if customer get
any problem or if customer want to enhance the application, that can be handled by
the company people.

Q1. What is the difference between Software Product and Software

Application?

Answer:

Software Application

If the Software developed with respective particular client requirements or single

client requirements that can be called as Software Application. Ex: Bank
Applications, Hospital Applications.

Software Product

If the Software developed with respective multiple clients requirements, that can be
called as Software Product. Ex: MS Office, VB, Operating System etc.
Q2. What is Error, Defect, Bug?

Answer:

Error: Any mistake in a programme is called “Error”.

Defect: Any mistake found by the tester during Testing can be called as “Defect”.

Bug: The reported defect is accepted by developer to resolve can be called as

“Bug”.

Q3. SQC (Software Quality Control)?

Answer: It is a process of validating the Software.

Q4. Why Software has Bugs?

(i) Poor requirements

(ii) Futurities (Customers requirements are frequently changing)

(iii) Miscellaneous Communication.

(iv) Unrealistic schedule

(v) Inadequate testing.

Solutions

(i) Solid requirements

(ii) Good communication

(iii) Realistic schedule

(iv) Adequate testing

(v) Gather / Stick to initial requirements as much as possible.

 TESTING MODELS
FISH MODEL

Fish model defines the mapping between development stages and Testing

Diagram\
Reviews in Analysis

In general Software Development process starts with requirements gathering and

analysis. In this, Business Development People are preparing Business Requirement
Specification Document and Analyst people are preparing Analysis Document with
respective to Business Requirement Specification. After completion of analysis
document, the same category people conducting reviews in Analysis Document for
completeness and correctness. During the review they are concentrate on the
below factors.

i) Are they complete?

ii) Are they right requirement?

iii) Are they achievable?

iv) Are they reasonable?

v) Are they testable?

Reviews in Design Document

After completion of Analysis document and corresponding reviews , designers are

preparing design document which includes Functional Requirement Specifications
and System Requirement Specifications .After completion of design document the
same category people are conducting reviews in design document for completeness
and correctness. During the review they concentrate on below factors.

1)Are they complete

2)Are they met right requirements?
3)Are they understandable?
4) Does they handle Errors or not?

White Box Testing

After completion of deign document and correspondence reviews , programs with
concentrate on coding to construct a Software Build. After completion of preparing
all programs, Programmers are interconnecting them to a system. In this
interconnection of programs to verify the programs and interface between
programs or modules, programmers are conducting “White Box Testing ”White Box
Testing classified as Two Types such as (I) Unit Testing(II) Integration Testing.

Unit Testing
It is also called as Program Testing or Micro Testing. Unit testing means “Single
Program Testing or Component Testing. Unit testing consists of below factors.
a)Basic Path Testing.
During this testing programmers are checking that whether the program is running
or not? To perform this test they will follow below approach.
1)Draw flow diagram of that program.
2)Calculate number of independent paths in that program (Cyclometic Complexity)
(The number of independent paths in the program)
3)Execute the program more that one time to cover all independent paths in that
program.
b)Control Structure Testing
In this testing the programmers will concentrate on corresponding program output.
In this programmers will concentrate on every statement including, If conditions,
For loops, Memory allocation etc.,
c)Program Technique Testing
In this testing the programmers are checking the execution speed of the program. If
the execution speed of the program is not good, then programmers are performing
changes in the structure of the program without disturbing functionality.
d)Mutation Testing
Mutation means changes in a program. In this testing programmers are performing
wanted changes in the program and executing the program repeatedly. In this Test
repetition

Programmers are checking the completeness and correctness of the Test.

II)Integration Testing
After completion of dependent program development and corresponding Unit
Testing, Programmers are interconnecting to forma system. To estimate the
 interface between programs or modules programmers are conducting Integration
Testing. They are (4) Types of approaches.
main modul
a)Top-Down Approach.
The verification of main module without coming to some of the Sub-Modules is
called as Top-Down Approach.“Conduct test on Main module without conducting
test on some of the Sub-Modules is called Top-Down Approach.”
Stub

Sub Modul-1 Sub Modul-2 Sub Modul-3

Temporary Program/ Called

Program

In the above approach “STUB” is a Temporary Program, it works like as under

constructive Sub Module, it is also called as Called Program.
b)Bottom-Up Approach.
The verification of Sub-Modules without coming from Main Module is called “Bottom-
Up” Approach.“Conducting
Main Modul test on Sub-Modules without testing on Main Module is
called Bottom-up Approach.

Driver/Calling Program

Sub-Modul-1 Sub-Modul-2 Sub-Modul-3

In the above approach “Driver” is temporary program, it works like as under

constructive Main Module. Driver is also known as Calling Program.
 Main Module
c)Hybrid Approach / Sand-witch Approach

The combination of Top-down Approach and Bottom-Up Approach is called as Hybrid

Approach / Sand-witch approach
Driver/Calling
Program

Sub-Module-1 Sub-Module-2 Sub-Module-3

Bottom-Up
Approach

Stub

Sub-Sub- Sub-Sub- Sub-Sub-

Module-3 Modul-2 Module-3

Top-Down
Approach

d)Big bang Approach.

The verification of all modules after completion of all Modules development and
corresponding unit testing is called as “Big bang Approach”. This approach is not
suitable for large modules.

CASE STUDY

Case 1: Top-down approach is follow able, when the customer’s requirements are
constituent of clear.
Case 2: Bottom-up approach is follow able, when the customer’s requirements are
not clear or frequently changing.
Case 3: Hybrid Approach is follow able, when the customer’s requirements are clear
and the architecture structure of the system is changing.
Case 4: Big bang Approach is follow able, when the application build consists less
number of modules or less number of interconnections

BLACK BOX TESTING

After completion integration of all modules to form a system, developers are
sending that build to the separate Testing team. This separate testing team
validates the Software build with respective customer’s requirements and
expectations through “Black Box Testing” techniques. It is also known as “Close Box
Testing” / “Functional & System Testing” It is classified as (3) types such as
1)Usability Testing.
a. User Interface Testing.
b. Manual Support Testing.
2)Functional Testing.
a. Functionality Testing.
b. Sanitation Testing.
3)Non-Functional Testing.
a. Recovery Testing.
b. Compatibility Testing
c. Configuration Testing.
d. Intersystem Testing
e. Comparative Testing
f. Security Testing.
g. Installation Testing.
h. Load Testing.
i. Stress Testing
j. Data Volume Testing.
k.Storage Testing.

1) Usability Testing
After receiving build from the development people, testers are conducting usability
testing to check whether the application build is providing user friendly screens or
not. Usability Testing is classified into (2) Types such as
(a) User Interface Testing
(2) Manual Support Testing
a. User Interface Testing

During this testing testers are checking the Look and Feel, Ease of use of
application of build screen.
Ex: The Microsoft (6) Rules for testing
1) Controls are in it caps.
2) Ok, Cancel existence.
3) System Menu existence.
4) Controls are not overlapped
5) Controls should be visible.
6) Controls must be aligned.
b. Manual Support Testing
It is also known as “Help document Testing”. During this testing Testers are
checking the context sensitiveness testing. Ex: Spelling Mistakes, Grammar
mistakes, Word Missing, Line Missing etc. ,Case 1: Receive build from the
developers.

User interface testing.

Functional & Non-Functional Testing

Manual Support Testing.

2) Functional Testing
After completion of User Interface testing, Testers are conducting Functional Testing
to validate customer requirements. Functional Testing classified into (2) Types (a)
Functionality Testing (b) Sanitation Testing.
a) Functionality Testing
During this Testing Testers are validating customers requirement in terms of
(6) coverage.
1) Behavioral Coverage.
2) Input Domain Coverage.
3) Error-Handling Coverage.
4) Calculation Coverage.
5) Back-end Coverage.
6)Service level Coverage.

1) Behavioral Coverage.
In this testing Testers are checking whether the objects are properly responding of
not, with respective to Business Operation.
2) Input Domain Coverage
In this testing Testers are checking whether the input objects /Input fields are taking
right type and range of value or not. To perform this test we (Testers) are using
(2) Types of Testing.
(a)BVA (Boundary Value Analysis)
(b)ECP (Equivalence Class Partitioning)
BVA(RANGE OF OBJECT)

RANGE EXPECTED
ACTUAL RESULT

Min= Pass

Min-1= Fail

Min+1= Pass

Max= Pass

Max-1= Pass
 ECP(Defines Type Of Object)

Valid Invalid

Pass Fail

Ex: A Login process allows User Name and Password from a User. In this User Name
object allows “Alphabets lower case” Range from 4 to 8Characters long and
Password object allows “Alphabets lower case” range from 6 to 10 Characters long.
Prepare BVA and ECP for the above expected.

BVA & ECP for User Name

BVA ECP

RANGE EXPECT ACTUAL RESULT VALID INVALID

ED
[A-Z] [A-Z]
Min=4c Pass
[0-9]
har
ALL
Min- Fail
1=3cha SPECIAL
r
CHARACTE
Min+1= Pass R
5 Char

Max= 8 Pass
Char

Max-1= Pass
7 Char
BVA & ECP for Age

EX: Age object allows numeric range from 16 to 60.Prepare BVA and ECP for the
above expected.

BVA

RANGE EXPECT ACTUAL RESULT

ED ECP
Min=16 Pass
VALID INVALID
Min- Fail
[ 0-9] [A-Z]
1=15
[ a-z]
Min+1= Pass ALL
17
SPECIAL
Max= Pass
60 CHARACTE
R
Max-1= Pass
59

Min+1= Fail
61 EX: Mobile No. object allows numeric
10digits only. Prepare BVA and ECP
for the above expected.

BVA & ECP for Mobile No.

BVA
ECP
RANGE EXPECT ACTUA RESULT
VALID INVALID
ED L

Max=10 Pass [ 0-9] [A-Z]

[ a-z]
Max- Fail
1=9 ALL
Max+1 Fail CHARACTER
=11
3)ErrorError-Handling Coverage.

In this we are checking whether the objects are preventing “Negative Operations”
or not.

4) Calculation Coverage

In this we are checking whether the functionality output is right or wrong.

5) Back-End Coverage.

In this testing we are checking whether the insert of front end operations on back
end table context.

6) Service level coverage.

The order functionality.

b) Sanitation Testing
It is also known as “Garbage Testing”. During this testing , testers are finding extra
functionalities in the build with respect to customer requirements.
3)Non-Functional Testing

After completion of Functional Testing, testers are concentrating on Non-Functional

Testing to validate extra characteristics of that build. They are divided into (11)
Types.
a) Recovery Testing
During this testing we are checking that whether the application Build is changing
from Abnormal State (Crash / Hang) to Normal State or not. Abnormal State to
Normal State

Abnormal State to Normal State

b)Compatibility Testing
They are (2) types of Compatibility Testing.
During this testing we are checking whether the application build is able to run on
different platforms or not. Platform means Operating System, Browsers, compilers
and other System software’s.

During this testing we are checking whether the application build is able to run on
different platforms or not. Platform means Operating System, Browsers, compilers
and other System software’s.

c) Configuration Testing

It is also known as “Hardware Compatibility Testing”. During this testing we are

validating whether the application build is supporting different technologies input /
Output devises or not.
d) Intersystem Testing.
It is also known as “Inter operability Testing”. During this testing we are checking
whether the application build is coexistence with other existence to share common
resource or not

e) Comparative Testing.
It is also known as “Competitive Testing”. During this testing we are comparing the
features of produce with some like previous produce (or) Existing produce in the
market to estimate competitiveness.
f)Security Testing.
 It is also known as “Penetration Testing”. During this testing we are validating (3)
types of factors such as
(i) Authorization.
(ii) Access Control.
(iii)Encrypt / Decrypt Data Testing.
(i) Authorization.
In this testers are checking whether a valid user is accessible or not, invalid user is
preventable or not.
(ii)Access Control
In this we are checking whether a valid user have permission to use specific
features / Services or not
iii) Encrypt / Decrypt Data Testing.

The code conversion in between client process and server process to avoid third
party accessing.

g) Installation Testing
It is also known as “Deploying Testing”.During this testing we are validating below
factors.

Build and Customer

Supported Expected
S/W Configure
Computer

h) Load Testing.
Run the application under customer expected configuration under customer load to
estimate the speed of processing is called “Load Testing”.
i) Stress Testing.
Run the application under customer expected configuration under various loads
from low to peak to estimate Stress capacity of the application build is called Stress
Testing.
j)Storage Testing.
The execution of application build under customer expected configuration under
huge amount of resources to estimate the storage capacity of the application
database is called Storage Testing.
k)Data Volume Testing.
During this testing Testers are calculating the number of records to be stored into
application database.
 GRAY BOX TESTING
Gray Box Testing is a combination of “White Box Testing” and Black Box Testing.
UAT (User Acceptance Test)
After completion of Software Testing, the Project Management / Project Manager will
invite customer to collect feedback on one developed software
They are (2) types such as

Α - Test B-Test
(ALFA TEST) (BETA TEST)

Software Application Software Product.

By Real customer By Model customer.
At development site At customer site

Release
Testing

It is also known as “Port Testing”. After completion of User Acceptance Test” and
corresponding modifications, the Project Management will establish Release Team
with few Developers, few Testers and One (or) two Hardware Engineers. This
release team will go to customer’s site to install the software on the customer’s
environment. During this they will concentrate on below factors.
a). Compact Installation.
b). Overall functionality.
c). Input device handling.
d). Output device handling.
e).OS Error handling.
d).Secondary storage handling.
e).Coexistence with other existence software.

After completion of above like factor observation the release team is providing
required training sessions to the customers to understand about the project.

Maintenance

During utilization of Software by customers, the company people are receiving

change request from them. To receive change request from the customers the
Project Management establish “CCB” (Change Control Board) with few Developers,
few testers and Project Manager.
CASE STUDY

Challenges in Testing

Generally organizations are maintaining separate Testing for Functional and System
Testing. This separate Testing team is also involving in Release Team and CCB.
Some time this separate Testing team is also not able to conduct planned Testing
or good testing due to some risks
The risks are
1. Lack of knowledge on project domain.
2. Lack of communication.
3. Lack of resources.
4. Lack of time.
5. Lack of Test Data. To overcome above like risks, the people are following “Ad-
hoc” Testing.
Planned Testing
A Tester conduct Test on application build with pre-planned procedure is called
Planned Testing
.(or)A Tester conduct Test on application build by following formal methods are
called
Planned Testing
.
Ad-hoc Testing
A Tester conduct test on application build without Pre-planed is called
Ad-hoc Testing
.(or)A Tester conduct test on application build by following “Informal Methods” is
called “
Ad-hoc Testing
”.They are classified as (4) Types.
(a)Monkey Testing.
Due to lack of time, Testers are conducting test on major functionalities of the
application build. This style of testing is called“
Monkey Testing
”. It is also known as Cheapening Testing.
(b)Buddy Testing.
Due lack of time, Testers are grouping with programmers to conduct Test on
application as early as possible. This style of Testing is called as
Buddy Testing
.Buddy means a group of Programmers and Testers.

(c) Pair Testing.

Due to lack of knowledge on domain Junior Testers grouped with Senior Testers to
share their knowledge. This style of testing is called
Pair Testing
.(d) Exploratory Testing
.Due to lack of Test Data, Testers are conducting Test on application depending on
available documents, discussions with other and get the requirements from
customers. This style of testing called
Exploratory Testing.

SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC)

1) WATER FALL MODEL

In this Model next stage starts after completion of previous stage.
There is no overlapping between two stages.
ADVANTAGES

i) it is less expensive.
ii)It works well for small applications.
iii)It is flexible when the customer requirements are constant.
DISADVANTAGES

i)Testing is a single stage starts after coding.

ii)If any defect is found during Testing, the rectification of that defect would be
difficult.
iii)It is “not flexible” to have changes in the customer requirements during
developing the software.

2) INCREMENTAL WATER FALL MODEL

To overcome some of the limitations of Waterfall we can use Incremental Waterfall

model.
Incremental Waterfall Model can be used Software Produce Development.
In this Model a set of requirements they would be one working product.
3) PROTOTYPE MODEL

It is follow able when the customer requirements are not clear. “Prototype means a
sample Model of application without functionality.

ADVANTAGES

i)It is flexible when the customer requirements are not clear.

DISADVANTAGES
i)It is expensive

4) Spiral Model
Spiral Model is follow able when the customer requirements are enhance able in
terms of versions.
n this Model we will start the process within complete requirements.
ADVANTAGES
it is flexible for high risk based projects.

DISADVANTAGES
It is expensive.

5) V-MODEL

Like as Fish Model “V-Model” is also defines the mapping between Development
stages and Testing stages. In V-Model V stands for “Verification and Validation”.
Verification
To check whether the people are developing right product or not.
Validation
To check whether the developed product is right or not.
Software Testing
The “Verification and Validation” of a Software is called Software Testing.
6) Agile Model
It is a latest model which is used in Software produce development.
In this model we can get build from the developers in very short time (1to 4 Weeks)
In this model development process, testing process will be carried out
parallelly. They are (2) methods such as (a)

X-Tream Programming.
(b)Scrum
ADVANTAGES

Any defect identified early, so that he rectification of the defect cost and time would
be very less.
ii) As the defect is identified early, the impact of the same defect is very less on
subsequent features.

DISADVANTAGES

i) Documentation is very less.

Smoke Testing
Like as Sanity Testing, Smoke Testing is also used to estimate the stability of the
Build.
Sanity Testing
After receiving the build from the developers we people are conducting “Sanity
Testing” to estimate stability of that build before start real testing. During this
testing we will be concentrate on below factors.
a) Understandable.
b) Operatable.
c) Observable.
d)Controllable.
e)Consistency.
f)Automatable.
g)Maintainable
h)Simplicity. From the above
(8) factors, Sanity Testing is also known as Build Verification Testing (BVT) or
Tester Acceptance Testing (TAT) or Testability Testing or Oct-angle Testing.

Re-Testing.
Case 1: The repeating of same test for more than one time with multiple data is
called as “Re-Testing”. Case 2: The re-execution of failed tests on modified build to
ensure bug fixing work is called “Re-Testing”
Regression Testing.
The Re-execution of selected test or modified build, to check is there any side
effects occurred or not on dependent functionalities by modifying report add effects
or by adding new requirements.

Types of Build
They are (7) types of Build. They are
(1) Initial Build
(2) Stable Build
(3) Defect effected Build
(4) Modified Build
(5) Complete Build
(6) Master Build
(7) Golden Build

Types of Projects
Mainly there are (3) Types of projects. They are
(1) Traditional Project
(2) Outsourcing Project
(3) Maintenance Project
MANUAL TESTING