Software Test Estimation

Company Logo
Test Estimation Framework
Prepared by/Modified by
Role
Test Manager
Date of
preparation/
Modification
dd/mmm/yyyy
Reviewed by
Role
Date of Review
Reviewer 1
Reviewer 2
Approved by
Project Manager
Test Lead
Role
dd/mmm/yyyy
Date of Approval
dd/mmm/yyyy
Head
Circulation List
Group1, Group2
Version number
of the work
product
1.0
Company Title/Name
Company Internal
Company Title/Name
Project Name
TABLE OF CONTENTS
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Date
Introduction.................................................................................................................................... 3
Objective......................................................................................................................................... 3
ProjectName Test Activities.......................................................................................................... 4
Size Estimation.............................................................................................................................. 6
Productivity.................................................................................................................................... 8
Effort Estimation.......................................................................................................................... 10
Conclusion................................................................................................................................... 14
Assumptions................................................................................................................................ 14
Appendix....................................................................................................................................... 14
Revision History........................................................................................................................... 15
Version 1.0
Page 2 of 15
Company Title/Name
Project Name
1.
Introduction
Testing is the mechanism by which defects can be found during execution of the application, which are
undetected during reviews in different stages of software development.
This document is an attempt to come out with test estimation framework that has a sound basis and
which is more aligned to ProjectName testing requirements.
The proposed estimation framework is based on the current set of testing activities carried out as part of
ProjectName testing. If the activities change [scope, no. Of activities, type of activities etc] in future,
the estimation framework has to be modified as appropriate.
2.
Objective
This document introduces an estimation framework for ProjectName testing activities. The goal of this
estimation framework is to:
Identify the major testing activities that are carried out as a part of ProjectName testing.
Arrive at Size estimation for each work product pertaining to all the testing activities.
Based on empirical data, compute productivity for each work product pertaining to all the testing
activities.
Arrive at Effort estimation for each work product pertaining to all the testing activities.
Date
Version 1.0
Page 3 of 15
Company Title/Name
3.
Project Name
ProjectName
Test Activities
The following table provides the list of testing activities that are carried out in ProjectName during the various
ProjectName-PLM stages. The White Box activities are newly identified for future needs.
Project
Name
Test Activities
Comments
M0
None
ProjectName Test team is not involved in this
M1
Understanding SRD/PRD and FS
M1
Prepare Master Test plan
M1
Review Master Test Plan
M2
Black Box Testing: Prepare functional test

plan
Review functional test plan
PLM
Stage
M2
M2
Black Box Testing: Prepare Functional Test

Case documents
M2
White Box Testing: Design of test cases
M2
Prepare QTP Scripts: Black Box Test cases.
M2
Review and Update Functional Test Case

documents.
M2/M3
Prepare Test Data
M3
White Box Testing: implementation of test

code
M3
Setting up Test Environment
Date
phase.
Identify test requirement by going through
SRD/PRD, FS documents and participating in
relevant Fagan reviews / JAD sessions.
Contains test requirements [Functional /
Performance / Security / Compatibility] for the
product, test strategy, test environment, overall
test schedule and plan.
Review for completeness based on test
requirements
Functional test plan is prepared for critical
features of the product.
Review for completeness based on functional
test requirements
It contains test cases pertaining to all test
requirements (PRD/SRD)
It also traces the test cases to product
requirements (PRD/SRD)
Create unit test design document
(The JUNIT test framework can be used for
testing Java code)
Identify features, which can be automated using
QTP.
Define Actions and data sets for the identified
features
Identify Workflows
Create/Update Global Object File
Create QTP Scripts (VBScript)VB (according to
data driven test technique)
Add checkpoints and update shared object
repository
Integrate in the QTP framework
Read the updated requirements document or
PCR
Update the traceability matrix
Identify and remove Obsolete test cases
Identify Updates to existing test cases
Identify new test cases
Read the test case doc(Functional, Performance,
Security, Compatibility)
Identify the data requirement for each kind of
testing
Coding of white box test cases using JUnit
framework.
Creation of test data sets for white box testing
Setup Performance test environment
Setup Functional test environment
Setup Unit test environment
Setup Integration test environment
Version 1.0
Page 4 of 15
Company Title/Name
Project
Name
Project Name
Test Activities
Comments
M3
Execute manual Functional Test Cases for

Desktop.
M3
M3
Execute QTP scripts (Functional Test Cases)

for Desktop.
Execute manual Functional Test Cases for
Devices.
Execute QTP scripts (Functional Test Cases)
for Devices.
Performance testing using Spider tool.
Set the test environment

Configure user
Execute the tests
Set the test Framework
Execute the tests
Configure Devices
Execute the tests
Using device simulators / browsers on desktop.
M3
Perform V&V (Verification & Validation)
M3
Perform incremental & regression testing
M3
Log and Report Test execution results.
M3
M4/M5
Defect Triage involvement

None
PLM
Stage
M3
M3
Date
Identify no. of users to be simulated

Create Spider Sessions (50 user/ session is limit)
Execute the tests
Go through V&V bugs that are fixed
Identify V&V tests
Setup Test Environment
Execute V&V tests
Go through regression bugs that are fixed
Identify regression tests
Setup Test Environment
Execute regression tests
Bugs are filed in the defect tracking system Bugzilla. Provide test summary reports in the
form of an excel sheet.
Participation in defect prioritization.
ProjectName Test team is not involved in this
phase.
Version 1.0
Page 5 of 15
Company Title/Name
Project Name
4.
Size Estimation
In this section we have come out with the definition of Size for each of the test activities identified in the previous
section.
Project
Name
Test Activities
Activities for arriving at Sizing /

Work Product Items
Work
size
M1
None (ProjectName Test team is

not involved in this phase.)
N/A
Master Test Plan document
will contain high level
1) Test requirements [Functional /
Performance /
Security / Compatibility],
2) Test Strategy,
3) Test Environment,
4) QA Review Plan,
5) Resourcing &
6) Scheduling.
Review Record
N/A
M1
M1
None (ProjectName Test team

is not involved in this phase.)
Understanding SRD/PRD and FS
M2
Black Box Testing: Prepare

functional test plan
M2
M2

Functional Test Cases. (for a
given feature.)
M2
White Box Testing: Design of test

cases
M2
Prepare QTP Scripts: Black Box

Test cases.
product
PLM
Stage
M0
Date
(1) Identify test items (Usually one

test item per use case) for a given
use case.
(2) Identify test scenarios for each of
the test item. (Typically there are at
least three scenarios for a given test
item viz. Functional test scenario,
Alternate test scenario, Exceptional
test scenario. For example in some
cases, there will be multiple sets of
the above three test scenario
categories.)
(3) Identify and compute number of
test cases under each scenario
depending on the corresponding test
requirements.
1) Identify the packages, classes or
functions which need white box
testing
2) Identify Asserts in the same.
3)Design a fixture or test suite for the
same
4)Create unit test design document
Identify Workflow
Identify number of unique actions
(one action equivalent to test case)
Associate actions with workflow.
Version 1.0
N/A
Sizing not
applicable ( To
obtain data based
on past history )
Sizing not
applicable ( To
obtain data based
on past history )
Sizing not
applicable ( To
obtain data based
on past history )
Sizing not
applicable ( To
obtain data based
on past history )
Total # of test
cases / tests
Total # of Asserts
per class
Total # of i/o for
total no. of test
cases(Asserts)
Per class
QTP Source Lines
Of Code.
Page 6 of 15
Company Title/Name
Project
Name
Test Activities
Project Name
Activities for arriving at Sizing /

Work Product Items
Work
size
product
PLM
Stage
M2
Review and Update Functional

Test Case documents.
M2/M3
Prepare Test Data [user data

creation, content data creation
etc.]
White Box Testing:
implementation of test code
M3
M3
M3
Execute Functional Test Cases
M3
M3
M3
M3
Performance testing
M3
Perform V&V (Verification &

Validation)
Perform incremental &
regression testing
M3
Arrive at SLOC based on actions.

Review regression suite
Update regression suite
Review functional test case
Update functional test case
Pst files, nsf files, attachments of
various application types, QTP scripts
for user data generation
Coding of white box test cases using
JUnit framework.
Creation of test data sets for white
box testing (The JUNIT test
framework can be used for testing
Java code)
Desktop Test Execution
Execute QTP scripts (Functional Test
Cases) for Desktop.
Device Test Execution
Execute QTP scripts (Functional Test
Cases) for Devices.
1) Identify product areas whose
throughput will be tested
2) Identify product areas which will
stress tested
3) Identify product areas which will
Load tested
V&V test report
Regression test report
M3
Log and Report Test execution

results.
Updated bugzilla defect entries &

consolidate test reports
M3
M4/M5
None (ProjectName Test team

is not involved in this phase.)
N/A (ProjectName Test team is not

involved in this phase.)
Date
Version 1.0
Total # of
regression test
cases
Total # of
functional test
cases
Sizing not
applicable
Java Source lines
of code
OR
# of JUnit Classes
Sizing not
applicable
Total # of executed
test cases
Total # of executed
test cases
Total # of executed
test cases
Total # of executed
test cases
Delphi technique
will be used
Total # of executed
V&V test cases
Total # of executed
regression test
cases
Total # of defects
updated / added in
bugzilla
Sizing not
applicable
N/A
Page 7 of 15
Company Title/Name
Project Name
5.
Productivity
This section outlines the productivity for the test activities, which are carried out at ProjectName. The data was
computed based on empirical data based on Razor & Unifi releases in the past. The productivity figures are based
on average productivity viz. Averaged out across complexities of requirements.
Proje
ctNa
me
Test Activities
Work Product Items
Average Productivity
None (ProjectName Test

team is not involved in this
phase.)
Understanding SRD/PRD and
FS
N/A
N/A
N/A
N/A

functional test plan
Functional Test Cases. (For a
given feature.)
Master Test Plan document

Review Record
Functional Test Plan document
N/A
N/A
N/A
Review Record
1) Identify test items (Usually one
test item per use case) for a given
use case.
(2) Identify test scenarios for each of
the test item. (Typically there are at
least three scenarios for a given test
item viz. Functional test scenario,
Alternate test scenario, Exceptional
test scenario. For example in some
cases, there will be multiple sets of
the above three test scenario
categories.)
(3) Identify number of test cases
under each scenario depending on
the corresponding test requirements.
1) Document which will no. of
packages, classes and function to be
tested with Assert candidate
And I/O details
(1) Identify Workflow (2) Identify
number of unique actions (one action
equivalent to test case) (3) Associate
actions with workflow. (4) Arrive at
SLOC based on actions.
Update functional test case
N/A
3 to 4 test cases per hr
(For writing test cases )
PLM
Stage
M0
M1
M1
M1
M2
M2
M2
M2
White Box Testing: Design of

test cases
M2
Prepare QTP Scripts. (Black

Box Test cases.)
M2
Review and Update Functional

Test Case documents.
Prepare Test Data [user data
creation, content data creation
etc.]
White Box Testing:
implementation of test code
M2/M
3
M3
M3
M3

- Manual Testing on Desktop
Date
Pst files, nsf files, attachments of

various application types, QTP
scripts for user data generation
1) JUnit source code
Desktop Test Execution (Manual
Testing)
Version 1.0
3 to 4 Classes per hour
10 QTP Source Lines

of Code per hour.
3 to 4 test case per

hour
20 email or PIM data /
hour
20 Admin setting / hour
60 Lines of JUnit
Code/Day with (all
asserts and comments)
N/A
5 to 6 test cases
execution per hour.
Page 8 of 15
Company Title/Name
Proje
ctNa
me
Project Name
Test Activities
Work Product Items
Average Productivity
M3

- Automated Testing on
Desktop
Desktop Test Execution (Automated

Testing)
40 to 50 test cases
execution per hour.
M3

Manual Testing on Devices
Device Test Execution (Manual

Testing)
3 to 4 test cases
execution per hour
M3

Automated Testing on
Devices
Device Test Execution (Automated

Testing)
M3
Performance testing
M3

Validation (Manual Desktop
Testing)
Validation (Manual Device
Testing)
regression testing Desktop,
Manual testing.
regression testing Desktop,
Automated testing.
regression testing Device,
Manual testing.
regression testing Device,
Automated testing.
Test Reports for transaction latencies

Test reports for maximum load
Test report for optimal Configuration
V&V test report
Note: QTP scripting on

device emulators is
work in progress. Right
now productivity data
not available.
5 to 6 test cases
execution per hour
PLM
Stage
M3
M3
M3
M3
M3
V&V test report
3 to 4 test cases
execution per hour
Test Summary report
5 to 6 test cases
execution per hour.
Test Summary report
40 to 50 test cases
execution per hour.
Test Summary report
3 to 4 test cases
execution per hour
Test Summary report
Note: QTP scripting on

device emulators is
work in progress. Right
now productivity data
not available.
4-5 defects / hr
[bugzilla entries /
updates]
Productivity not
applicable
N/A (ProjectName
Test team is not
M3
Log and Report Test execution

results.
Updated bugzilla defect entries &

consolidate test reports
M3
M4/M
5
None (ProjectName Test

team is not involved in this
phase.)
N/A (ProjectName Test team is not

Date
5 to 6 test cases
execution per hour.
Version 1.0
Page 9 of 15
Company Title/Name
Project Name
6.
Effort Estimation
Once the size of each work product is estimated (as outlined in previous section), the next step is to arrive at the
effort in person hours. There are two scenarios here: One scenario where we have the empirical data for the
Productivity for the activities and the other where we do not have any empirical data. In the second scenario, we
have to rely on Wide Band Delphi Technique for estimation. This technique for arriving at effort estimation is based
on effort estimates arrived independently by three engineers and consolidating them in a effort estimate meeting
chaired by a moderator.
Proje
ctNa
me
Test Activities
Work Product Items
Size Units
[A]
Productivity
[B]
Effort in
Hours.
Person
None
(ProjectNam
e Test team is
not involved in
this phase.)
Understanding
SRD/PRD and
FS
N/A
N/A
N/A
N/A
Total # of test
requirements [Functional
+ Performance +
Security + Compatibility]
N/A
N/A
M1
Prepare
Master Test
Plan
Test requirements, Test

Strategy, Test
Environment, QA Review
Plan, Resourcing &
Scheduling.
N/A
N/A
M1
Review Master
Test Plan
Review Record
N/A
N/A
M2
Black Box
Testing:
Prepare
functional test
plan
Functional Test Plan

document
N/A
N/A
M2
Review
functional test
plan
Review Record
N/A
N/A
This will be computed

at the start of M1.
The estimates
depend on size of the
SRD/PRD/FS items.
The effort estimates
are based on Wide
Band Delphi
Technique ( Effort
estimates computed
separately by three
engineers )
at the start of M1.
The estimates
SRD/PRD/FS items.
are based on Wide
Band Delphi
Technique ( Effort
estimates computed
separately by three
engineers )
are based on Wide
Band Delphi
Technique ( Effort
estimates computed
separately by three
engineers )
are based on Wide
Band Delphi
Technique ( Effort
estimates computed
separately by three
engineers )
are based on Wide
Band Delphi
Technique (Effort
estimates computed
separately by three
engineers)
PLM
Stage
M0
M1
Date
Version 1.0
Page 10 of 15
Company Title/Name
Proje
ctNa
me
Project Name
Test Activities
Work Product Items
Size Units
[A]
Productivity
[B]
Effort in
Hours.
Person
M2
Black Box
Testing:
Prepare
Functional Test
Case
documents.
Total
number of
test cases /
tests
3 to 4 test cases
/ tests per hour.
[A] Divided by [B] will

provide the effort in
person hours.
M2
White Box
Testing:
Design of test
cases
(1) Identify test items

(Usually one test item per
use case) for a given use
case.
(2) Identify test scenarios
for each of the test item.
(Typically there are at
least three scenarios for a
given test item viz.
Functional test scenario,
Alternate test scenario,
Exceptional test scenario.
For example in some
cases, there will be
multiple sets of the above
three test scenario
categories.)
(3) Identify and compute
number of test cases
under each scenario
depending on the
corresponding test
requirements.
1) Identify the packages,
classes or functions which
need white box testing
2) Identify Asserts in the
same.
3) Design a fixture or test
suite for the same
4) Identify whether
specific input/output
needs for testing if yes
then verify if any other
framework can be utilized
(e.g. Cactus Framework)
Total # of
Asserts per
class (A1)
3 to 4 Classes
per hour

person hours
PLM
Stage
M2
M2
M2/M
3
M3
Date
Prepare QTP
Scripts. (Black
Box Test
cases.)
Review and
Update
Functional Test
Case
documents.
Prepare Test
Data [user
data creation,
content data
creation etc.]
White Box
Testing:
(1) Identify Workflow (2)

Identify number of unique
actions (one action
equivalent to test case) (3)
Associate actions with
workflow. (4) Arrive at
SLOC based on actions.
Update functional test
case
Total # of
i/o for total
no. of test
cases(Asse
rts)
Per class
(A2)
Here
A=A1+A2
Total QTP
Source
Lines of
Code
Total
number of
test cases
( Here A=A1+A2 )
10 QTP Source
Lines of Code
per hour.
(Based on past
three months
empirical data)
3 to 4 tests per
hour
Pst files, nsf files,

attachments of various
application types, QTP
scripts for user data
generation
N/A
N/A
1) JUnit source code
# of JUnit
Classes
60 Lines of
JUnit Code/Day
Version 1.0

person hours.

person hours
at the start of M3.
The estimates
SRD/PRD/FS items.
are based on Delphi
Technique (Effort
estimates computed
separately by three
engineers)
Page 11 of 15
Company Title/Name
Proje
ctNa
me
Test Activities
Project Name
Work Product Items
Size Units
[A]
Productivity
[B]
Effort in
Hours.
Person
person hours
Setup Performance test

environment
Setup Functional test
environment
Setup Unit test
environment
Setup Integration test
environment
N/A
with (all asserts

and comments)
N/A
Execute
Functional Test
Cases Manual Testing
on Desktop
Execute
Functional Test
Cases
Manual Testing
on Devices
Execute
Functional Test
Cases Automated
Testing on
Desktop
Execute
Functional Test
Cases
Automated
Testing on
Devices

(Manual Testing)
No of test
cases
executed
per hour.
5 to 6 test cases
execution per
hour.
The estimates
SRD/PRD/FS items.
are based on Delphi
Technique (Effort
estimates computed
separately by three
engineers)
person hours.

(Manual Testing)
No of test
cases
executed
per hour.
3 to 4 test cases
execution per
hour

person hours.

(Automated Testing)
No of test
cases
executed
per hour.

person hours.

(Automated Testing)
No of test
cases
executed
per hour.
M3
Performance
testing
Test Reports for

transaction latencies
M3
Perform V&V
(Verification &
Validation
(Manual
Desktop
Testing)
Perform V&V
(Verification &
Validation
(Manual
Device
Testing)
Perform
incremental &
regression
testing
Desktop,
Manual
testing..
Perform
incremental &
regression
V&V test report
Delphi
technique
will be used
No of test
cases
executed
per hour.
40 - 50 test
cases execution
per hour.
( Based on past
three months
empirical data )
Note: QTP
scripting on
device
emulators is
work in
progress. Right
now productivity
data not
available.
5 to 6 test cases
execution per
hour
5 to 6 test cases
execution per
hour.
PLM
Stage
M3
M3
M3
M3
M3
M3
M3
M3
Date
implementation
of test code
Setting up Test
Environment
Note: QTP scripting

on device emulators
is work in progress.
Right now productivity
data not available

person hours
person hours.
V&V test report
No of test
cases
executed
per hour.
3 to 4 test cases
execution per
hour

person hours.
Test Summary report
No of test
cases
executed
per hour.
5 to 6 test
cases execution
per hour.

person hours.
Test Summary report
No of test
cases
executed
40 to 50 test
cases execution
per hour.

person hours.
Version 1.0
Page 12 of 15
Company Title/Name
Proje
ctNa
me
Test Activities
Project Name
Work Product Items
Size Units
[A]
Productivity
[B]
Effort in
Hours.
Person
PLM
Stage
M3
M3
M3
testing
Desktop,
Automated
testing.
Perform
incremental &
regression
testing Device,
Manual testing.
(Only for
Maintenance
cycles) Device,
Manual testing.
Perform
incremental &
regression
testing (Only
for
Maintenance
cycles) Device,
Automated
testing.
Log and
Report Test
execution
results.
per hour.
Test Summary report
No of test
cases
executed
per hour.
3 to 4 test cases
execution per
hour

person hours.
Test Summary report
No of test
cases
executed
per hour.
Note: QTP scripting

on device emulators
is work in progress.
Right now productivity
data not available
Updated bugzilla defect

entries & consolidate test
reports
Total # of
defects
updated /
added in
bugzilla
N/A
Note: QTP
scripting on
device
emulators is
work in
progress. Right
now productivity
data not
available
4-5 defects / hr
[bugzilla
entries /
updates]
N/A
Total Effort varies

depending on the
number of
Bugs/CRs/Enhancem
ents. ( It also depends
on the number of
participants in this
activity )
N/A
M3
Defect Triage
involvement
Participation in defect
prioritization.
M4/M
5
None
(ProjectNam
e Test team is
not involved in
this phase.)
None (ProjectName
Test team is not involved
in this phase.)
Date
N/A
Version 1.0
N/A

person hours.
Page 13 of 15
Company Title/Name
Project Name
7.
Conclusion
With the proposed Test Estimation framework for ProjectName-QA in place, the following improvements
can be expected:
The testing team will be able to arrive at a close-to accurate estimate, which will allow it to predict and
manage schedules effectively.
The proposed estimation framework is based on the current set of testing activities carried out as part of
ProjectName testing. If the activities change [scope, number of activities, type of activities etc] in future,
the estimation framework has to be suitably modified.
8.
Assumptions
The estimation framework is for pure Engineering activities. Project management efforts are NOT taken
into account.
9.
Appendix
The ExcelSheet workbook titled ProjectName-TestEstimationWorkBook would be used to capture size,

productivity, effort estimation for each ProjectName-QA activity. This workbook also captures the effort
summary for all the QA activities for a given project in the second worksheet.
Glossary:
The following are a list of glossary of terms used. (As used in the Unifi Test Case Documents)
Test Cases / Tests: This is lowest possible testing unit, denotes one unique action (with input data variations)
according to ProjectName usage.
Test Data: Data that is used for carrying out testing (Manual or Automated). For example, test data pertains to
Email content, PIM content or Admin Settings for ProjectName One Business Server.
Workflow: It is defined as a set of test items, which have corresponding QTP scripts. Each QTP script represents
an automated test scenario.
Date
Version 1.0
Page 14 of 15
Company Title/Name
Project Name
10.
Revision History
Section
Changed
Change Description
Revision Date
Version
Number
Reviewed
by
Approved
by
Initial
Initial Version
dd mmm yyyy
Draft 1.0
Testmanager
/ProjectMan
ager
DeliveryM
anager
Date
Version 1.0
Page 15 of 15

Software Test Estimation

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Software Test Estimation

Transféré par

Droits d'auteur :

Formats disponibles

Company Logo

Test Estimation Framework

ProjectName Test team is not involved in this

Understanding SRD/PRD and FS

Prepare Master Test plan

Review Master Test Plan

Black Box Testing: Prepare functional test

Black Box Testing: Prepare Functional Test

White Box Testing: Design of test cases

Prepare QTP Scripts: Black Box Test cases.

Review and Update Functional Test Case

Prepare Test Data

White Box Testing: implementation of test

Setting up Test Environment

Execute manual Functional Test Cases for

Execute QTP scripts (Functional Test Cases)

Set the test environment

Perform V&V (Verification & Validation)

Perform incremental & regression testing

Log and Report Test execution results.

Defect Triage involvement

Identify no. of users to be simulated

Activities for arriving at Sizing /

Review Master Test Plan

None (ProjectName Test team is

None (ProjectName Test team

Black Box Testing: Prepare

Review functional test plan

Black Box Testing: Prepare

White Box Testing: Design of test

Prepare QTP Scripts: Black Box

(1) Identify test items (Usually one

Activities for arriving at Sizing /

Review and Update Functional

Prepare Test Data [user data

Setting up Test Environment

Execute Functional Test Cases

Execute Functional Test Cases

Execute Functional Test Cases

Execute Functional Test Cases

Perform V&V (Verification &

Arrive at SLOC based on actions.

Log and Report Test execution

Updated bugzilla defect entries &

Defect Triage involvement

Participation in defect prioritization.

None (ProjectName Test team

N/A (ProjectName Test team is not

Work Product Items

None (ProjectName Test

Prepare Master Test plan

Master Test Plan document

White Box Testing: Design of

Prepare QTP Scripts. (Black

Review and Update Functional

Setting up Test Environment

Execute Functional Test Cases

Pst files, nsf files, attachments of

3 to 4 Classes per hour

10 QTP Source Lines

3 to 4 test case per

Work Product Items

Execute Functional Test Cases

Desktop Test Execution (Automated