Testing Tools (Manual)

suresh_240878@yahoo.com Suresh.
B –9440163282
Jai Sri Ram Jai Sai Ram

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
ANALYSIS
Specification
Analyst
Software Requirement Specification (S/W RS) SRS
System Requirement
Specification
HLD
DESIGN
High Level Design Document
Designers
Design Document LLD
Low Level Design Document
CODING
Programmers
TESTING
Testers
PROJECT MANAGEMENT
Release and Maintenance
Manual Testing 1

Suresh.B –9440163282 suresh_240878@yahoo.com
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 over all application functionalities in terms of modules
from root level to leaf level.
Ex: Login
Mail Chat
Logout
2 Manual Testing
suresh_240878@yahoo.com Suresh.B –9440163282
(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. V - Valid
LOGIN IV - Invalid
User Name V V IV IV
Password V IV V IV
MESSAGE BOX OK CANCEL

Please Try Again
OK
DATA
BASE
INBOX
Note: A Project will have one HLD and Multiple LLDs.

4) CODING:
A Physical construction of Software is called as “Coding”.
System
M1 M2 M3
S1 S2 S3 BUILD
SS1 SS2 SS3
P1 P2 P3
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.
Manual Testing 3

What is the difference between Software Product and Software

Application?
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.,
What is Error, Defect, Bug?

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”.
SQC (Software Quality Control)

It is a process of validating the Software.
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.
4 Manual Testing
TESTING MODELS
FISH MODEL
Fish model defines the mapping between development stages and Testing
stages.
S/W RS (FRS & SRS) Design Release &
Analysis (HLD & LLD) Coding
Black Box Maintenance
Testing /
Functional &
Requirements System Testing
Gathering / Close Box
BRS / CRS / Testing
URS
Verification Validation
Reviews in White Box Testing / Test Software

Reviews in
Analysis Glass Box Testing / Changes
Design
Programe Phase
Testing / Open Box
Testing
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.
Manual Testing 5

i) Are they complete/

ii) Are they met right requirements?
iii) Are they understandable?
iv) 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.
(I) 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,
6 Manual Testing
Programmers are checking the completeness and correctness of the

Test.
A=10 A=10
B=20 B=20
C=A+B I=A+B Perform change
msgbox I C=I
msgbox I
Passed Passed Failed

(In-compete (Complete
Testing) Testing)
(II) Integration Testing
After completion of dependent program development and
corresponding Unit Testing, Programmers are interconnecting to form
a system. To estimate the interface between programs or modules
programmers are conducting Integration Testing. They are (4) Types
of approaches.
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.”
Main Module
STUB Temporary Program

/ Called Program
Sub-Module-1 Sub-Module-2 Sub-Module-3

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 test on Sub-Modules without testing on Main
Module is called Bottom-up Approach.
Main Module
Driver / Calling Program

In the above approach “Driver” is temporary program, it
works like as under constructive Main Module. Driver is also
known as Calling Program.
Manual Testing 7

c) Hybrid Approach / Sand-witch Approach

The combination of Top-down Approach and Bottom-Up
Approach is called as Hybrid Approach / Sand-witch approach.
Main Module
Driver / Calling Program Bottom-Up
Approach
STUB Top-Down
Approach
Sub-Sub-Module-1 Sub-Sub-Module-2 Sub-Sub-Module-3
d) Bigbang Approach.
The verification of all modules after completion of all
Modules development and corresponding unit testing is called as
“Bigbang Approach”.
This approach is not suitable for large modules.
CASE STUDY
Case 1: Top-down approach is followable, when the customer’s

requirements are constituent of clear.
Case 2: Bottom-up approach is followable, when the customer’s

requirements are not clear or frequently changing.
Case 3: Hybrid Approach is followable, when the customer’s requirements

are clear and the architecture structure of the system is changing.
Case 4: Bigbang Approach is followable, when the application build

consists less number of modules or less number of
interconnections.
8 Manual Testing
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 initcaps.
2) Ok, Cancel existence.
3) System Menu existence.
4) Controls are not overlapped.
5) Controls should be visible.
6) Controls must be aligned.
Manual Testing 9

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.
Usability
Functional & Non-Functional Testing
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) Behavioural Coverage.
2) Input Domain Coverage.
3) Error-Handling Coverage.
4) Calculation Coverage.
5) Back-end Coverage.
6) Service level Coverage.
1) Behavioural 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.
(i) BVA (Boundary Value Analysis
(ii) ECP (Equivalence Class Partitioning)
BVA ECP
(Range of Object) (Defines Type of Object)
Range Expected Actual Result Valid Invalid
Min= Pass
Min-1= Fail
Min+1= Pass
Pass fail
Max= Pass
Max-1= Pass
Max+1= Fail
10 Manual Testing
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 8
Characters 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
Min= 4 Char Pass [a-z] [A-Z]
Min-1= 3 Char Fail [0-9]
Min+1= 5 Char Pass All
Max= 8 Char Pass Special
Max-1= 7 Char Pass characters
Max+1= 9 Char Fail
BVA & ECP for Password

BVA ECP
Max+1= 11 Char Fail
Ex: Age object allows numeric range from 16 to 60.

Prepare BVA and ECP for the above expected.
BVA & ECP for Age

BVA ECP
Min= 16 Pass [0-9] [A-Z]
Min-1= 15 Fail [a-z]
Min+1= 17 Pass All
Max= 60 Pass Special
Max-1= 59 Pass characters
Max+1= 61 Fail
Manual Testing 11

Ex: Mobile No. object allows numeric 10

digits only. Prepare BVA and ECP for
the above expected.
BVA & ECP for Mobile No.

BVA ECP
Max= 10 Pass [0-9] [A-Z]
Max-1= 9 Fail [a-z]
Max+1= 11 Fail All Special characters
3) Error-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.
ODBC
JDBC
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.
12 Manual Testing
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
Normal State
Abnormal State
b) Compatibility Testing
They are (2) types of Compatibility Testing.
Build O.S Build O.S
V.B Unix VC++ Win98
Ex: Unix does not support VB Æ Win98 is supporting VC++

Techniques Æ But Build is not working
Properly due to defects
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.
Manual Testing 13

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.
Ex.: E-Seva.
Elec. Bill Server
Telephone Bill Server
Water Tax Bill Common Data Server

Base
Income Tax Bill Server
Municipal Bill Server
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.
Note: Comparative Testing is applicable for Software Produces only
not for applications, because Software application is developed
for a single client requirement, but product can be developed with
respect to multiple clients requirements.
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.
14 Manual Testing
(iii) Encrypt / Decrypt Data Testing.

The code conversion in between client process and server
process to avoid third party accessing.
CLIENT
User Name SERVER
Password
Request Decrypt
Encrypt
Cipher Text
Request
Decrypt
Encrypt
Cipher Text
g) Installation Testing
It is also known as “Deploying Testing”. During this testing we
are validating below factors.
Build Customer Æ Setup Program.

& Supported expected Æ Easy Navigation.
Software configure Æ Occupied Disk Space.
Computer Æ Check Un-installation.
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.
Note: Storage Testing, Data volume Testing coverages same, but Storage
Testing is representing in Number of bytes and Data Volume Testing
is representing number of Records.
Manual Testing 15

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 β – 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
ion the customer’s environment.
During this they will concentrate on below factors.

Î Compact Installation.
Î Overall functionality.
Î Input device handling.
Î Output device handling.
Î OS Error handling.
Î Secondary storage handling.
Î 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.
16 Manual Testing
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.
CCB
Receive change
Enhancement Missed Defect
Impact Analysis
Impact Analysis
Perform changes
Perform changes Test S/w changes
Increase Testing
Test S/w changes process Capability
CASE STUDY
TESTING STAGES RESPONSIBLE PERSONS
Review in Analysis Analyst
Review in Design Designer
Unit Testing Programmers
Integration Testing Programmers
Functional & System Testing Test Engineers / Testers
User Acceptance Testing Users / Customers
Release Testing / Port Testing CCB
TERMINOLOGY
DEVELOPERS TESTERS
Input Test Data
Output Test Log
Program Test Script
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.
Manual Testing 17

The risks are

Î Lack of knowledge on project domain.
Î Lack of communication.
Î Lack of resources.
Î Lack of time.
Î 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.
18 Manual Testing
SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC)

1) WATERFALL MODEL
Requirement Gathering
Analysis
Design
Coding
Testing
Release &
Maintenance
Î 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 WATERFALL 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.
1.0
R.G Analysis Design Coding Testing R&M
2.0
3.0
Manual Testing 19

3) PROTOTYPE MODEL
It is followable when the customer requirements are not clear.
“Prototype means a sample Model of application without
functionality.
Not Clear
Hardware Prototype Software Prototype
Demo to Client
Finalize Environment Requirements refined
SRS Base lined BRS Base lined

ADVANTAGES
i) It is flexible when the customer requirements are not clear.
DISADVANTAGES
i) It is expensive
4) Spiral Model
Î Spiral Model is followable when the customer requirements are
enhanceble in terms of versions.
Î In this Model we will start the process within complete requirements.
Planning Risk Analysis
Requirement
Gathering
5.0 4.0 3.0 2.0 1.0
Customer Coding and

Evaluation Testing
Evaluation Engineers
ADVANTAGES
It is flexible for high risk based projects.
DISADVANTAGES
It is expensive.
20 Manual Testing
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.
BRS User Acceptance

Requirement Testing
Gathering
Black Box
System Testing
FRS Testing
Analysis
Integration
HLD Testing
Design White Box
LLD Testing
Unit Testing
Coding
Manual Testing 21

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 (1
to 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
i) 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.
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.
Smoke Testing
Like as Sanity Testing, Smoke Testing is also used to estimate the
stability of the Build.
22 Manual 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 reported
defects or by adding new requirements.
Types of Build
They are (7) types of Build. They are
Initial Build
(1) Initial Build Development
Sanity
(2) Stable Build Stable Build Testing
(3) Defect effected Build Comprehensi Defect Effected Build

ve Testing Bug
(4) Modified Build
Modified Build Fixing
(5) Complete Build
Re-Testing Complete Build
(6) Master Build Regression
Testing Test Closer
Master Build (Test Lead)
(7) Golden Build
U.A.T
Golden Build Sign off
Types of Projects
Mainly there are (3) Types of projects. They are (1) Traditional Project
(2) Outsourcing Project (3) Maintenance Project
Type of Project R/G Analysis Design Coding Testing R&M
Traditional 9 9 9 9 9 9
Outsourcing 8 8 8 8 9 9
Maintenance 8 8 8 8 8 9
Manual Testing 23

MANUAL TESTING
Testing Process
Test Initiation T.R.M 1) Scope of the Project

(Project Management / (Test Responsibility 2) Type of the Project
Quality Analyst Matrix) 3) Risk involved in that Project
1) What to Test?
Test Plan Document 2) How to Test?
(Test Lead) 3) Who to Test?
4) Whom to Test?
Test Scenarios & Re-testing &

Test Cases with Regression Testing
Step by step Test Case execution as
procedure Batches
(Test Engineer /
Tester) Defect Report Final Summary
Report
Bug fixing
Test Closer (Test Lead)
UAT
Sign Off
24 Manual Testing
PETT Process (Process Expert Tolls and Techniques)
Requirement Gathering
Analysis
Design Test initiation
Coding Test Plan Document
Test Scenarios & Test Case

with Step by step process
(1) Initial Build
Level ‘2’ Testing Level ‘0’ Testing / Sanity Testing

Re-Testing / Regression
Testing (2) Stable Build
Level ‘1’ Testing / Comprehensive
(4) Modified Testing / Batch Testing
Build Defect Report
(3) Defect Effected

Bug Build
Fixing (5) Complete Build
Level ‘3’ Testing / Test Closure / Postmortem

Testing / Pre-acceptance Testing
(6) Master Build
User Acceptance Testing
(7) Golden Build
Sign Off
Manual Testing 25

Testing Initiation:
In general testing process start with “Test initiation”. In this, Project
Manager / Quality Analyst develop Test starting Document. This document
defines the required testing approach to be followed by the testing team.
During this document preparation they will concentrate on below (12)
components.
1) Scope & Objective. 7) Test Automation
2) Budget Control. 8) Defect Tracing & Reporting
3) Test approach. 9) Measurements & Matrix.
4) Roles & Responsibilities 10) Change & Configuration Management
5) Communication & Status Reporting 11) Risks & Mitigations
6) Test deliverables 12) Training Plan.
1) Scope & Objective:

The need of testing in the project.
2) Budget Control.
Time & Cost allocation to the project.
Ex: As per U.S. Norms

100%
64% Development 36% Testing

Department Department
# 3) Test approach
##
In this they will specify a list of selected quality factors to be
applied by the Tester.
T.R.M (Test Responsibility Matrix) can be finalized by Project
Manager / Quality Analyst based on scope of the project, type of the
project and Risks involved in that project.
TRM : It defines the mapping between Test factors and Development
Stages.
26 Manual Testing
Function &
Quality Factors / Test RG &
Design Coding System R&M
Factors Analysis
Testing
1) Authorization
2) Access Control
3) Ease of use
4) Ease of operation
5) Correctness
6) Continuity &
Processing
7) Coupling
8) Data integrity
9) Recovery
10) Portable
11) Service Level
12) Performance
13) Maintainable
14) Methodology
15) Audit trail.
1) Authorization: Whether a valid user is accessible or not and Invalid
User is preventable or not.
2) Access control: Whether a valid user have permission to user specific
service of not
3) Ease of Use: Whether the application build is providing user
friendly screens or not.
4) Ease of operate: Easy to installation, downloading, uploading,
dumping, un-installing.
5) Correctness: Whether the functionality output is right or wrong.
6) Continuity & processing: The integration of modules.
7) Coupling: Co-existence with other Software.
8) Data Integrity: Whether the input objects are taking right type and
range of values or not.
9) Recovery: Whether the application build is changing from
abnormal state to normal state or not.
10) Portable: Whether the application build is able to run on
different platforms or not.
11) Service Level: The order of functionality.
12) Performance: The speed of processing.
13) Maintainable: Whether the application build is longtime serviceable
in customers site or not.
Manual Testing 27

14) Methodology: Whether the people (Tester) are following right

process of not. If not he will be punishable.
15) Audit Trail: Whether the system is maintains data for the user
operation (Ex. Bank Application, Withdrawal time,
ATM Centre Code etc.,)
1) Authorization Æ Security Testing

2) Access Control Æ Security Testing
3) Ease of use Æ User interface Testing
4) Ease of operation Æ Installation Testing
5) Correctness Æ Functionality Testing
6) Continuity & Processing Æ Integration Testing
7) Coupling Æ Intersystem Testing
8) Data integrity Æ Input domain Testing
9) Recovery Æ Recovery Testing
10) Portable Æ Compatibility Testing
11) Service Level Æ Functionality Testing
12) Performance Æ Load, Stress, Storage, Data volume Testing
13) Maintainable Æ Stress Testing
14) Methodology Æ Compliance Testing
15) Audit trail. Æ Functionality Testing
4) Roles and Responsibilities

Name of the jobs and his / her responsibilities.
5) Communication n& Status reporting

The required communication between two consecutive jobs.
Ex: Project Management Test Lead Test Engineer
When do report? Weekly Once, twice, daily etc.,
6) Test deliverables
The required documents to be prepared by the testing team. The
following documents were prepared by the Test lead and Test engineers.
Test Plan, Test Scenario, Test Cases, Test Data, Test log, Defect
report, Final Summery Report etc.,
7) Test automation
The purpose of Automation testing in the project and available
tools in the organization.
28 Manual Testing
8) Defect tracing & Reporting.

The required communication between Programmers and Testers
when Test Engineer / Tester got a mismatch.
Large Scale Small Scale
Project Management Project Management
Project Lead
Test Lead Test Lead Team Lead
Team Lead
Test Engineer Programmer Test Engineer Programmer
Transmittal Report
9) Measurement & Matrix:

The required measurement to estimate the status of the project. In
measurements there are (3) types such as (1) Quality Assessment
Measurement (2) Test Management Measurement (3) Process Capability
Measurement.
10) Change & Configuration Management

How to handle change request from the customer and how to store
the documents for future reference.
11) Risk & Mitigations:

The possible risks and solutions to overcome them.
12) Training Plan:

The required training secession to the Testing team to understand
about the project.
Manual Testing 29

TEST PLAN
After completion of Test Strategy Document, the strategy of the Project

implemented by Test Lead in the Project through Test Plan.
During Test Plan Document preparation, Test Lead category people
follows below approach.
a) Team formation
BRS
System Test Plan
b) Identify risks
TRM Module Test Plan
c) Prepare Test Plan (if project is big then only Module
Test Plan is to be prepared)
Development Plan d) Review Test Plan
a) Team Formation:
In general Test Plan Document preparation starts with Team
formation. In this Test Lead category people form the Testing Team
depending on below factors.
i. Project size.
ii. Project duration.
iii. Availability of domain testers.
iv. Resources (Automation Tools)
b) Identify Risks
After completion of Team Formation the Test Lead identifies risks
with respect to that formed testing team in Testing.
i. Lack of time.
ii. Lack of resources.
iii. Lack of communication.
iv. Lack of knowledge on project domain.
v. Lack of test data.
vi. Lack of development process rigor.
vii. Delays in delivery.
30 Manual Testing
c) Prepare Test Plan

After completion of Team formation and Risk Analysis, Team
Lead will prepare Test Plan Document in IEEE (Institute of Electrical &
Electronic Engineer) Format (829)
1) Test Plan ID 9) Exit Criteria
2) Introduction 10) Test deliverables
3) Test items 11) Test environment
4) Features to be tested 12) Staff & Training needs
5) Features not to be tested 13) Responsibilities
6) Test approach 14) Schedule
7) Entry criteria 15) Risks & Mitigations
8) Suspension Criteria 16) Approved by
1) Test Plan ID:

Unique number for feature reference.
2) Introduction
Introduction about the project or module.
3) Test items
The name of the requirements or features.
4) Features to be tested
The name of the requirements or features to be test.
5) Features not to be tested

The name of the requirements or features not to be test
6) Test approach
The list of selected quality factors to be applied by the Tester.
7) Entry criteria
When to start Testing
Î Take complete and correct Test cases.
Î Create Test Environment.
Î Receive Stable Build from the developers.
8) Suspension criteria
When to suspend testing temporarily
Î When we have network problem.
Î If pending defects are more
(Pending defects = No. of reported defects – No. of resolved defects)
Manual Testing 31

9) Exit criteria
When to stop testing
Î After completion of all module testing.
Î After completion of all Major bugs resolved.
10) Test deliverables

The required documents to be prepared by the Testers.
Ex.: Test Scenarios, Test Cases, Test Scripts, Test Data, Test log, Defect
Report, FSR ………… etc.,
11) Test environment

The required Software and Hardware to conduct Testing.
12) Staff and Training needs

The names of selected testers and their training needs.
13) Responsibilities
Work allocation to the testers.
Ex. Modules Vs. Testers.
14) Schedule
Time duration to the testers.
15) Risks and Mitigations

The required solutions for the previously analyzed risks.
16) Approved by
Who approved the document, the signature of the Project Manager.
Name of the Test Lead.
d) Review Test Plan:

Completion of Test Plan Document preparation, Test Lead is conducting
Review Meeting to estimate completeness and correctness of that document.
During this review they will concentrate on below coverages.
(i) Requirements Based Coverage (What to Test?)
(ii) Risk Based Coverage (Who to Test & When to Test?)
(iii) TRM Based Coverage (How to test?)
32 Manual Testing
TEST SCENARIOS & TEST CASE DESIGN

After completion of Test Plan Document and corresponding Reviews
Test Lad allocate the work to the Testers.
Testers are preparing corresponding Test Scenarios and Test Caes based
on Requirement Specifications.
USE CASE
Use Case is a required document which maintenance the detail
information about one low level requirement.
If you want to design Test Cases based on Use Cases, we can study the
Use Case below approach.
USE CASE FORMAT:
Title
Requirement Description
Actors / Users
Pre-operation
Action
Positive Flows
Exceptions / Negative flows
Alternative flows / Alternative Positive flows
1) Collect all Use Cases.
2) Take one Use Case and Study.
2.1) Identity Entry Point.
2.2) Identity Input Requirement
2.3) Identity Outputs
2.4) Identity Alternative flows and exceptions.
2.5) Identity exit point.
3) Prepare scenarios.
4) Review scenarios.
5) Prepare Test Cass with step by step procedure.
6) Continue from step (2) to (6) until completion of all Use Cases.
TEST SCENARIOS
Test Scenarios means Test situations.
Test Scenario Template
These templates are created in MS Excel.
Project Name:
Reviewed by
Module Name:
Created by:
Reviewed by
Created on:
Sl. No. Requirement Name Test Scenario Test Cases
Manual Testing 33

TEST CASES
A set of Test steps documented along with required inputs and expected
results in order to test one low level requirement.
Thinks to remember while designing the Test Cases.

1) Test Case should be simple and clear.
2) Test Case should be complete.
3) No duplicate Test Case should b written.
TEST CASE TYPE

1) User Interface Test Cases.
2) Usability Test Cases.
3) Validation Test Cases.
4) Functional Test Cases.
1) User Interface Test Cases

To verify the look and Feel of application build screens.
Ex: Font Size, Text alignment, Images etc.,
2) Usability Test Cases

To verify ease of use of application build screens.
Ex:
a) Default cursor should be present at the first field.
b) Tab keys should be implemented for all input objects from left to right
in downward direction.
c) Shortcut keys should be implemented for all menu operation.
d) Tool tips (Whenever we place the cursor on particular object, it should
return meaningful message)
3) Validation Test Cases:

Test Cases that are required to validate business rules or field
validation.
4) Functional Test Cases:

Test Cases that are required to validate the functionality.
TEST DESIGN TECHNIQUES

They are mainly (5) types of design techniques.
(1) Boundary Value Analysis (BVA)
(2) ECP (Equal Class Partition)
(3) Error Guessing
(4) Decision Tables
(5) State transition.
34 Manual Testing
(1) BVA:
It is used to validate the range of input objects.
(2) ECP:
Î Splitting the inputs into equal parts and randomly checking them.
Î To verify the type of input objects.
(3) Error Guessing

It is a technique which can be used by the people, who have prior
knowledge on that application (Ex. This can be used by experts)
(4) Decision Tables

A Black Box Test Design testing in which test cases are designed
to execute the combination of inputs.
Valid Invalid Valid Invalid

Valid Valid Invalid Valid
(5) State Transition

A Black Box Test design techniques, in which test cases are
designed to execute valid, invalid state transition.
Insert
card
Block
Card
Wait for
PIN Entry
PIN Wrong
PIN Wrong
PIN Wrong nd
2 Entry
1st Entry 3rd Entry

PIN Ok
PIN Ok
PIN Ok
Access
Account
Manual Testing 35

TEST CASE TEMPLATE
Test Case Test Case Step Step Test

Priority
Name / ID Description Name Description Data
1 2 3 4 5 6
Expected Actual Created Created

Status Comments
Results Results By on
7 8 9 10 11 12
Reviewed Reviewed Reviewer’s

QC Path
By On Comments
13 14 15 16
1) Test Case Name / ID:

Unique Number for future reference
Ex: TC001_Project Name_Module Name_Functionality Name
2) Test Case Description:

The description about that Test case.
Î Pre-requisites
Î Documents referred.
3) Priority
Importance of the Test Case. They are classified into (3) Types
such as
(1) High Priority (Basic functionality Test Cases)
(2) Medium Priority (General functionality Test Cases – Recovery,
Compatibility Testing etc.,)
(3) Low Priority (Cosmetic Test Cases – User Interface Testing)
4) Step Name
Every Test Case divided into multiple steps, every step in the test
case will have unique number.
Ex: Step–1; Step–2; Step–3 etc.,
5) Step Description
The required action to be performed by the user.
6) Test Data
Set of inputs that are required to execute steps.
36 Manual Testing
7) Expected Results
The required expected output from the system for the
corresponding user action.
8) Actual Results
The actual output of the system after performing user action.
9) Status
The current position of the Test Case. They are classified into (4)
types, such as
(a) No Run: Test Case not executed atleast for once.
(b) Not complied: A partially executed test case.
(c) Passed: Test Case executed and the expected value and
Actual value is same, “Test is passed”.
(d) Failed: Test Case any step(s) expected values
mismatched with actual value, “Test is failed”.
10) Created By
The name of the Test Engineer, who created the Test Cases.
11) Created on
Date and Time of the created Test Case.
12) Comments
A set of comments given by Tester for the Step or Test Cases.
13) QC Path
The path of Quality Control.
14) Reviewed By
Name of the Reviewer.
15) Reviewed on
When (Date & Time) the document was reviewed by reviewer.
16) Reviewer’s Comments

A set of comments given by reviewer.
Manual Testing 37

CASE STUDY
38 Manual Testing
User Name
User Name object allows alphabets lower case range from 4 to 8
characters.
Password
Password object allows alphabets lower case range from 6 to 10
characters.
Customer Name
Î Customer Name object allows alphabets.
Î Range from 4 to 12 characters.
Î First letter should be Upper Case.
Î Mandatory.
Customer Address
Î Customer Address object allows alpha-numeric and some special
Characters (“–“ “/” “#” “,” “.”)
Î Maximum of 20 Characters.
Î Mandatory.
Customer DOB
Î Customer DOB object allows Numeric Only.
Î The format is MM/DD/YYYY.
Î Date should be less than current system date.
Î Mandatory.
Customer Ph.No.
Î Customer Ph.No. object allows Numeric Only.
Î Allows 10 digits only.
Î Phone number is unique.
Î Mandatory.
E–Mail
Î E-Mail object allows alpha-numeric and special Characters.
Î Format is suresh_240878@yahoo.com.
Î It is not mandatory.
Manual Testing 39

TEST SCENARIO DOCUMENT
Project Name: Customer Info

Reviewed by
Module Name: Admin
Created by: Suresh
Reviewed by
Created on: 18/10/2008
Requirement Test
Sl. No. Test Cases
Name Scenario
Ok 1) Verify Ok with valid data.
1 Login 2) Verify Ok with invalid data.
Cancel 3) Verify Cancel
Insert 1) Verify Insert with valid data.
2) Verify Insert with invalid
data.
3) Verify Insert with duplicate
2 Add
data.
4) Verify Insert with missing
mandatory fields.
Search 1) Verify Search with valid
data.
3 Search 2) Verify Search with invalid
data.
Update 1) Verify Update with valid
data.
2) Verify Update with invalid
data.
3) Verify Update with duplicate
4 Edit
data.
4) Verify Update with missing
mandatory fields.
Home 6) Verify Home
5 Delete Delete Verify Delete
6 Cancel Cancel Verify Cancel
7 Home Home Verify Home
8 Logout Logout Verify Logout
Note: RCN (Requirement Clarification Note)

Any doubt in FRS / BRS Document, we people design RCN Document and
the same will be sent to BDP for clarification.
40 Manual Testing
TEST CASE DOCUMENT

Expected Result
name description Name Description Data
TC01_ This Test Step-1 Open Brower, Url It should display Login
Customer case enter Url. Page with User Name,
Info_Admin_ validates Address, click Password objects and Ok,
Verify Ok ‘Ok’ on Go Cancel functionalities.
with Valid functionality Step-2 Enter valid User It should display
data with valid User Name Name Customer Information
data and Password & Pass page with Add, Search,
click on Ok word Logout functionalities.
Verify Ok ‘Ok’ on Go Cancel functionalities.
with invalid functionality Step-2 Enter invalid User It should display
data with invalid User Name Name meaningful error
data and Password & Pass message.
click on Ok word
Verify Cancel Cancel on Go Cancel functionalities.
functionality Step-2 Enter User User It should clear all fields
Name and Name and cursor should be
Password click & Pass present in the first field.
on Cancel word
Verify Insert ‘Insert’ on Go Cancel functionalities.
with Valid functionality Step-2 Enter valid User It should display
Step-3 Click on Add -- It should display Add
Customer page with
C.Name, C.Addr.,
C.DOB, C.Ph.No., E-
mail objects and Insert,
Reset, Cancel
functionalities.
Manual Testing 41


Expected Result
Step-4 Enter data in C.Name It should clear all fields
corresponding C.Addr. and cursor should be
C.DOB
fields and present in the first field.
C.PhNo
click on Reset E-mail
Step-5 Enter valid C.Name
It should display a
data in C.Addr.
meaningful Message
C.DOB
corresponding such as “Customer Data
C.PhNo
fields and created with Customer
E-mail
click on Insert ID”
with invalid functionality Step-2 Enter valid User It should display
data with invalid User Name Name Customer Information
Customer page with
C.Name, C.Addr.,
C.DOB, C.Ph.No., E-
Reset, Cancel
functionalities.
Step-4 Enter invalid C.Name It should display a
data in C.Addr. meaningful Error
C.DOB
corresponding Message.
C.PhNo
fields and E-mail
click on Insert
with functionality Step-2 Enter valid User It should display
duplicate data with User Name Name Customer Information
duplicate and Password & Pass page with Add, Search,
data click on Ok word Logout functionalities.
Customer page with
C.Name, C.Addr.,
42 Manual Testing

Expected Result
C.DOB, C.Ph.No., E-
Reset, Cancel
functionalities.
Step-4 Enter C.Name It should display a
duplicate data C.Addr. meaningful Error
C.DOB
in Message.
C.PhNo
corresponding E-mail
fields and
click on Insert
with missing functionality Step-2 Enter valid User It should display
mandatory with User Name Name Customer Information
fields missing and Password & Pass page with Add, Search,
mandatory click on Ok word Logout functionalities.
fields Step-3 Click on Add -- It should display Add
Customer page with
C.Name, C.Addr.,
C.DOB, C.Ph.No., E-
Reset, Cancel
functionalities.
Step-4 Enter data in C.Name It should display a
corresponding C.Addr. meaningful Error
C.DOB
fields by Message.
C.PhNo
missing some E-mail
mandatory
fields and
click on Insert
Verify Cancel ‘Cancel’ on Go Cancel functionalities.
functionality Step-2 Enter valid User It should display
User Name Name Customer Information
and Password & Pass page with Add, Search,
Manual Testing 43


Expected Result
Customer page with
C.Name, C.Addr.,
C.DOB, C.Ph.No., E-
Reset, Cancel
functionalities.
Step-4 Enter data in C.Name It should close current
corresponding C.Addr. page and display
fields and click C.DOB
previous page.
on Cancel C.PhNo
E-mail
Verify Search ‘Search’ on Go Cancel functionalities.
with valid functionality Step-2 Enter valid User It should display
Step-3 Click on -- It should display Search
Search Page with C.ID, C.Name,
C.DOB, C.Ph.No.,
objects and Search,
Reset, Cancel
functionalities.
Step-4 Enter data in C.ID It should clear all fields
corresponding C.Name and cursor should be
fields click on C.DOB present in the first field.
C.PhNo
Reset
Step-5 Enter valid C.ID It should display Search
data in C.Name Results Page with
corresponding C.DOB Customers Information
fields and click C.PhNo and Edit, Delete, Cancel,
on Search Home functionalities.
Verify Search ‘Search’ on Go Cancel functionalities.
with invalid functionality Step-2 Enter valid User It should display
data with invalid User Name Name Customer Information
44 Manual Testing

Expected Result
C.DOB, C.Ph.No.,
objects and Search,
Reset, Cancel
functionalities.
Step-4 Enter invalid C.ID It should display
data in C.Name meaningful error
corresponding C.DOB
message.
fields and click C.PhNo
on Search
Verify Cancel ‘Cancel’ on Go Cancel functionalities.
C.DOB, C.Ph.No.,
objects and Search,
Reset, Cancel
functionalities.
Step-4 Enter data in C.ID It should close current
corresponding C.Name page and display
fields and click C.DOB previous page.
on Cancel C.PhNo
Verify ‘Update’ on Go Cancel functionalities.
Update with functionality
valid data Step-2 Enter valid User It should display
Manual Testing 45


Expected Result
C.DOB, C.Ph.No.,
objects and Search,
Reset, Cancel
functionalities.
Step-5 Select a - It should display Edit
Customer Page with C.ID, C.Name,
data click on C.Addr., C.DOB,
Edit C.Ph.No., E-mail objects
and Update, Reset,
Cancel, Home
functionalities.
Step-6 Enter data in C.ID It should clear all fields
corresponding C.Name and cursor should be
C.DOB
fields click on present in the first field.
C.Addr.
Reset C.PhNo
E-mail
Step-7 Enter valid C.ID It should display “Update
data in C.Name done” message.
C.DOB
corresponding
C.Addr.
fields click on C.PhNo
update E-mail
Update with functionality Step-2 Enter valid User It should display
invalid data with invalid User Name Name Customer Information
C.DOB, C.Ph.No.,
objects and Search,
46 Manual Testing

Expected Result
Reset, Cancel
functionalities.
and Update, Reset,
Cancel, Home
functionalities.
Step-6 Enter invalid C.ID It should display
data in C.Name meaningful error
C.DOB
corresponding message.
C.Addr.
fields click on C.PhNo
update E-mail
duplicate data with User Name Name Customer Information
duplicate and Password & Pass page with Add, Search,
data click on Ok word Logout functionalities.
C.DOB, C.Ph.No.,
objects and Search,
Reset, Cancel
functionalities.
Manual Testing 47


Expected Result
and Update, Reset,
Cancel, Home
functionalities.
Step-6 Enter C.ID It should display
duplicate data C.Name meaningful error
C.DOB
in message.
C.Addr.
corresponding C.PhNo
fields click on E-mail
update
missing with User Name Name Customer Information
mandatory missing and Password & Pass page with Add, Search,
fields mandatory click on Ok word Logout functionalities.
fields Step-3 Click on -- It should display Search
C.DOB, C.Ph.No.,
objects and Search,
Reset, Cancel
functionalities.
corresponding C.DOB
Customers Information

and Update, Reset,
Cancel, Home
functionalities.
48 Manual Testing

Expected Result
Step-6 Enter data in C.ID It should display
corresponding C.Name meaningful error
C.DOB
fields by message.
C.Addr.
missing some C.PhNo
mandatory E-mail
fields and
click on
update
C.DOB, C.Ph.No.,
objects and Search,
Reset, Cancel
functionalities.

and Update, Reset, Cancel,
Home functionalities.
C.DOB
fields and Previous Page.
C.Addr.
click on C.PhNo
Cancel E-mail
Manual Testing 49


Expected Result
Verify Home Cancel on Go Cancel functionalities.
functionality
Step-2 Enter valid User It should display
C.DOB, C.Ph.No.,
objects and Search,
Reset, Cancel
functionalities.

and Update, Reset, Cancel,
Home functionalities.
C.DOB
fields and Customer Info Page.
C.Addr.
click on C.PhNo
Home E-mail
Verify Delete Delete on Go Cancel functionalities.
50 Manual Testing

Expected Result
C.DOB, C.Ph.No.,
objects and Search,
Reset, Cancel
functionalities.
Step-5 Select a - It should remove
Customer customer’s information
data click on with “Customers
Delete Information was
successfully deleted”.
C.DOB, C.Ph.No.,
objects and Search,
Reset, Cancel
functionalities.
Step-5 Select a - It should close current
Customer page and display
data click on previous page.
Cancel
Manual Testing 51


Expected Result
Verify Home Home on Go Cancel functionalities.
C.DOB, C.Ph.No.,
objects and Search,
Reset, Cancel
functionalities.
Step-5 Select a - It should close current
Customer page and display
data click on Customer Info Page.
Home
Verify Logout on Go Cancel functionalities.
Logout functionality Step-2 Enter valid User It should display
Step-3 Click on - It should close current
Logout page and display Login
Page
52 Manual Testing
User Name
User Name object allows alphabets lower case range from 4 to 8
characters.
BVA & ECP for User Name

BVA ECP
Max+1= 9 Char Fail
Password
Password object allows alphabets lower case range from 6 to 10
characters.
BVA & ECP for Password
BVA ECP
Max+1= 11 Char Fail
Customer Name
Î Customer Name object allows alphabets.
Î Range from 4 to 12 characters.
Î First letter should be Upper Case.
Î Mandatory.
BVA & ECP for Customer Name
BVA ECP
Min= 4 Char Pass [a-z] [0-9]
Min-1= 3 Char Fail [A-Z] All
Min+1= 5 Char Pass Special
Max= 12 Char Pass characters
Max-1= 11 Char Pass
Max+1= 13 Char Fail
Manual Testing 53

Customer Address
Î Customer Address object allows alpha-numeric and some special
Characters (“–“ “/” “#” “,” “.”)
Î Maximum of 20 Characters.
Î Mandatory.
BVA & ECP for Customer Address
BVA ECP
Max= 20 Char Pass [a-z] All
Max-1= 19 Char Pass [A-Z] Special
Max+1= 21 Char Fail [0-9] characters
Some Spl. Except
Characters mentioned
–/#,.
Customer DOB
Î Customer DOB object allows Numeric Only.
Î The format is MM/DD/YYYY.
Î Date should be less than current system date.
Î Mandatory.
BVA & ECP for Customer DOB
BVA ECP
Max= 20 Char Pass [a-z] All
Max-1= 19 Char Fail [A-Z] Special
Max+1= 21 Char Pass [0-9] characters
Some Spl. Except
Characters mentioned
–/#,.
Customer Ph.No.
Î Customer Ph.No. object allows Numeric Only.
Î Allows 10 digits only.
Î Phone number is unique.
Î Mandatory.
BVA & ECP for Customer Ph.No.
BVA ECP
Max= 10 Digits Pass [0-9] [a-z]
Max-1= 19 Digits Fail [A-Z]
Max+1= 21 Digits Pass All Spl.
Characters
54 Manual Testing
TEST DATA DOCUMENT

Project Name
Reviewed by
Module Name
Created By
Reviewed on
Created on

Sl. Test Case Step Data

Data generated Comments
No. Name Name required
Step- http://192.168.1.0
Url
1 /Customer Info 1.0
1) rama
TC01_
User 2) rames
Customer
Name 3) gahesha
1 Info_Admin_
Step- 4) reliance
Verify Ok with
2 1) suresh
Valid data
2) sureshb
Password
3) sureshbug
4) sureshbuga
Step- http://192.168.1.0
Url
1) ram
TC02_
User 2) sureshbug
Customer
Name 3) ga*1
2 Info_Admin_
Step- 4) ram@123
Verify Ok with
2 1) sures
invalid data
2) sureshbugat
Password
3) SURESH
4) sarvani@bu
TC03_ Step- http://192.168.1.0
Url
Customer 1 /Customer Info 1.0
3
Info_Admin_ Step- U.Name pava
Verify Cancel 2 Password ganesh
Step- http://192.168.1.0
Url
Step- U.Name pava
TC04_
2 Password ganesh
Customer
Ramu
4 Info_Admin_
Sita
Verify Insert C.Name
Step- Ramakrishna
with Valid data
5 Koteswararao
Koti,D.No.-5/G
C.Addr.
Brundavancolony7/G-3
Manual Testing 55


C.DOB 05/25/1976
C.Ph.No. 9440163282
suresh_240878@
E-mail
yahoo.com
Step- http://192.168.1.0
Url
Step- U.Name pava
2 Password ganesh
TC05_
Sai
Customer C.Name
Saisarvanibug
Info_Admin_
5 Brundavancolony7/G*3
Verify Insert
C.Addr. Brundavanacolony
with invalid Step-
7/G-3
data 4
C.DOB 25/10/1976
C.Ph.No. +91-9440163282
suresh_240878#
E-mail
yahoo.com
Step- http://192.168.1.0
Url
TC06_ Step- U.Name pava
Customer 2 Password ganesh
Info_Admin_ C.Name Koteswararao
6
Verify Insert C.Addr. Brundavancolony7/G-3
with duplicate Step- C.DOB 05/25/1976
data 4 C.Ph.No. 9440163282
suresh_240878@
E-mail
yahoo.com
Step- http://192.168.1.0
Url
TC07_
Step- U.Name pava
Customer
2 Password ganesh
Info_Admin_
C.Name Koteswararao
7 Verify Insert
C.Addr. Brundavancolony7/G-3
with missing
Step- C.DOB 05/25/1976
mandatory
4 C.Ph.No. 9440163282
fields
suresh_240878@
E-mail
yahoo.com
TC08_
Step- http://192.168.1.0
8 Customer Url
Info_Admin_
56 Manual Testing

Verify Cancel
Step- U.Name pava
2 Password ganesh
C.Name Koteswararao
C.Addr. Brundavancolony7/G-3
Step- C.DOB 05/25/1976
4 C.Ph.No. 9440163282
suresh_240878@
E-mail
yahoo.com
Step- http://192.168.1.0
Url
TC09_ 1 /Customer Info 1.0
Customer Step- U.Name pava
9 Info_Admin_ 2 Password ganesh
Verify Search C.Name Koteswararao
Step-
with valid data C.DOB 05/25/1976
5
C.Ph.No. 9440163282
Manual Testing 57

Review on Test Cases

After completion of Test Case preparation, Test Engineer is conducting
Peer Review and Test Lead is conducting Lead Review to estimate
“Completeness and Correctness” of that document
PM PL
TE-1 TE-2
Peer Review
After completion of review on Test Cases, Test lead is mapping Test

Cases with Requirement Traceability Matrix Document. (RTM)
RTM defines the mapping between requirements and Test Cases.
Traceability Matrix Template

Project Name Project Manager
Prepared By Reviewed By
Reviewed on
Prepared on
Last Updated on
Requirement Use Case Test Case
Sl. No. Test Scenario
Description Reference Reference
TEST CASE EXECUTION
After completion of Test Cases preparation and corresponding reviews,

Testers are receiving initial build from the development people.
During Test Case execution Testers are receiving modified build from the
developers. To receive any type of build from the developers, Testers required
a valid negotiation / communications with developers like as below.
58 Manual Testing
Developers
COMMON REPOSITORY / SOFT BASE
1.0 2.0 3.0

Client
VSS (Visual Source Safe)
The versions have been maintained
by these VSS
FTP (File Transfer Protocol)

Deploy / Install Build
Sanity Testing
Testers
EXECUTION LEVELS:
Initial Build
Level ‘0’
Stable Build Sanity Testing
Level ‘1’ Defect Effected Build

Comprehensive
Testing
Modified Build Bug Fixing
Level ‘2’ Complete Build

Re-Testing Level ‘3’
Regression Testing Test Closer
Master Build (Test Lead)
U.A.T
Manual Testing
Golden Build Sign off 59

TEST HARNESS:
Test Harness means ready to start testing.
Test Harness = Test Environment + List of Test Cases.
LEVEL ‘0’ TESTING

After receiving initial build from the development people, Testers are
conducting Level ‘0’ Testing to estimate stability of that build before start real
testing.
In this testing, Testers are concentrates on Core (Basic) functionalities.
During this Testing they will concentrates on below factors.
1) Under standable.
2) Operatable
3) Observable
4) Controllable.
5) Consistency.
6) Automatable.
7) Maintainable.
8) Simplicity.
From the above factors Level ‘0’ Testing is also known as “Oct-Angle
Testing” or Sanity Testing or Build Verification Testing or Tester Acceptance
Testing or Testability Testing.

It is also known as “Comprehensive Testing”. During this testing Testers
are executing all P0, P1, P2, Test Cases (P0–High Priority, P1–Medium Priority,
P2–Low Priority) to validate functionality. In this every Test Case has to be
executed by Tester either in Manual or in Automation.
Build Build
Test Cases
Test Cases
Automation
Test Engineer Testing
Manual Testing
Test Engineer
Automation Testing
60 Manual Testing
Execution Process
Skip Pass
Take all the Test Test Case Fail Close

Cases Execution
Blocked Test Cases Partial Pass or Fail
Defect Report
During test execution, Testers are reporting mis-matches to development
Teas as “Defect” in Defect Report Document.
Defect Report Format

1) Defect ID
Unique for future reference.
2) Summary
Brief description of the defect.
3) Features
The name of the feature / functionality in which defect.
4) Test Case Name

Name of the Test Case (in which Test Case execution the defect is
raised)
5) Reproducible
The defect is repeatable in every time execution.
a. If Yes: It is reproducible, attach test procedure.
b. If No: It is not reproducible, attach test procedure along with snap
shots.
6) Status
Status of the defect. They are (2) types
(i) New–Reporting for first time.
(ii) Re-open–For re-reporting defects.
Manual Testing 61

7) Severity (Seriousness with respect to Testers)

It means seriousness of the defect with respect to Tester or
seriousness of the functionality. They are classified into (3) Types such
as
(i) High severity – Urgent to solve

(ii) Medium severity – Mandatory to solve
(iii) Low severity – Compulsory to solve
8) Priority
Importance of the defect with respect to customer or importance of
the functionality. It is classified into (3) types such as
(i) High Priority
(ii) Medium Priority
(iii) Low Priority
9) Assigned to
Name of the Developer
10) Detected By
Name of the Tester (Who detected the defect)
11) Reported on
Date and Time
12) Build Version ID

In which version of the build the defect is raised.
13) Suggested to fix

Suggestions to developer to fix the defects
By Developers
Î Fixed By:
Name of the Programmer who fixed the defect.
Î Resolved on
Date and Time
Î Resolution Type:
Acknowledgment from the developers for the reported
defect.
Î Approved by
Signature of the Team Lead / Project Lead.
62 Manual Testing
Types of defects
1) User interface defects (Low Severity)
Spelling mistakes (High Priority)
Improper alignment (Low Priority)
2) Input domain defect (Medium Severity)

Input type is not taking valid type ((High Priority)
Input type is taking invalid type also (Low Priority)
3) Error handling defect (Medium Severity)

No error message for wrong operation (High Priority)
Complex message in error message (Low Priority)
4) Calculation defect (High Severity)

Wrong outputs (High Priority)
5) Load conditional defect (High Severity)

Build is not supporting more than one user (High Priority)
Build is not supporting customer expected load (Low/Medium Priority)
6) Hardware defect (High Severity)

Build is not supporting any hardware devices (High Priority)
Build is supporting hardware and wrong output coming from hardware
(Low Priority)
7) Role conditional defect (High Severity)

System crash, Showstoppers, Dead lock etc.,
8) Version control system (High Severity)

Mistake in version control
9) Source defects (Medium Severity)

Mistake in Help Document (High Priority)
What is defect Age?

The time gap between defect reported on and defect resolved on.
What is Build Internal period?

The time gap between two consequent builds is called as Build Internal
period.
Manual Testing 63

BUG LIFE CYCLE / DEFECT LIFE CYCLE

New
Review the defect
Reopen
Open Rejected Hold Duplicate Deferred
Fixed
Defect
If defect is
not fixed
Close
Hold: The defect is not accepted, not rejected due to developer need more
information about that defect.
Duplicate: The defect is rejected due to defect is previously accepted defect.
Deferred: The defect is postponed to next version / release.

After receiving the modified build from the developers, Testers are
performing Re-testing / Regression Testing to ensure whether the reported
defects are properly rectified by the developers or not and to check whether
there is any side effects occurred or not on dependent functionalities by solving
the reported defects or by adding new requirements.
Case Study
Modified Build
High Severity Medium Severity Low Severity Enhancement

All P0, P1, P2 All P0, some P1, & Some P0 & All P0, P1, P2
Test Cases Selected P2 Test Selected P1, P2 Test Cases
Cases Test Cases
64 Manual Testing
Case 1: If the development team resolved bug severity is high, then Testers
are re-executing all P0, P1, P2 Test Cases on that modified build.
Case 2: If the development team resolved bug severity is medium then,
Testers are re-executing all P0, some P1 and selected P2 Tests cases
on that modified Build.
Case 3: If the development team resolved bug severity is low, then Testers
are re-executing some P0 and selected P1 and P2 Test cases on that
modified build.
Case 4: If the development team released modified build due to some
change request then the Testers are re-executing all P0, P1, P2 Test
Cases on that modified build.

After completion of all test cases execution and corresponding bugs
resolving, Testers are sending complete build to the Test lead along with FSR
(Final Summary Report)
After receiving Final Summary Report from the Testers, Test lead is
conducting “Test Closure” to estimate that whether the Test Engineer meets exit
criteria or not.
In this Test lead category people will concentrate on below coverages.
1) Requirements Coverage:
All the requirements with respect to functionality.
2) Bug density
No. of defects in Module . X 100
No of defects in the Project
3) Analysis of deferred bugs:
Whether the deferred bugs are reasonable or not to postpone.
After completion of above like coverages Test lead is conducting Test
Closure in below approach.
Take High Bug density Module
Do Regression Effort Estimation
Do Regression Plan Regression
Do Regression
Manual Testing 65

User Acceptance Testing

After completion of “Test Closure” the Project Manager collects
feedback from the customers on developed software through “User Acceptance
Testing”. They are two types such as
α – Test β – Test
(Alfa Test) (Beta Test)
Æ Software Application. Æ Software Product.
Æ By Real customer. Æ By Model customer.
Æ At development site. Æ At customer site.
Signoff
After completion of User Acceptance Testing and corresponding
modifications, the Project Management deliver that software / build to the client
along with Software Delivery Note (S/w DN). It consists of (2) issues such as
(i) User Manual.
(ii) Known issues
66 Manual Testing

Testing Tools (Manual)

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Testing Tools (Manual)

Diunggah oleh

Hak Cipta:

Format Tersedia

suresh_240878@yahoo.com Suresh.

Jai Sri Ram Jai Sai Ram

S.Q.A (Software Quality Assurance)

(ii) LLD (Low Level Design Document)

MESSAGE BOX OK CANCEL

Note: A Project will have one HLD and Multiple LLDs.

SS1 SS2 SS3

 What is the difference between Software Product and Software

 What is Error, Defect, Bug?

SQC (Software Quality Control)

 Why Software has Bugs?

Reviews in White Box Testing / Test Software

Reviews in Design Document

i) Are they complete/

Programmers are checking the completeness and correctness of the

Passed Passed Failed

STUB Temporary Program

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

Driver / Calling Program

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

c) Hybrid Approach / Sand-witch Approach

Case 1: Top-down approach is followable, when the customer’s

Case 2: Bottom-up approach is followable, when the customer’s

Case 3: Hybrid Approach is followable, when the customer’s requirements

Case 4: Bigbang Approach is followable, when the application build

BLACK BOX TESTING

b. Manual Support Testing

BVA & ECP for User Name

BVA & ECP for Password

Ex: Age object allows numeric range from 16 to 60.

BVA & ECP for Age

Ex: Mobile No. object allows numeric 10

BVA & ECP for Mobile No.

In this we are checking whether the

In this testing we are checking whether the insert of front end

6) Service level coverage.

Build O.S Build O.S

V.B Unix VC++ Win98

Ex: Unix does not support VB Æ Win98 is supporting VC++

Telephone Bill Server

Water Tax Bill Common Data Server

Municipal Bill Server

(iii) Encrypt / Decrypt Data Testing.

Build Customer Æ Setup Program.

GRAY BOX TESTING

UAT (User Acceptance Test)

During this they will concentrate on below factors.

After completion of above like factor observation the release team is

Enhancement Missed Defect

Perform changes Test S/w changes

The risks are

SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC)

2) INCREMENTAL WATERFALL MODEL

Hardware Prototype Software Prototype

Finalize Environment Requirements refined

SRS Base lined BRS Base lined

5.0 4.0 3.0 2.0 1.0

Customer Coding and

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”.

To check whether the people are developing right product or not.

What is the difference between Software Product and Software

What is Error, Defect, Bug?

Why Software has Bugs?