enterprise referral ph 3 test plan v1

TEST PLANProject Enterprise Referral Phase 3

Release CRMS 10.6.0.0Version 1

Date June 17, 2010Author Mohammed Golam

Revision HistoryDate Version Description Author

6/17/2010 Draft Initial Document Creation Mohammed Golam

TABLE OF CONTENTS1. INTRODUCTION..........................................................................................................................................3

1.1 TEST OBJECTIVE*...........................................................................................................................................31.2 SUMMARY OF TEST OBJECTIVE: THE FOLLOWING MATRIX LAYS OUT THE LIST OF ALL THE TEST ITEMS:

31.3 PROJECT OVERVIEW...........................................................................................................................................91.3 SCOPE.............................................................................................................................................................91.4 COVERED DURING TESTING..........................................................................................................................9

2. ENTRY AND EXIT CRITERIA.................................................................................................................9

2.1 ENTRY CRITERIA.............................................................................................................................................92.2 EXIT CRITERIA..............................................................................................................................................102.3 DATA.............................................................................................................................................................112.4 FACILITIES.....................................................................................................................................................11

3. DEPENDENCIES........................................................................................................................................11

3.1 DEPENDENCIES.............................................................................................................................................113.2 ASSUMPTIONS AND RISK ASSESSMENT......................................................................................................12

4. FUNCTIONAL TESTS IN SCOPE........................................................................................................15

5. TESTS OUT OF SCOPE..........................................................................................................................16

6. TEST APPROACH.....................................................................................................................................17

6.1 FUNCTIONAL TEST........................................................................................................................................176.2 REGRESSION TEST.......................................................................................................................................17

7. ENVIRONMENTAL NEEDS...................................................................................................................18

7.1 ROLES & RESPONSIBILITIES........................................................................................................................187.2 TEST ENVIRONMENT BASE SYSTEM HARDWARE / SOFTWARE.................................................................187.3 TEST ENVIRONMENT CONFIGURATIONS......................................................................................................197.4 TEST TOOLS.................................................................................................................................................20

8. COMMUNICATION...................................................................................................................................20

8.1.1 Escalation Process....................................................................................................................209. CONTACT INFORMATION....................................................................................................................21

10. PROBLEM REPORTING, ESCALATION AND ISSUE RESOLUTION..................................21

11. MILESTONES AND SCHEDULE SUMMARY.................................................................................21

12. DELIVERABLES.........................................................................................................................................22

12.1 TEST ARTIFACTS AND LOCATION............................................................................................................2212.2 REFERENCES.............................................................................................................................................22

13. APPROVAL AND SIGN OFF.................................................................................................................22

14. APPENDIX....................................................................................................................................................22

14.1 Glossary.................................................................................................................................................22

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 Priority

Notes

1 TA-1

Catching: Referral sent from GRE to SFDC(Both 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


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 existing client & Prospect record

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

3 TA-1


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


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(Both from

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

FAC and GCC)

6 TA-1


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 Enhancement

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 receivedb) My Teams BAC Referrals

receivedc) My Teams BAC Referrals

received today

8 TA-2

Catching: UI Enhancements

View received Referral (Lead) Validate received referral (Lead)a) Validate record type=

Enterprise individual referral. a) Validate page layout= Clone

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


SFDC to GRE Field Mapping Gaps

10 TA-2

Catching: UIEnhancements

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

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

opportunity record during conversion. Opportunities is required for referrals

required for referrals

12 TA-4


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 created it will overwrite the previous referrals information

ii) Referral information is also available on the opportunity.

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 will overwrite the previous referrals information.

ii) Validate Referral information is also available on the opportunity.

13 TA-5


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.

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.

f) Add a new referral information section.

14 TA-6


View converted Referral Opportunity: Stage Values

Validate converted Referral Opportunity: Stage Values

15

TA-7


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 IDc) BAC Party IDd) Status (Enterprise

Status Values)e) Sub Status (Enterprise

Status Values)

Validate that the following information has been sent back to the GRE for received referrals:

a) Validate Associate UPN#b) Validate referral IDc) Validate BAC Party IDd) 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

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.

available for viewing on the referrals tab.

18 TA-10

Pitching:UI Enhancements

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 Associateb) Referral IDc) BAC Party IDd) Status (Enterprise

Status Values)e) Sub Status( Enterprise

Status Values)f) Receiving Associate

Informationg) GCC Associate

Information

Validate the following information is sent back to the GRE for received referrals.

a) Validate receiving Associateb) Validate referral IDc) Validate BAC Party IDd) 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 Enhancements

Viewing referrals from the referrals tab.

a) New referrals tabis 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 tabis 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 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 TestingPlease 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 Dev/

provisioned within the test environment Pkg/Arch

6 Environment is populated with the correct data load – (for data projects only)

Dev/Pkg/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/Testing 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/Testing 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/Bus15 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 CriteriaExit criteria for DEV testing all Domestic advisory are as follows:

1) Teams have executed all test cases functional in DEV2) Teams have logged all issues in PMO issues object3) 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 DataThe 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 FacilitiesThe 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 DependenciesSalesforce Catcher 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

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

# Requirement #

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 CompleteSCP Lead to ProspectAssumption 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 35 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 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.

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.

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

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 CA can see any referrals when they are part

Referrals 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 (FAC Only)

FA does not meet 48hour SLA and the referral is 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.

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 TestTest 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

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 TestTest 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

ManagerSuccess Criteria: Actual results match expected results as

documented in the Regression script kitSpecial 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

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 TestersThese are the dedicated functional testing resources.

3. Business TestersThese are the dedicated functional testing resources.

4. Project ManagersWould 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 / SoftwareSalesforce Catcher:

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:

DEVo SFDC DOM ADV SDEV3o SQL DEVo INFA DEV

IDEo SFDC DOM ADV SIDEo SQL IDEo INFA IDE

QAo SFDC DOM ADV SQA2o SQL QAo INFA QA

PRODo SFDC DOM ADV PROD

o SQL PRODo INFA PROD

Salesforce Pitcher: DEV

o SFDC DOM ADV SDEV3o SQL DEVo INFA DEV

IDEo SFDC DOM ADV SIDEo SQL DEVo INFA DEV

QAo SFDC DOM ADV SQA2o SQL DEVo INFA DEV

PRODo SFDC DOM ADV PRODo SQL DEVo INFA DEV

7.4 Test Toolso 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

8. CommunicationThe 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 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 PhoneJoe Martz Data Services Lead 609-274-3088Nishant Parikh Test Team Manager 609-274-8864Michael Bujnowski Project ManagerGina DePasquale Senior Business Analyst 718 - 913 - 4810Mohammed 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 OwnerScheduled Completion

DateTest Plan created Mohammed Golam 06/17/2010Functional test script created Mohammed Golam 06/17/2010Test 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/2010Functional certification (CEDP) starts Design Team 06/03/2010QA/UAT starts – ALL Design Team

QA Team (Regression only)07/28/2010

QA/UAT ends – ALL Design TeamQA Team (Regression only)

08/17/2010

PROD testing starts – ALL Design TeamQA Team (Regression only)

08/21/2010

PROD testing ends - ALL Design TeamQA Team (Regression only)

08/21/2010

12. Deliverables

12.1 Test Artifacts and LocationList Item Projected

Completion Date

Location Analysts Involved

Test Plan July 18, 2010 Latest located on PMO Product Record: https://na1.salesforce.com/01530000001RvuD

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

13. Approval and Sign OffSystem Name / Role Sign-Off Provided

BySign-Off

Date

Business Sponsor Anna Maria Geehan

Business Stakeholder Joyce Molter

https://na1.salesforce.com/a0930000003Jdjq

https://na1.salesforce.com/01530000001RvuD

https://na1.salesforce.com/01530000001RvuD

System Name / Role Sign-Off Provided By

Sign-Off Date

Tech Sponsor Scott KrutanData Services Lead Joe MartzRelease, Testing and Environment Management Lead Apurva Patel

Development Lead & Technical Project Manager

Shankar Ramasubramania

n Project Manager Michael BujnowskiTechnical SME Bill KuehlerTechnical Architect Wilson NgCRMS Analyst SME Jessy BorreroCRMS Analysts Interim Referrals SME Mallesh

Muthukaruppan

14. Appendix

14.1 Glossary

Term DefinitionAccount (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.

BAC Bank of America CorporationCatching (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 ManagementCSG 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 CenterThe organization charged with providing client financial planning assistance for the Mass Affluent segment of

Term Definitionclients

GCC Global Client Coverage GroupGCB Global Commercial Bank GroupGRE (Global Referral Engine) Referral Engine utilized by

GWIM and GCC to route referral across LOBs.GWM Global Wealth ManagementGWIM Global Wealth Investment Management HUB Merrill Lynch’s proprietary cross reference database

being developed for customer master integrationInstitution 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 BusinessObject This is another term for Table. Terms used

interchangeably 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.comWeb 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.

enterprise referral ph 3 test plan v1

Documents