3. TABLE OF CONTENTS
1. INTRODUCTION.....................................................................................................................................................4
1.1 TEST OBJECTIVE*..................................................................................................................................................4
1.2 SUMMARY OF TEST OBJECTIVE: THE FOLLOWING MATRIX LAYS OUT THE LIST OF ALL THE TEST ITEMS: ..........4
1.3 PROJECT OVERVIEW
.....................................................................................................................................................................................9
1.3 SCOPE....................................................................................................................................................................9
1.4 COVERED DURING TESTING................................................................................................................................10
2. ENTRY AND EXIT CRITERIA...........................................................................................................................10
2.1 ENTRY CRITERIA.................................................................................................................................................10
2.2 EXIT CRITERIA.....................................................................................................................................................11
2.3 DATA...................................................................................................................................................................12
2.4 FACILITIES...........................................................................................................................................................12
3. DEPENDENCIES...................................................................................................................................................12
3.1 DEPENDENCIES....................................................................................................................................................12
3.2 ASSUMPTIONS AND RISK ASSESSMENT...............................................................................................................13
4. FUNCTIONAL TESTS IN SCOPE ......................................................................................................................18
5. TESTS OUT OF SCOPE........................................................................................................................................19
6. TEST APPROACH.................................................................................................................................................20
6.1 FUNCTIONAL TEST...............................................................................................................................................20
6.2 REGRESSION TEST...............................................................................................................................................21
7. ENVIRONMENTAL NEEDS................................................................................................................................22
7.1 ROLES & RESPONSIBILITIES................................................................................................................................22
7.2 TEST ENVIRONMENT BASE SYSTEM HARDWARE / SOFTWARE...........................................................................22
7.3 TEST ENVIRONMENT CONFIGURATIONS..............................................................................................................23
7.4 TEST TOOLS.........................................................................................................................................................24
8. COMMUNICATION..............................................................................................................................................25
8.1.1 Escalation Process.......................................................................................................................................26
9. CONTACT INFORMATION................................................................................................................................26
10. PROBLEM REPORTING, ESCALATION AND ISSUE RESOLUTION.....................................................26
11. MILESTONES AND SCHEDULE SUMMARY...............................................................................................26
12. DELIVERABLES.................................................................................................................................................27
12.1 TEST ARTIFACTS AND LOCATION......................................................................................................................27
12.2 REFERENCES......................................................................................................................................................27
13. APPROVAL AND SIGN OFF............................................................................................................................28
14. APPENDIX............................................................................................................................................................28
14.1 GLOSSARY.........................................................................................................................................................28
Page 3
4. 1. Introduction
1.1 Test Objective*
The purpose of this Test Plan is to provide a detailed outline of the testing process,
approach and methodology that will be utilized to organize and manage the functional
test for the Monday 11/08/2010 release of Enterprise Referral UI Phase 3 which
includes Sales force Catcher and Sales force Pitcher. The audience for this document is
the ML tech team, the ML business team and SFDC.
Testing is expected to be Wednesday 8/25/2010 and finish by Wednesday 9/15/2010.
1.2 Summary of Test Objective: The following matrix lays out the list of
all the test items:
No Test
case
ID
Test Area Test Scenarios Test Cases Prio
rity
Notes
1 TA-
1
Catching:
Referral
sent from
GRE to
SFDC(Bot
h from
FAC and
GCC)
All referrals are sent to SFDC
from the GRE with FA
Assignment (UPN# / SFDC
Username)
Validate All referrals are sent to SFDC
from the GRE with FA Assignment
(UPN# /SFDC Username)
2 TA-
1
Catching:
Referral
sent from
GRE to
SFDC(Bot
h from
FAC and
GCC)
All referrals are created in
SFDC as Lead records (Record
Type=Enterprise individual
referrals):
a) FA’s have ability to
convert a referral from
Lead to a client &
Prospect and
Opportunity.
b) I f the FA has an
existing relationship
with the client they
can associate the
referral to their
Validate All referrals are created in
SFDC as Lead records (Records
Type=Enterprise individual referrals)
a) Validate FA’s have ability to
convert a referral from Lead to a
client & Prospect and Opportunity.
b) Validate the FA has an existing
relationship with the client they
can associate the referral to their
existing client & Prospect record
Page 4
5. existing client &
Prospect record
3 TA-
1
Catching:
Referral
sent from
GRE to
SFDC(Bot
h from
FAC and
GCC)
All referrals received by SFDC
from FAC are required to meet
a 48 hour SLA. The
management of the SLA is
handled by the GRE.
a) FA’s who do not meet
the SLA will lose
visibility to the referral
and the referral is sent
to management to re-
assignment.
Validate all referrals received by SFDC
from FAC are required to meet a 48
hour SLA. The management of the
SLA is handled by the GRE.
a) Validate FA’s who do not
meet the SLA will lose
visibility to the referral and the
referral is sent to a
management to re-assignment.
4 TA-
1
Catching:
Referral
sent from
GRE to
SFDC(Bot
h from
FAC and
GCC)
FAC and GCC referrals are
subject to expiration rules. The
management of the expiration
rules is handled by the GRE.
Validate FAC and GCC referrals are
subject to expiration rules. The
management of the expiration rules is
handled by the GRE.
5 TA-
1
Catching:
Referral
sent from
GRE to
SFDC(Bot
h from
FAC and
GCC)
Salesforce send the status
update to the GRE in the
approved Enterprise status
values
Validate Salesforce send the status
update to the GRE in the approved
Enterprise status values
6 TA-
1
Catching:
Referral
sent from
GRE to
SFDC(Bot
h from
FAC and
GCC)
Received referrals are available
for viewing on the leads,
Opportunity and Referrals Tab
Validate Received referrals are
available for viewing on the leads,
Opportunity and Referrals Tab
7 TA-
2
Catching:
UI
Enhanceme
nt
Referral lead list views are the
following:
a) My BAC Referrals
received
b) My Teams BAC
Referrals received
c) My Teams BAC
Referrals received
today
Validate Referral lead list views are the
following:
a) My BAC Referrals received
b) My Teams BAC Referrals
received
c) My Teams BAC Referrals
received today
8 TA-
2
Catching:
UI
Enhanceme
nts
View received Referral (Lead) Validate received referral (Lead)
a) Validate record type=
Enterprise individual referral.
a) Validate page layout= Clone
Page 5
6. of Referral Individual and
modify based on section 6.1 in
HLD
b) Validate the referral coming
from GRE has been
successfully created in
Salesforce as a Lead record
and the fields are in sync
between GRE and SFDC.
c) Validate Help text and lead
conversion mapping using
LLD.
9 TA-
2
Catching:
UI
Enhanceme
nts
SFDC to GRE Field Mapping
Gaps
10 TA-
2
Catching:
UI
Enhanceme
nts
View received referral (Lead)-
Status values.
Validate received referral (Lead)-Status
values.
11 TA-
3
Catching:
Convert a
receive
referral
Convert referral design.
a) Salesforce SCP Lead
to Prospect solution is
need to include the
following update:
i) Remove
options to
not create
an
opportunit
y record
during
conversion
.
Opportunit
ies is
required
for
referrals
Validate convert referral design.
a) Validate Salesforce SCP Lead
to Prospect solution is need to
include the following update:
i) Remove options to
not create an
opportunity record
during conversion.
Opportunities is
required for referrals
12 TA-
4
Catching:
UI
Enhanceme
nts
View converted referral (Client
& Prospect)
a) No new client &
prospect record type or
page layout is
required.
b) Rename the existing
referral information
section to “Most
recent received
referrals information.
i) Each time a
referral is
Validate converted referral (Client &
Prospect)
a) Validate No new client &
prospect record type or page
layout is required.
b) Rename the existing referral
information section to “Most
recent received referrals
information.
i) Validate
each time a
referral is
created it
Page 6
7. created it will
overwrite the
previous
referrals
information
ii) Referral
information is
also available
on the
opportunity.
will
overwrite
the previous
referrals
information.
ii) Validate
Referral
information
is also
available on
the
opportunity.
13 TA-
5
Catching:
UI
Enhanceme
nts
View converted referral
(Opportunity)
a) Create New record
type = Referral
Opportunity.
b) Clone or Standard
opportunity.
c) Create new record
type.
d) Create new page
layout.
e) Clone of Standard
opportunity and
modify.
f) Add a new referral
information section.
Validate converted referral
(Opportunity)
a) Validate create new record
type = Referral Opportunity.
b) Validate Clone or Standard
opportunity.
c) Validate create new record
type.
d) Validate create new page
layout.
e) Validate clone of Standard
opportunity and modify.
f) Validate add a new referral
information section.
14 TA-
6
Catching:
UI
Enhanceme
nts
View converted Referral
Opportunity: Stage Values
Validate converted Referral
Opportunity: Stage Values
15
TA-
7
Catching:
UI
Enhanceme
nts
Referral Opportunity list view.
a) My BAC Referrals
receive
b) My Teams BAC
Referrals receive.
c) My Teams BAC
referrals receive-
closed lost.
d) My Teams BAC
referrals receive –
closed won
Validate Referral Opportunity list view.
a) Validate my BAC Referrals
receive
b) Validate my Teams BAC
Referrals receive.
c) Validate my Teams BAC
referrals receive- closed lost.
d) Validate my Teams BAC
referrals receive – closed won
16 TA-
8
Catching:
Referral
updates
sent to
GRE
The following information are
send back to the GRE for
received referrals:
a) Receiving Associate
UPN#
b) Referral ID
Validate that the following information
has been sent back to the GRE for
received referrals:
a) Validate Associate UPN#
b) Validate referral ID
c) Validate BAC Party ID
Page 7
8. c) BAC Party ID
d) Status (Enterprise
Status Values)
e) Sub Status (Enterprise
Status Values)
d) Validate Status (Enterprise
Status Values)
e) Validate Sub Status
(Enterprise Status Values)
17 TA-
9
Pitching:
Referrals
sent from
SFDC to
GCC
The following are high level
summary of the requirements
for referrals send from SFDC to
the GRE (GCC Only)
a) All referrals are send
from SFDC to GRE
using the company
referral from (Smart
Form)
i) Custom link:
Send a
referral is
only available
on a client &
Prospect
Business
record.
b) Send referrals are
available in a new
related list “Sent
Referrals” on the
client & prospect
business page layout.
c) Send referrals are
available for viewing
on the referrals tab.
Validate that the following are high
level summary of the requirements for
referrals send from SFDC to the GRE
(GCC Only)
a) Validate all referrals are
send from SFDC to GRE
using the company
referral from (Smart
Form)
i) Validate
send a
referral is
only be
available on
a client &
Prospect
Business
record.
b) Validate send referrals are
available in a new related
list “Sent Referrals” on
the client & prospect
business page layout.
c) Validate send referrals are
available for viewing on
the referrals tab.
18 TA-
10
Pitching:
UI
Enhanceme
nts
Viewing pitched referrals.
a) New related list “Sent
referrals” on client &
Prospect business
records.
b) FA should be able to
drill into the referral
record to get
additional referral
information
(Salesforce will create
a new WS for the GRE
to push referral
information to
Salesforce)
Validate pitched referrals.
a) Validate new related list “Sent
referrals” on client & Prospect
business records.
b) Validate FA should be able to
drill into the referral record to
get additional referral
information
(Salesforce will create a new
WS for the GRE to push referral
information to Salesforce)
19 TA-
11
Pitching:
Referral
updates
received
from GRE
The following information is
sent back to the GRE for
received referrals.
a) Receiving Associate
b) Referral ID
c) BAC Party ID
Validate the following information is
sent back to the GRE for received
referrals.
a) Validate receiving Associate
b) Validate referral ID
c) Validate BAC Party ID
Page 8
9. d) Status (Enterprise
Status Values)
e) Sub Status( Enterprise
Status Values)
f) Receiving Associate
Information
g) GCC Associate
Information
d) Validate Status (Enterprise
Status Values)
e) Validate Sub
Status( Enterprise Status
Values)
f) Validate receiving Associate
Information
g) Validate GCC Associate
Information
20 TA-
12
Pitching &
Catching:
UI
Enhanceme
nts
Viewing referrals from the
referrals tab.
a) New referrals tab
is available for all
users.
b) My BAC referrals
received
c) My Team’s BAC
referrals received
d) My Team’s BAC
referrals received-
closed lost.
e) My Team’s BAC
referrals received-
Closed Won.
f) My BAC referrals
received sent
g) My Team’s BAC
referrals sent
Validate viewing referrals from the
referrals tab.
a) Validate new referrals tab
is available for all users.
b) Validate my BAC referrals
received
c) Validate my Team’s BAC
referrals received
d) Validate my Team’s BAC
referrals received- closed lost.
e) Validate my Team’s BAC
referrals received- Closed
Won.
f) Validate my BAC referrals
received send
g) Validate my Team’s BAC
referrals send
1.3 Project Overview
Domestic Advisory sends and receives referrals thru GRE. When domestic advisory
receives a referral, we call it catcher and when domestic advisory sends a referral we
call pitching. All referrals will be sent to Salesforce with an FA Assignment. The UPN #
will be unique identifier that will be sent to SFDC (Via GRE) to support referrals
assignment.
1.3 Scope
The Domestic advisory will require testing against the CEDP train and associated
milestone dates while the Sales force Cather and Sales force Pitcher will run against
Page 9
10. CRMS. The domestic advisory will require DEV, IDE and QA functional testing and sign-
off before proceeding to PROD. System test/edge case testing will be done completely
in DEV and IDE, partially in QA (depending on time available and priority) and will NOT
be completed in PROD.
1.4 Covered During Testing
Please review matrix outlined in Section 1
2. Entry and Exit Criteria
2.1 Entry Criteria
Requirement Author Check Box
( if
applicable)
1 Business requirement documents (BRS) and use
cases (if available) are complete and approved
Business
Sponsor
2 SRS, SAD and/or functional requirements documents
are complete and approved
Dev
3 Project Plan & Project Schedule are published Dev
4 Test environment with integrated code related to the
release is available
Dev/Pkg/
Arch
5 Test Ids and data has been sourced and provisioned
within the test environment
Dev/Pkg/
Arch
6 Environment is populated with the correct data load – Dev/Pkg/
Page 10
11. (for data projects only) Arch
7 <Test Phase Name> Test Plan has been created Testing
Svcs
8 <Test Phase Name> Test Cases and Scripts have
been created
Testing
Svcs
9 <Previous Test Phase> has been completed
successfully
Dev/Testi
ng Svcs
10 Business and/or Development Test Cases/Scripts are
made available to Testing Services
Bus/Dev
11 A defect tracking process is established and
accessible by all
Dev/Testi
ng Svcs
12 A release manifest has been provided which includes
a list of defects and enhancements
Dev
13 Development technical walkthrough/demo has been
completed
Dev
14 UAT Signoff - Tests, Results, issues and priority Dev/Bus
15 Implémentation Procédures (i.e. SUS, login script,
msi, etc.)
Dev/Pkg/
Arch
16 Contingency/Rollback instructions Dev/Pkg/
Arch
17 Source files or package submitted into PVCS Dev/Pkg/
Arch
2.2 Exit Criteria
Exit criteria for DEV testing all Domestic advisory are as follows:
Page 11
12. 1) Teams have executed all test cases functional in DEV
2) Teams have logged all issues in PMO issues object
3) Teams have re-tested and resolved any issues (actual bug or test script error)
in DEV org
Exit criteria for IDE, QA and PROD testing are managed by the CRMS Release
Manager and are tracked outside of this document.
2.3 Data
The test data will be required and the Test Script document will contain the information
on Test Data. The test data would comprise of the artificially created data set & the real
data that exists in the system today. The artificial test data would ensure that 100% test
coverage is achieved while live data would serve as a reality check.
Examples of the test data set are as follows:
2.4 Facilities
The Testing team can be located at different places within same campus. Additionally
some resources could be from MLITS off-shore resource pool while some on-shore
resources might choose to work remotely. Hence, it will be a pool of on-shore, off-shore
and virtual test resources.
3. Dependencies
3.1 Dependencies
Salesforce Catcher will require the following applications:
•WMW Workstation
•GRE
Page 12
13. •GCC
•GBC
•CRM Application
•Apex Trigger on Lead update in GRE
•API Web Service
•SCP Data Integration Complete
•SCP Lead to Prospect
Salesforce Pitcher will require the following applications:
•WMW Workstation
•GRE
•GCC
•GBC
•CRM Application
•Apex Trigger on Lead update in GRE
•API Web Service
•SCP Data Integration Complete
•SCP Lead to Prospect
3.2 Assumptions and Risk Assessment
# Requiremen
t #
Assumption/Constraint
1 N/A Salesforce will only integrate with the GRE in Phase 3. This phase
will not include any integration with LDRS or CPR, etc.
2 N/A Salesforce has dependencies on the following deployments:
SCP Data Integration Complete
Page 13
14. SCP Lead to Prospect
Assumption is if SCP deployment is complete all client & Prospect
(Type=Prospect and Client) records in the salesforce will also exist
in the GWIM Hub and vice versa
3 5.1.1.16.2 FA’s, CA’s and Managers will use salesforce to work with referral
as follows:
• FAC is sending INDIVIDUAL referrals only to FA’s (SFDC
Catching)
• GCC is sending INDIVIDUAL referrals only to FA’s (SFDC
Catching)
• FA’s are sending BUSINESS referrals only to GCC
(Pitching)
4 5.1.1.16.2 WMB’s are out of scope for Phase 3
5 N/A In November the interim referral program solution will run in parallel
with phase 3 Enterprise Referrals solution. The following programs
will no longer go through the interim process:
-FAC
-GBC
*Note: Salesforce will continue to work with the LDRS to support
the interim referral programs in November
6 N/A The new referrals tab will display several list views for FA’s, CA’s
and Managers. Existing interim referral program referrals will be
displayed in the “received” referrals list view and will be identifiable
by the referral code field included in the view.
7 N/A The referral tab list views will not provide a combined list view of
“My sent Referrals and My Received Referrals”
8 N/A Currently there is no integration between Salesforce and the
Account Opening process: however the GRE will use their existing
process (Won/Funded) to update Salesforce status fields to identify
if an account has been open or funded. Therefore, GRE will update
Page 14
15. Salesforce with account opening information
9 N/A There will be changes required to the existing interim Referral
Program. Impact Analysis will be completed during LLD.
10 N/A Training for the Salesforce component of the Enterprise Referrals
solution will be planned and deployed prior to rolling out this project
in November. Currently no requirements around training have been
designed. Detailed information will be documented outside of this
HLD.
11 N/A Support Plan / Process / Documentation for Salesforce component
of the Enterprise Referrals solution will be planned and deployed
prior to rolling out this project in November. Currently no
requirements around training have been designed. Detailed
information will be documented outside of this HLD.
12 N/A An integrated testing plan and testing strategy that includes how
testing will be deployed for Salesforce Enterprise Referrals solution
will be planned and deployed prior to rolling out the project in
November. Detailed information will be documented outside of this
HLD.
13 N/A Once the Enterprise Referrals phase 3 HLD is signed off all the
Interim Referral Enhancements will be reviewed and it is
determined that the request will impact phase 3 delivery, it will be
on hold until the deployment of the project in November, 2010.
14 N/A End to End pipeline reporting for the overall Enterprise Referral
program will be handled outside of Salesforce.
15 N/A All referrals will be sent to Salesforce with an FA Assignment. The
UPN # will be the unique identifier that GRE will send to SFDC to
support referral assignment. Assignment error handling will be
outlined in LLD.
16 6.14 GRE will update Salesforce in real time with new referral. GRE is
integrating with Salesforce web services for referral creation.
Page 15
16. 17 5.1.1.13 GRE is responsible for sending the initial email notification to the
FA once it confirms the referral can successfully be assigned to a
FA in Salesforce.
18 N/A The client contact (48 hour SLA) clock is only applicable for FAC
Referral. GCC referrals do not have SLA’s where if the SLA is not
met the referral will be sent for re-assignment. However-GCC does
have expiration requirements that are managed by other GRE
clocks.
19 N/A When referrals are re-assigned due to the FAC 48 hours SLA the
new receiving associates will be able to see any notes / activities
created by the previous referral owner. This is in line with the
current interim referral solution.
20 5.1.1.23;
5.1.1.24
GRE is responsible for maintaining all referral expiration clocks.
21 N/A Once a referral is expired that referral is considered “dead”. That
same referral ID would not be sent back to Salesforce. If a new
referral for that same client is generated a new referral ID would be
generated.
22 5.1.1.14.1 GRE will work with the WMW UI Alert team to discuss the 75 days
Alert in line with 90 days expiration clock (expiration details are still
being defined by changed management)
23 N/A GRE will work with the WMW UI Alert team to discuss the 24 hours
Alert for FAC referrals that is required to be added to the current
MWM alert functionality.
24 N/A The following fields are unique / external fields in Salesforce,
duplicates will not be permitted:
-Referral ID: Text (10)
-BAC Party ID: Text (11)*
*Note: Currently there is a discrepancy between the field length of
BAC Party ID in Salesforce and GRE. GRE field length is 20.
Page 16
17. 25 5.1.1.18.4.4 The presence of a BAC Party ID on a Referral identifies that the
referral is for a person who has an existing banking relationship.
26 5.1.1.15
5.1.1.15.3.1
5.1.1.15.3.2
Salesforce will not support client consent Requirements in Phase 3.
27 5.1.1.17.1 Salesforce definition of an FA “discontinuing” a referral is based on
the Enterprise Status Mapping. An FA can “discontinue” a referral
ONLY by updating status of a received referral to Unqualified
(Lead) or closed cost (Opportunity)
28 6.16 & 6.19 Salesforce is responsible for creating a translation table to allow
status updates to be sent from Salesforce to GRE using the
Enterprise Referral status values. A translation table is required for
“Catching” referrals only.
29 N/A When a referral is assigned to an FA that has an existing
relationship with the FA will use the existing convert Matching
functionality (as defined by SCP Lead to Prospect functionality).
GRE will not pass any identifier to Salesforce to force association
to a referral to a client & Prospect during Lead.
30 N/A Salesforce.com will not send any “activity” (tasks, event, meetings,
and calls) information to the GRE.
31 N/A When a FA pitches / sends a referral from Salesforce, Salesforce
will call the smart From with the SFDC ID and the GRE will
complete the translation required to execute the customer search
and pre-fill the smart Form with client information.
32 N/A After a FA submits a pitched / sent referral the GRE will complete
the updates required to pass updated client information to the
various client profile database (i.e. GWIM Hub) so the updated
information will be available in Salesforce.
33 N/A
Page 17
18. 4. Functional Tests in Scope
Salesforce Catcher:
Test
Case
#
Test Case Name Test Case Description
1 FA Assignment of
Referral
SFDC Receives a referral from GRE with FA
assignment
2 FA Re- Assignment of
Referral
SFDC Receives a re-assigned referral from GRE
with the new FA assignment
3 FA Assignment of
Referral
FA Assignment Error Cases
4 Receive Referral - FAC /
Advisory
FA receives a referrals from FAC
5 Receive Referral - GCC FA receives a referral from GCC (no existing FA
relationship)
6 Receive Referral - GCC FA receives a referral from GCC (previous existing
FA relationship and assigns to existing FA)
7 Update Referral (FAC &
GCC)
FA updates status, other fields on the Referral in
Salesforce
8 View Received Referral FA views all referrals they are assigned from a list
view
9 View Received Referrals CA can see any referrals when they are part of a
team
10 View Received Referrals Manager can view all referrals assigned to any FA
subordinates
11 Discontinue Referral FA Discontinues a referral
12 Referral SLA Expiration FA does not meet 48hour SLA and the referral is
Page 18
19. (FAC Only) sent for re-assignment
Salesforce Pitcher:
Test
Case #
Test Case Name Test Case Description
1 Submit Referral for Business
Client & Prospect record
FA sends a referral from an existing
Prospect or Client in Salesforce - Must by a
Business C&P Record
2 Receive Status updates (FAC
& GCC)
Salesforce receives status/field updates of
the submitted referral
3 View Submitted Referrals FA views the status and other information
of a submitted referral in Salesforce
4 Update Submitted Referrals FA submits a referral and identifies they
need to make an update (i.e. Phone #,
Address) to the submitted referral
5 Sending a Referral on behalf of
an FA
CA can create referrals on behalf of an FA -
however they can never be the owner /
pitcher of the referral.
6 CA’s View of Sent Referrals CA can see any referrals that an FA on
their team created
7 Managers View of Sent
Referrals
Manager can view all referrals sent by their
FA subordinates
5. Tests Out of Scope
The following section outlines the requirements that are no longer valid for the
salesforce application.
Page 19
20. • 5.1.1.15 and Child requirements for referral consent are not in scope for sales
force
• 5.1.1.16.2 – WMB’s are not in Scope in Phase 3 for referral
• 5.1.1.18.2 – List view will be separate for leads and Referrals. Referrals list views
are defined in this documents; however there will not be any modification to any
non referral record type list views.
• The last three requirements in the BRD extract doc (Reg #pg 42) are not in
scope for sales force as they are FAC requirements.
• 5.1.1.18.4.4 & 5.1.1.11.3.4 – Business advised to support this requirement the
BAC party ID field will be displayed on the page layout. A new field named
Existing Banking client is not required and training will be enforce the message
that the presence of a BAC party ID identifies that there is an existing banking
relationship.
• 5.1.1.23 & 5.1.1.24 – GWIM / GCC are defining the clocks of these requirements.
A general SFDC requirement has been added to support these requirements
6. Test Approach
6.1 Functional Test
Test Objective: Verify that the Domestic advisory sending and receiving
referral from GRE and functioning as designed.
Technique: The following techniques will be utilized for each workstream
tested:
• Positive test cases
• Negative test cases
Page 20
21. Required Tools: • Microsoft Excel Test Script
• Microsoft Word Testing Execution Instructions
• Microsoft Excel Test User Sheet (QA and PROD only)
• PMO Testing Issues Object
Success Criteria: Actual results match expected results as documented in the
workstream script document
Special Considerations: None
6.2 Regression Test
Test Objective: To verify that code and environment changes have not
negatively impacted the existing functionality.
Technique: Re-execution of test cases/scripts associated with previously
existing functionality to ensure that the functionality has not
been impacted by changes associated with a new release.
Required Tools: • Microsoft Excel Test Script
• Microsoft Word Testing Execution Instructions
• Microsoft Excel Test User Sheet (QA and PROD only)
• PMO Testing Issues Object
• Other tools as required by CRMS Release Manager
Success Criteria: Actual results match expected results as documented in the
Regression script kit
Special Considerations: • Design team will complete some ad hoc regression
test cases in DEV and IDE
• Full regression testing will be managed by CRMS
Release Manager in QA and PROD
Page 21
22. 7. Environmental Needs
7.1 Roles & Responsibilities
The matrix below outlines staff and responsibilities during testing:
# Resource Role Responsibility
1. BA and / or QA
Lead
Will lead the triage of any issues that will be reported
during the ongoing test cycles in each of environments
until the project is signed off in Production. This
resource will also be coordinating with the technology
testing team, the QA testing team and the business
testing team in case they hit any road blocks.
2.
Functional Testers These are the dedicated functional testing resources.
3.
Business Testers These are the dedicated functional testing resources.
4.
Project Managers
Would acts as mentors and decision makers when the
Project is at a critical stage.
5.
Business Partners
Would acts as mentors and decision makers when the
Project is at a critical stage and sign-off on the Project
upon the successful completion of the Project.
6. Environment
Management SFDC
Help in facilitating environmental issues should they
arise during the testing phase.
7. Release
Management
Help address any issues that challenge the release. For
example, issues resolution consumes more time than
anticipated thereby jeopardizing the release time lines.
7.2 Test Environment Base System Hardware / Software
Salesforce Catcher:
Page 22
23. • Sys Admin access to SFDC DOM ADV, IDE, QA and PROD via URL
• DEV, IDE, QA and PROD SQL Access
• DEV, IDE, QA and PROD INFA Access
• DEV, IDE, QA and PROD WMW
Salesforce Pitcher:
• Sys Admin access to SFDC DOM ADV, IDE, QA and PROD via URL
• DEV SQL Access
• DEV INFA Access
• DEV, IDE, QA and PROD WMW with OCC v2/v3 installed
• Win merge
7.3 Test Environment Configurations
• Testing will be performed against the following environments:
Salesforce Catcher:
• DEV
o SFDC DOM ADV SDEV3
o SQL DEV
o INFA DEV
• IDE
o SFDC DOM ADV SIDE
o SQL IDE
o INFA IDE
• QA
o SFDC DOM ADV SQA2
o SQL QA
o INFA QA
• PROD
Page 23
24. o SFDC DOM ADV PROD
o SQL PROD
o INFA PROD
Salesforce Pitcher:
• DEV
o SFDC DOM ADV SDEV3
o SQL DEV
o INFA DEV
• IDE
o SFDC DOM ADV SIDE
o SQL DEV
o INFA DEV
• QA
o SFDC DOM ADV SQA2
o SQL DEV
o INFA DEV
• PROD
o SFDC DOM ADV PROD
o SQL DEV
o INFA DEV
7.4 Test Tools
o Microsoft Excel (Test Script)
o Microsoft Word (Test Plans)
o PMO (Testing Issues Object)
o Other tools as deemed necessary by CRMS Release Manager for QA and
PROD regression testing
Page 24
25. 8. Communication
The defects and the issues will be managed within the issues tab in the PMO. On a
daily basis during the testing cycle the Issue reports will be generated in order to keep
track of issues and their resolutions. Additionally, the expertise of the existing defect
management team will be leveraged for the all the report and metrics generation. The
report will capture the following:
• Number of defects found to date
• Number of defects resolved
• Number of defects still Open
• Breakdown of Bugs by Severity / Priority Matrix
• Dev Manager to whom the defect is assigned to.
• Defect Id
• State of the defect.
• Days elapsed since submission of the defect.
• Submitter who logged the defect.
• Severity
• Headline is the short description of the defect.
• Business Priority
• Notes
• Defect/Change Request
Additionally, we will leverage the reports generated by the defect management team to
generate additional reports that we deem necessary at that point in time.
For example: Testing status reports - may summarize daily testing activities, issues,
risks, bug counts, test case coverage, and other relevant metrics.
*Note: The precise reporting format & types of reports will be determined
Page 25
26. at the onset of testing cycle.
8.1.1 Escalation Process
The defects will be evaluated for the “Severity” and “Priority”. The Critical / Major
defects with high priority will be escalated to appropriate teams.
9. Contact Information
Name Role Phone
Joe Martz Data Services Lead 609-274-3088
Nishant Parikh Test Team Manager 609-274-8864
Michael Bujnowski Project Manager
Gina DePasquale Senior Business Analyst 718 - 913 - 4810
Mohammed Golam Test Lead 609-274-4251
10. Problem Reporting, Escalation and Issue Resolution
• All defects found during testing will be entered and tracked using PMO Issues object
• All defects found will be assigned to the developer or test script writer
• A discussion takes place between the tech team and functional team to resolve
defects/issues
• Defects are corrected in DEV org then ANT package/install doc is updated and
package/deployment/testing is walked back up through standard environment
progression
11. Milestones and Schedule Summary
Milestone Owner
Scheduled
Completion Date
Test Plan created Mohammed Golam 06/17/2010
Functional test script created Mohammed Golam 06/17/2010
Page 26
27. Milestone Owner
Scheduled
Completion Date
Test plan finalized and approved
• ML tech team sign-off received
• ML business team sign-off received
Mohammed Golam 06/17/2010
DEV testing starts Design Team 05/19/2010
Functional certification (CEDP) starts Design Team 06/03/2010
QA/UAT starts – ALL Design Team
QA Team (Regression only)
07/28/2010
QA/UAT ends – ALL Design Team
QA Team (Regression only)
08/17/2010
PROD testing starts – ALL Design Team
QA Team (Regression only)
08/21/2010
PROD testing ends - ALL Design Team
QA Team (Regression only)
08/21/2010
12. Deliverables
12.1 Test Artifacts and Location
List Item Projected
Completion
Date
Location Analysts
Involved
Test Plan July 18, 2010 Latest located on PMO Product Record:
https://na1.salesforce.com/01530000001Rvu
D
Mohammed
Golam
Enterprise
Referral SFDC
Phase 3 HLD
V6.doc
June 17, 2010 Latest located on PMO Product Record:
https://na1.salesforce.com/a0930000003Jdjq
Mohammed
Golam
12.2 References
•Enterprise Referral SFDC Phase 3 HLD v06.doc
Page 27
28. 13. Approval and Sign Off
System Name / Role Sign-Off Provided By
Sign-Off
Date
Business Sponsor Anna Maria Geehan
Business Stakeholder Joyce Molter
Tech Sponsor Scott Krutan
Data Services Lead Joe Martz
Release, Testing and Environment Management
Lead
Apurva Patel
Development Lead & Technical Project Manager
Shankar
Ramasubramanian
Project Manager Michael Bujnowski
Technical SME Bill Kuehler
Technical Architect Wilson Ng
CRMS Analyst SME Jessy Borrero
CRMS Analysts Interim Referrals SME
Mallesh
Muthukaruppan
14. Appendix
14.1 Glossary
Term Definition
Account (Merrill
Lynch)
A Financial account that belongs to a client (Retirement Account,
Trust Account, etc.). Clients can have multiple accounts at
Merrill Lynch.
Account
(Salesforce.com)
Standard Object within Salesforce that contains all Client records
with Retirement Services greater than 5 Mil. Records in this
Object are visible through application via Account Tab.
Page 28
29. Term Definition
BAC Bank of America Corporation
Catching (Catch) The “Catching” scenario denotes the receiving of a Referral from
point A (catching/receiving point) from point B (pitching/sending
point).
CRM Customer Relationship Management
CSG Also referred to as ADG and Small Market. This group of
specialist process Retirement service accounts less than 5
Million dollars.
FA (Financial
Advisor)
FA(s) are the key client relationship managers and have a
financial interest in servicing their clients.
FAC Financial Advisory Center
The organization charged with providing client financial planning
assistance for the Mass Affluent segment of clients
GCC Global Client Coverage Group
GCB Global Commercial Bank Group
GRE (Global Referral Engine) Referral Engine utilized by GWIM and
GCC to route referral across LOBs.
GWM Global Wealth Management
GWIM Global Wealth Investment Management
HUB Merrill Lynch’s proprietary cross reference database being
developed for customer master integration
Institution Lead Custom Object created within Salesforce specifically for the
Large Market application to store Leads related to the Retirement
Services. Records within this custom object are visible to users
via Bank Lead Tab in the application (see picture below).
LOBs Line of Business
Object This is another term for Table. Terms used interchangeably
Page 29
30. Term Definition
throughout this document. (Account, Contact, Opportunity)
Pitching (Pitch) The “Pitching” scenario denotes the sending of a Referral from
point A (pitching/sending point) to point B (catching/receiving
point).
Referrals Value proposition where one associate confirms the customer’s
consent/interest and introduces the person/institution to another
associate in a different LOB to complete sales process.
SFDC Salesforce.com
Web Service File received thru integration containing data necessary to create
new referral.
Wealth
Management
Workstation
(WMW)
Desktop Application used by Merrill Lynch users (FA(s), CA(s),
Managers, etc.) to conduct their day to day business. The WMW
desktop integrates several “best of breed” applications with ML
core applications and provides a comprehensive business
platform to the end users.
Page 30
