Professional Documents
Culture Documents
Manual Testing: Who Can Get Testing Job?
Manual Testing: Who Can Get Testing Job?
PRODUCT:1
Will be involved in this meeting Apart from them many times customer representations also
2
Analysis Phase
Designed Phase
Testing Phase
Initial or Requirement Phase:Task:-Interacting with the customer and gathering the requirements.
Roles:- i) Business Analyst [BA]
ii) Engagement manager [EM]
Process:- First of all the Business Analyst can Appointment . from the customer, collects the
template from the company meet the customer an the appointment date gathers the
requirements with the help of the template and come back to the company with the
requirement documentary.
The Engagement manager will go through the requirements document. If at all he
finds any extra requirements hence he will deal with the excess cast of project. If it is any
confession of requirements then the will ask the consult team to develop the prototype he
will demonstrates to the customer gather the clean requirements and finally hand over the
requirements document to the business analyst.
3
Analysis phase:Task:
Feasibility study
Tentative planning
Requirement analysis
Roles:
Process:-
[HLD]
[LLD]
Proper indentation
Color coding.
Proper commenting.
Proof:- The proof document of the coding phase SCD (Source Code Document).
Delivery & Maintains Phase:Delivery:Task:- Hand overring the application to the client .
Roles:- Deployment Engineers or Installation Engineers
Process:- Deployment engineers will go to the clients place , install the application into the
original customer ,Environment and finally hand overs the software to the customer.
Proof:- The final official argument made between the company and the customer is the
proof document this phase.
Maintains:- Once the customer start using the application if at all any problem occurs then
that problem will become the task ,based on the task corresponding roles will be appointed
,these roles will define the process, solves the problem and final get the Application latter.
Some customer many request for continuos maintenance in that situation the
company will send a team of member to the customer place continuously in order to take care
of that software.
Q. where exactly testing comes in to picture?
Which sort of testing you are expecting?
How many sort or testing are there?
Ans:- They are two sort of testing
i) Un convectional testing.
ii) Convectional testing.
Un convectional testing:- It is a sort of testing in which the quality assurances people. Will
check each and every role in the organization in order to conform weather they are doing
their work according to the companies proper guidelines are not. Right form the staring of the
SDLC to the end of it.
Convectional testing:- It is a sort of testing in which the test engineers will check the
developed application (or) its related parts are working according to the expectation or not
from the coding phase to the end of the SDLC
7
Methods of the testing (or) testing techniques:Basically there are two methods of testing.
i)
ii) White Box Testing (or) Glass Box Testing (or) Clear Box Testing
Black Box Testing:- It is a method of testing in which one will perform testing only on the
Functional part of an application with out on the having the knowledge of structural part.
Usually the black box Test engineers will perform it.
White Box Testing:- It is a method of testing in which one will perform testing on the
Structural part of an application .
Usually developers (or) White box testers will perform it.
Gray Box testing:- It is a method of testing in which one will perform testing on both the
functional part as well as the structural part of an application.
Usually the test engineers who have the knowledge of structural part will perform it.
In this stage the Black box test engineers will test the functional part of the
module.
Integration level testing:- In this stage the developers of will develop some
interface(linking program) in order to integrate the modules this interface will be tested by
white box testers. Developers will follow any one of the approaches white integration the
module.
Top down approaches
Bottom up approaches
Hybrid approaches (or) Sand rive approached
Big-Bang approaches
Top down approaches:- In this approaches the parent modules will be
developed first and then the corresponding child modules will be developed
and integrated.
STUB:- While integrating the modules in top down approach if at all any mandatory
modules are missing then that mandatory modules will be replace with a temporary
program.
DRIVER:- While integrating the module in bottom up approached if at all any mandatory
modules is missing then that modules is replaced with a temporary program DRIVER
Hybrid approach (or) San drive approach:- This a mixed approach of Both
top down and bottom up approaches.
10
Big-Bang approach:- In this approach one will wait till all the modules are
developed and finally will integrate then at a time.
System level testing:System:- Once the software application is installed in to an environment then as a whole we
will call it as a system.
In this stage the block box test engineers will conduct many type of testing like
load testing, performance testing, stress testing, comparability testing, system integration
testing..ect.
System integration testing:- It is a type of testing in which on will perform
some action on module and check for the reflections in all the related are as of
the application.
User acceptance level testing:- In this stage the block box test engineer will perform testing
on the user desired areas in the presence of accept the application happy.
Client Sever Environment (or) Two Tier Architecture:- In this environment two tier will
be there .one is for client and another is for data base server. Presentation layer and the
business layer will be available is each and every client and the data base player will be
present in data base server.
When ever the application need be used single premises and there is no
problem with the security of the. Business logic as well as the application need accessed very
fast lye then this environment be suggested.
12
Web Based Environment (or) Three Tier Architecture:- In this environment three tier will
be there one is for clients, the middle is one is for application sever and the other is for data
base sever. presentation layer available in the client business layer will be available in the
application server. data base sever.
When ever the application need to be used all over the world by limited
numbers of user and wounds the business logic will be secured and function updaters to be
easily them the in environment can be suggested.
13
THIN CLIENT:- If at all the client machine is having only the .presentation
logic then it is know as thin client.
THICK CLIENT:- If at all the client machine is having both presentation
logic as well as business logic then it is known as thick client.
APPLICATION:- It is a Presentation Layer, Business Layer, Data Base
Layer.
SOFTWARE DEVELOPMENT PROCESS MODELS: Waterfall Model
Prototype Model
Evolutionary Model
Spiral Model
Fish Model
V-Model
14
Waterfall Model:Phase
Activity
Outcome
INTIAL
REQ &
GATHE
RINGN
G
BRS
ANALYAIA
SYS,
DESIG
N
SRS
DESIGN
TDD,GUI
S/W
DESIG
N
UNIT TEST
UTR
INT .TEST
ITR
IMPLIM
ENTATI
ON
CODING
MTRTEST
MOD
STRTEST
SYS
BLOCK
BOX
TESTIN
G
TESTING
DELIVER &
MAINENENCE
UATR
UAT
DELIVERY TO CLIENT
Prototype Model:15
PROTOTY
UN CLEAR
PE REQ.
CLIENT
DEMO
DEMO
TO
TO
REQ.
ARECLIENT
ENVIRONMENT
CLIENT
REFINED
CONFORMATION
Advantage:- when ever the customer is not clear with his requirement. Them this is best
suitable model
Draw Back:-
Evolutionary Model:16
INITIAL
REQ.
N
O
DEVELOP
APPLICATIO
N
FEED BACK
WITH NEW REQ.
USER
ACCE
PT
USER
VALEDATION
YE
S
APPLICATION
BASE
LINE
Advantage:- when ever the customer is evolution the requirement then this is the Best
suitable model
Draw Back:- time consuming model
Costly model
Deed lines cant properly define.
No transference.
Project monetary any maintenance is very difficult.
Spiral Model:17
4)REFINIG &
PLANNING
2) RISK ROOT
CAUSE
ANALYSIS
ESTIMATION
3) IMPLEMENATION
CONTINGENCIES
Advantage:- When ever the project highly risk based then this is the best suitable model.
Draw Back:- Time consuming model.
Costly model.
Risk root cause analysis is nota easy task.
Fish Model:-
18
REQ
ANAYSIS
DELIVERY MAI-GATHERING
Testing Maintan
DESIGN
CODING
SYSTEM
SRS
HLD
BRS REVIEW
BLOCK Box Testing
SCD
LLD
Test S/W
SRS REVIEW
Changes
TDD REVIEW
Advantage:- As both the verification are done the outcome will be a quality product.
Draw Back:- Time consuming.
Costly model.
V-Model:Verification
Validation
INITIAL &
BRS
PREPARING PROJECT PLANNING
ANALYIS
SRS
PREPARING TEST PLANNING
DESIGN &
DESIGN PHASE TESTING
CODING
PROGRAM PHASE TESTING
TESTING
TESTING
TDD
SCD
S/W BUILD
SYSTEM
TEST
MANAGEMT PROCESS
USER ACCEPTANCE TESTING
DEVIVER &
TESTING
MANINTENANCE
EFFICIENCY
DRE= A
PORT
S/W
TEST S/W
CHANGS
A+B
Advantage:- As both the verification and validation is done and test management process is
maintained. The outcome will be quality product.
Draw Back:- It is time consuming model.
It is a costly model.
Verification:- Verification is a process of checking whether the product is being
developing in a right manner or not.
Validation:- Validation is a process of checking whether the develop product is right
or not.
TYPE OF TESTING:
Regression testing
Re testing
Half- testing
B-testing
Static testing
Dynamic testing
Instillation testing
Compatibility testing
Exploratory testing
End-To-End Testing
Security testing
Usability testing
Reliability testing
Mutation testing
Adhoc testing
20
Build acceptance testing (or) Build verification testing (or) Sanity testing:It is a type of testing in which one will conduct overall testing one the released build in
order to conform where the proper of not for conducting detailed testing
In this type of testing us ally they check the following.
i)
ii)
Weather one can navigate to all the pages of the application or not.
iii)
iv)
In some company they will call this types of testing as Smoke testing also
but in some companies they say that just before releasing the build the developer will check
weather the build is proper or not i.e. know as Smoke testing.
Once the build is released the testing engineers will once again check weather
the build is proper or not i.e. knows as BAT (or) BVT (or) sanity testing.
Regression testing:- It is a type of testing in which one will perform testing on the ready
testing functionality again and again us allay it is done in two servicers.
i)
When even some defects are identified raised to the development department once
the next build is released the testing engineers will check the defect functionality as
well as the related functionality once again.
ii)
When ever some new feature are added i.e. the application next build is released to
the testing department then the test engineers will check all the related features of
those new features once again.
NOTE: - Testing new features for the first time not regression testing.
Some companies may do Random testing at the end that also will fall under
regression testing only.
Retesting: - It is a type of testing in which one will perform testing on the same functionality
again and again with multiple sets of data in order come to a conclusion weather the
functionality is working fine or not.
21
NOTE:i)
Regression testing starts form the 2nd build and continue up to the last build.
ii)
Re testing starts from the 1st build and continuous up to the last build.
iii)
During regression testing also re testing will be conducted that is the reason
some people even call it as Re and Regression testing.
Half testing: - It is a type of testing user accepting testing conducting in the soft ware
company by the test engineers just before the delivery.
B-testing: - It is a type of testing user accepting testing conducting in the client place either
by the end user (or) by the third party testing experts just before actual implementation of a
application.
Static testing: - It is types of testing in which one will perform testing on the application on
its related factors without perform any action.
EX: - GUI testing, Document testing, code--------------ect
Dynamic testing: - It is types of testing in which one will perform testing on the application
on its related factors by perform some action.
EX: - retesting, functionality testing.ect.
Instillation testing :- It is a type of testing in which one will trey to instillation the
application by following the guide ling provided in the deployment document in order to
conform whether those guidelines really suitable for instillation the application comfortable
(or) not.
Compatibility testing:- It is type of testing in which one will install the application into
multiple environment prepared with different .combation in order to check .whether it is
suitable with those environment (or) not.
Monkey testing: - It is type of testing in which one will intentionally perform some action
in order to check stability of the application.
Port testing: - It is type of testing in which one will install the application into the original
customers environment and check whether it is comprisable with that environment (or) not.
22
Exploratory testing:- It is type of testing in which Do many expert will check the
functionality of the application which out having the knowledge of requirement just by
parallel exploring the functionality.
Exploratory: - Have in the base knowledge of some concept doing something and
more about it is knows as exploratory.
End-To-End testing: - It is type of testing in which one will perform testing on all the end to
end sceneries of the application.
Ex:- login
Balance enquiry ----10,000
With draw
-------3,000
Balance stmt
----------7,000
Logout
Security testing:- It is type of testing in which one will perform testing on the application in
order to conform whether it is properly protected (or)not.
i)
ii)
Direct URL testing: It is type of security testing in which one will enter the direct
URLs if secured pages and check whether they access (or) not.
URL [Uniform Resource Location]
iii)
Usability testing:- It is type of testing in which one will check the user friendly of the
application.
Reliability testing (or) Socking testing:- It is type of testing in which one will use the
application continues for long period of time in order to set the stability of the application.
Mutation testing:- It is type of testing in which one will perform testing on the application or
its related factors after doing some changes to them.
Adhoc testing:-It is a type of testing in which one will perform testing on the application in
the there own style after understanding requirement very clearly.
Us ally this type of testing will be encouraged after formal testing.
23
TEST PLANNING
ii)
TEST DEVELEPOMENT
iii)
TEST EXECUTION
iv)
RESULT ANALYSIS
v)
BUG TRACKING
vi)
REPORT
Test planning:- Test plan is strategic document which contains some information that
describes how to perform testing on that application in a effective ,efficient and optimized
way.
Plan:- Plan is a strategic document which contain some information that describe how
to perform task in a effective, efficient and optimization.
Optimization:- Optimization is a process are utilizing the available resources to their
level best and getting the maximum possible out put.
Index of test plan (or) Contents of test plan:1.0)
Introduction
1.1) objective
1.2) reference document
Reference document:- The list of the document that are referred will
preparing this documents will be listed out here in this section
EX: - SRS, Project plan
Features are tested: - The list of all the features with in the scope which are
to be tested will be listed out here in this section.
Features not be tested:- The list of all the features that are not planed for
testing will be listed out here in this section.
EX:- i) Out of scope features
ii) Low risk features
25
Level of testing: - the list of all the levels of testing that are maintained in the
company will be listed out here in this section.
Type of testing: - The list of all the type of testing that all perform in that company
will be listed out here in this section.
Test design techniques: - The list of all the techniques that used in that company
while designing test cases will be listed out here in this section.
EX: - BVA, ECP
Configuration management:-
Test Metrics: - The list of all the metrics that are maintained on the company doing
the test process will be listed out here in this section.
Terminology: - The list of all the terms used in that company along with their
meaning will be listed out here in this section.
Automation plan: - The list of all the areas that are planned for automation in that
company will be listed out here in this section.
26
List of automated tools: - The list of all the automated tools that are used in that
company will be listed out here in this section.
Acceptance criteria: - When to stop testing will be clearly described in this section.
Suspense criteria: - When to suspense testing will be clearly described here in this
section.
5.0) Test deliverables: - The list of all the document that are to be developed of delivery
doing testing process testing process will be mentioned here on this section.
6.0) Test environment:-The details of environment that is about to be used for testing will be
clearly mentioned here in this section.
7.0) Resource planning:- Who has to do what will be clearly described here in this section.
8.0) Scheduling (or) Time planning:- The starting dates and ending dates of each and ever
task will be clearly planed and mention in this section.
9.0)Staffing and training:- To accomplish that project sues fully if at all any staff
requirement and if at all any training requirement then that detailed will be clearly mention
here in this section.
10.0) Risk and Continence:- This list of all the potential risk and continence solution plan
will be clearly mentioned here in this section.
Ex:- Employee may leave the company the middle of the project?
Ans. Employee need to mint on benched.
Unable to de clearly project with in the deadline project?
Ans. Proper plan insurance.
Costumer may impose the deadline?
Ans. What not be tested should planned.
Unable to test all the feature with in the given time?
Ans. Priority based the execution.
11.0) Assumptions: - The listed of all the think that are be assumed by the test engineer will
be clearly mentioned here in this section.
12.0) Approached information:- Who has approval this document when it is approval will
be clearly described in this section.
27
USE CASES
SCREEN
SHORT
Use cases:- Use case describes of the functionality of certain application terms of
action response.
Login
User Name
Password
Login
Clear
Cancel
i) Functional requirement
ii) Special requirement
Functional requirement:
Login screen should contain user name, password connect to fields login, clear, cancel
button.
Connect fields is not mandatory but it should be allow user to select the data base option
when ever require.
Upon entering valid user name, password and clicking on login button corresponding
page must be displayed.
Upon entering in to any of the fields and clicking on clearly button all the fields must be
cleared and courser should he display in the user name.
Special requirement:
Initial when ever the login page invoked login and when ever and clear button is
disabled.
Upon entering some information in to and of the fields clear button must be enabling.
Upon entering some information in to both user name and password fields login
button must be enabling.
Tabbing order must be user name, password, connect to, login, clearer, cancel.
ii)
ii)
Brief description the use case: This use case describes the functionality of all the
features present in the login screen.
iii)
iv)
Explicitly requirement
Implicitly requirement
Explicitly requirement:- The requirement the explicitly given by the customer are know
as explicitly requirement.
29
Implicitly requirement: The requirement that are analyzed by the business analyst which
will add some value to the application with out disturbing any of the original customer
requirements.
Explicitly requirement: Install when ever the login page invoked login and clear button is disables.
Cancel button must be any way enable.
Open entering some information into any the fields clear button must be enabling.
Upon entering some information into both user name and password fields login button
must be enable.
Tabbing order must be user name password connect to login clear cancel.
Implicitly requirement: Open entering invalid user name valid password and click on login button the following
error message must be displayed. Invalid user name please try again.
Upon entering valid user name in valid password and click on login button following error
message must be displayed. invalid password please try again
Upon entering invalid user name invalid password and click on login button following error
message must be displayed. invalid user name and password please try again
Initial when ever the login screen is invoked the curser must be display on the user name
fields.
Precondition:- login screen must available.
Post condition:- Either home page (or) add mine and error message for invalid user.
Flow of events:- Two types
i) Main flow
ii) Alternative flow
Main flow:Action
Actors invoke the application.
Actors entrees valid user name valid password and click on login button.
Actors entrees valid user name valid password select a data base also and click on login
button.
Actors entrees invalid user name valid password and click on login button.
Actors entrees invalid password valid user name and click on login button.
Actors entrees invalid user name invalid password and click on login button.
Actors entrees some information into any of the field and click on clear button.
30
Response
Application display the login screen with the following fields user name, password, connect
to, login, clear, cancel.
Authentication, application display either home page (or)admin page depending upon the
actor entered.
Authentication, application display either home page (or)admin page depending upon the
actor entered with the mentioned data base connections .
Go to Alternative flow Table 1 (Invalid user name)
Go to Alternative flow Table 2 (invalid password)
Go to Alternative flow Table 3 (invalid user name and password).
Go to Alternative flow Table 4 (clear click).
Go to Alternative flow Table 5 (cancel click).
31
32
Response
Authentication, Application displace, the following error message invalid user name please
try again.
Authentication, Application displace, the following error message invalid password please try
again.
Authentication, Application displace, the following error message invalid user name and
invalid password please try again.
Application clears all the fields login screen and displaces the cursor in the user name fields.
Security module
Identify the functionality of the use case with respect total functionality ?
Ans : Authentication .
Identify the functionality point and prepare the functionality point document?
Ans: Where ever user perform some actions on the application that is called functional point.
Identify the input requirement to perform testing ?
Ans: Valid and invalid user name and password .
Identify the actors invalid ?
Ans: Normal user and admin user.
33
Identify the weather the use case linked with any other use case ?
Ans: Home pager and admin page use case.
Identify the precondition?
Ans: Login screen must be available
Identify the post condition ?
Ans: Either home page and admin user and error.
Understand main flow of the application ?
Functional point :- The point where the user can perform some action in the application is
know as functional point.
Testing process related document:-
UCD
Use Case
Docume
nt
FPD
Function
al Point
Docume
nt
TSD
Test
Scenario
Docume
nt
DTCD
DTD
Detail
Test
Case
Docume
Defect
Point
Docume
nt
Traceability matrix :-It is a document which contains table of linking information used for
traceability back for the reference in any kind of confusion (or)questionable situation.
EX1:- (CTM) Complete Traceability Matrix.
34
UCID
TPID
TSID
TCID
DID
10
99
86
36
20
30
45
55
REQUIREMENT ID
1.0
1.0
2.0
2.0
3.0
TCID
2.3
4.6
7.5
8.5
ii)
(two types)
b) Ve test case
iii)
Guide line for the writing GUI test case:Any idea a test engineer with which he feels that we can test something with out doing any
action will follow under GUI test case.
EX: Check for the available of all the object .
Check for the consistence for the object.
Check for the allayment of the object
If at all the customer requirement are given.
Check for the spelling and grammar.
Guide line for the writing the +Ve test case: Test engineer should have +Ve mind set.
He should consider the +Ve flow of the application
He must use only the valid input from the point of the functionality.
Requir Test
ement
case
Id
Cat
ego
ry
Prere
quisit
e
Description\T
est steps
C001
-NA+Ve
Expected value
Invok
e the
applic
ation.
Test
Login
screen
should be
display
LOT
Check
for the
availa
36
All the
object
must be
data
Actual value
Login screen
display.
C002
GUI
-NA-
C003
GUI
-NA
C004
GUI
-NA
C005
GUI
-NA
C006
GUI
-NA-
C007
GUI
-NA-
bility
of all
the
object
ive in
login
screen
as for
the
LOT.
Check
for the
canoni
stic of
all the
object
in the
login
screen
.
Check
for the
spellin
g in
the
login
screen
.
Check
for the
initial
positi
on of
the
cursor.
Check
for the
enable
propri
ety of
login,
clear,
and
cancle
button
.
Enter
some
infor
matio
n into
any of
the
filed
available
login
screen as
for the
LOT.
All the
Objects
must be
consistent
with each
other.
Initially the
cursor positi
the connect
fields.
Login, clear
cancel butto
to enable.
All the
spelling
must be
correct.
Initially
the cursor
must
position in
the user
name.
Initially
login,
clearly
button
must be
disable
and cancle
button
must be
enabled.
37
Clear
button
must be
enable.
Clear button
enable.
Login button
enable.
C008
GUI
-NA-
C009
GUI
-NA-
C010
GUI
-NA-
and
check
for the
enable
priorit
y of
clear
button
Enter
some
infor
matio
n into
both
user
name
passw
ord
fields
and
check
for the
enable
propri
ety of
login
button
.
Enter
the
user
name ,
passw
ord, as
for the
VIT
and
click
on
login
button
.
Enter
the
user
name ,
passw
ord, as
for the
VIT
select
data
based
opecti
Correspondi
page displac
per the VIT
Correspondi
page displac
per the VIT
mentioned th
data based.
Login screen
close.
Tabing orde
follows user
password co
to login canc
clear.
Correspondi
error messag
not as per th
IVIT.
Login
button
must be
enable.
VIT
Correspon
ding page
be must be
displayed
as per
the VIT.
Correspon
ding page
be must be
displayed
VIT
as per the
VIT with
the
mentioned
data base
connectio
n.
38
All the
fields
must be
cleared
C011
GUI
-NA-
C012
GUI
-NA
C013
GUI
C014
-NA-
C015
GUI
and curser
should be
displayed
in the user
name field
.
-NA
Check
for the
tabing
order
of the
object
.
Enter
the
user
name ,
passw
ord as
per
the
IVIT
and
click
on
login
button
.
Enter
39
Login button
enable.
Login button
enable.
Login
screen
closed.
Tabing
order must
be
follows.
(user
name
password
connect to
login
cancle
clear )
Correspon
ding error
message
be display
as per
IVIT.
Login
button
must be
disable.
-NA
GUI
on and
click
on
login
button
.
Enter
some
infor
matio
n into
any of
the
fields
and
click
on
clear
button
.
Click
in the
cancle
button
.
IVIT
C016
-NA-
some
infor
matio
n only
into
the
user
name
field
and
click
for the
enable
propri
ety
login
button
.
Enter
some
infor
matio
n only
into
the
passw
ord
filed
and
check
for the
enable
proper
ty
login
button
.
Login
button
must be
disable.
S.No
Object Name
Object Type
User name
Text box
Password
Text box
Connect to
Combo box
Login
Button
Clear
40
Button
Cancel
Button
User Name
Password
Suresh
QTP
Nag
Amal
Chiru
Sridevi
Ntr
Venky
Admin
Excepted
Value
Admin page
Home page
Home page
Balakrishna
Illu
Admin
Actual Value
Result
Admin page
Pass
Nag home
page
Pass
Chiru home
page
Pass
Ntr home
page
Pass
Home page
Pass
Home page
Venky home
page
Admin page
Admin page
Expected
Page
Actual Value
Result
Admin page
Fail
Pass
User Name
Password
Sure
Qtp
Invalid user
name plz tray
again
Invalid user
41
Chirutha
Sridevi
Ntr
Balakr
Nag
Tab
Jvreddy
Upendra
JVR
Invalid user
name and
password plz
tray again
Anu
Plz entry
valid user
name
pass
Plz entry
valid
Password
pass
Plz entry
valid
Password
Plz entry
valid User
name
Pass
Fail
Fail
Invalid
password plz
tray again
Guide line for the writing the Ve test case : Test engineer should have Ve mind set.
He should consider the Ve flow of the application
He must at list one invalid input in each set of data.
Test execution phase:- In this phase test engineer will do the following.
He will perform the action as it is described in the description Colum.
He will observer the actual behavior of the application.
He will document observer value under the actual value Colum.
Result analysis :- In this phase test engineer will compare the expected value with actual values and
if both are matching they will decide result as pass other wise fail.
If at all the test if not executed then they will decide the result as blocked.
Bug tracking:- Bug tracking is processes which defect are isolate, identify, and managed.
42
Def
ect
Te
st
ca
se
ID
C0
05
C0
06
C0
11
Issue
descript
ion
Initially
the
cursor is
position
ed in the
connect
to filed .
Initially
login
and
clear
button
are
enable
instead
of begin
display.
Upon
clicking
on clear
button
all the
field are
clear but
the
cursor is
nit
position
in the
user
name
Reprod
ucible
Not
applicab
le
Not
applicab
le.
B
y
J
v
r
>observ
e that all
Bu
ild
Vers
ion
2.3.6
2.3.6
2.3.6
J
v
r
>Enter
some
informat
ion any
of
fields.
>click
on clear
button.
D
at
e
J
v
r
43
Defe
ct
Defe
ct
Seve
rity
Prio
rity
Defect
Resol
ution
F
ix
B
y
Fi
x
da
te
Fi
x
bu
ild
Dat
a
Clo
ser
filed.
4
C0
14
5
C0
15
Upon
entering
user
name,
passwor
d as per
DIVT
and
clicking
on login
button
correspo
nding
error
message
are not
display
as per
the
DIVT.
Upon
entering
some
informat
ion
the
fields
are
cleared
but the
cursor is
not
display
in the
user
name.
1
>Enter
user
name
DVIT.
>Enter
the
passwor
d DVIT.
2.3.6
J
v
r
>Click
on login
button
>observ
e that
correspo
nding
error
message
is not
display
the
DVIT.
1
2.3.6
>Enter
some
44
C0
16
Only
into user
name
field
(or)
only
into
passwor
d filed
login
button
is
enabled
misted
of
display.
only
into user
name
filed
only
into the
passwor
d filed.
J
v
r
>
observe
that
login
button is
enable
instead
of being
display.
2.3.6
J
v
r
45
S.No
User Name
Password
Expect
Actual Value
Suresh
QTP
Uma
Jvr
Uprndra
Anu
Defect ID:- The sequence of the defect no will be mentioned her in this section.
Test case ID:- The test case id based on the which defect is found will be mentioned her in
this section.
Issue Description:- What exactly the defect is will be clearly described here in this section.
Reproducible stops:- The list of all the step which are followed by the test engineer in
order to identify the feature will be mention here in this section.
Defection By:- The name of test engineer who has the defect are defect in this section.
Defection Date:- The date are on which will be mention her in this section.
Defection Build:- The build number in which the defect will be mention in this section.
Defection Version:- The version number in which the defect is found will be mention in this section.
Severity:- Severity describes the severity of the defect severity is classified in to 4 types.
Fatal
Fatal:- It at all the related to the navigational block on available by of main functionality then such
type of problems are treated as fatal defects.
EX:-
Page
1
Page
3
Page
2
Val1
Val2
Result
46
Page
4
Not
open
ing
Add
Major defect:- If at all the problem are related to the working the major functionality them such type
of problem are treated a major defect.
EX:Val 1
10
Val 2
20
Result
-10
add
Minor Defect :-If at all the problem some related to the and feel of the application then such type of
problem are treated as minor defect.
Ex:Val 1
Val 2
Result
BAD
Suggestion :- If at all the problem are related to the value of the application then such type of
problems are treated as suggestion.
Ex:-
$
Not user friendly message
+Ve
User friendly
message
Priority :- Priority describes the sequence in which defect need to be rectify.
Priority is classified in to 4 types.
i)
ii)
iii)
iv)
Generally the fatal defect will be given critical priority, major defect will be given, high
priority, minor defect will be given medium priority, but dependence on the situation priority
will be changed.
Low severity high priority case:When ever there is a customer visit all the look and feel defects will be given highest priority
even though they are less serious.
High severity low priority case:When ever some part of model if development, reminding part is testing
department, the test engineer will raise that part is fatal issue but the development will given
low priority given it.
Hold
Require
ment
Rejected
No
As per design
Developer
New
No
Is defect
really
Application
rectificati
on If
Testing
defect
Is it
really a
defect
48
Yes
Open
Rectification
Yes
Fixed
Build 1
Yes
Build 2
No
Re opened
New:- When ever the defect is newly identified by the test engineer then the status is new.
Open:- When ever the developer the accepts then
Deferred:- When ever the developer the accepts the defect but wants some time for rectifying
the defect the will set the status is deferred.
Fixed:- When ever the defect is rectified the developer will set the status as fixed.
Reopened and Close:- Once the next build released the test engineer will check whether
defect is relay rectified (or)not if at all they feel relay rectified then they will set the status as
closed other wise reopened.
Hold:- When ever the developer is configured to accept or reject the defect they will set the
status is hold.
When ever the defect is hold status as they will be a meeting on that defect (Triage
meeting) and if at all consoled as a defect the developer will open it other wise the tester will closed it.
Rejected:-When ever the developer is conformed it is not a defect there he will status is
rejected.
When ever the defect is rejected status the test engineer will once again check if at all he
also feels it is a not a defect then he will set the status as closed other he will reopened.
As per design:- (it is a rare case only)
49
When ever the developer feels the tester has raised the defect with out having
knowledge of latest requirement then he will check the status as As per design.
When ever the defect in as per design status the test engineer will go to the new
requirement if at all he also feel it is as per design only then he will set the status is closed
other wise reopened.
Reporting phase:Classical Bug reporting process :Test lead
Develop lead
Tester
Developers
Draw Back:
Redundancy
Time consuming
No transparency
No security
Test lead
Common repository
50
Develop lead
BTT
Bug tracking tools :- Bug tracking tool is soft ware application which can be accessed only by the
etherized people which provides all the facility for bug tracking tools.
EX:- Bug zilla, issues tracking
Test closer Activity :- This a finely activity done in the process the test summary report which
contain some following information .
No.of cycles execution.
Devotion in of each cycle.
No.of test case are execution in which cycle.
No.of test case are passed are failed .
No.of defect are found in each cycle and extra.
Way of testing:- there or two type.
i)
ii)
Manual testing.
Automation testing.
Manual testing:- Manual testing is a process in which all the phase of software testing life cycle like
test planning, test development, test execution, result analysis, bug tracking and report or accomplish
successful manually with human efforts.
51
52