Loyalty Program Master Test Plan

Customer Centricity Initiative

Macy’s Loyalty Program

Master Test Planv. 1.01

Save Date: 4/11/2023Last Saved By: Ginene VanLieropPrint Date: 4/11/2023

Macy’s Loyalty ProgramMaster Test Plan v. 1.01

December 2009

http://secure.macyspartners.com/sites/dunnhumby/docs/mstloyalty/default.aspx

Test Plan Template v 3.2 (do not delete) Company Confidential of 21



ContentsDocument Purpose...........................................................................................4

1 Scope..........................................................................................................4

1.1 Requirements to Be Tested........................................................................................................4

1.2 Requirements Not to Be Tested..................................................................................................5

2 Testing Levels.............................................................................................5

2.1 Unit Testing................................................................................................................................. 5

2.2 System Testing............................................................................................................................ 5

2.3 Acceptance Testing.....................................................................................................................5

2.4 Regression Testing...................................................................................................................... 5

3 Approach....................................................................................................5

3.1 Guidelines for Iterative Testing.....................................................................................................6

3.2 Guidelines for Test Factors..........................................................................................................6

3.3 Application Interfaces.....................................................................................................................6

5 Environments and Data...............................................................................7

5.1 Inventory of Environment Resources............................................................................................9

5.2 Test Data................................................................................................................................. 12

6 Enterprise Test Tools.................................................................................13

7 Test Deliverables – Project Teams...............................................................13

8 Staffing, Responsibilities, and Training.......................................................14

9 Cross-Business Unit/Third Party Participation by Application........................14

10 Test Communication Plan......................................................................15

10.1 Meeting Schedules and Purpose................................................................................................15

10.2 Metrics and Measurements......................................................................................................15

10.3 Link to Bug Tracker..................................................................................................................15

11 Testing Schedules.................................................................................15

11.1 High-Level Testing Milestones..............................................................................................15

11.2 Link to Test Scheduler..........................................................................................................16

12 Risks and Contingencies........................................................................16





13 Assumptions, Constraints, and Dependencies.........................................16

13.1 Assumptions......................................................................................................................... 16

13.2 Constraints........................................................................................................................... 16

13.3 Dependencies.......................................................................................................................... 16

14 Document References...............................................................................17

15 Glossary of Terms...................................................................................17

16 Document History....................................................................................17

17 Reviewers and Approvers.........................................................................18

18 Appendix.................................................................................................18

19 Process Asset History....................................................................................................19





Document Purpose

The purpose of this Master Test Plan is to describe the testing efforts for the Macy’s tender neutral loyalty program also known as the Customer Centricity Initiative (CCI) and the Macy’s Loyalty Program. The areas covered will include scope, approach, resources, and scheduling

of testing activities across all testing phases.

1 Scope

Macy’s is creating a tender neutral loyalty program, which will allow customers the opportunity to enroll in the program via in-store, online, and through customer service.

The scope of this Program Level Master Test Plan is to outline testing information at a high-level that supports the implementation of the tender neutral loyalty program. The implementation of this program will require both Mainframe and Windows application-testing teams to ensure quality testing is performed during the system development lifecycle of this project.

Testing Advocates on projects classified as a Work Type 1 (WT1) will include their testing activities in the Project SDLC Document and will provide a link to the Loyalty Program Master Test Plan. Testing Advocates on projects classified as a Work Type 2 (WT2) will be required to create an application detail test plan with reference to the Loyalty Program Master Test Plan.

Testing Advocates should use the document asset templates from the new Q4M Streamline (Beta) intranet site. The link to this site is http://mymacys/applications/Q4M/Q4MBETA/default.aspx

1.1 Requirements to Be Tested

The requirements to be tested will fall into three categories, Business Requirements, System Requirements, and Technical Requirements.

Business Requirements: The Business Requirements to be tested are those presented in the Macy’s Loyalty Program Overview Document. The link to this document is http://secure.macyspartners.com/sites/dunnhumby/Docs/MSTLoyalty/Program Documents/Loyalty Overview Document.doc. Application teams will provide traceability evidence from their System Requirements to their applicable Business Requirements.

System Requirements: The System Requirements to be tested are those presented in each application’s WT1 SDLC Document or Requirements Definition Document (RDD). These documents can be found on the MST Loyalty Team Site by selecting the desired application tab. The link to the MST Loyalty Team Site is http://secure.macyspartners.com/sites/dunnhumby/docs/mstloyalty/default.aspx. Testing Advocates from each application team will perform testing using System Requirements outlined in either the WT1 SDLC Document or the RDD and any other supported documentation relevant to their testing efforts.

Technical Requirements: The Technical Requirements to be tested are those presented in the Technical Definition Document (TDD). Testing Advocates should contact their Project Manager or Development Lead for their project’s location of the TDD. Application teams will provide traceability evidence from their Technical Requirements to their System Requirements, to their applicable Business Requirements.




http://mymacys/applications/Q4M/Q4MBETA/default.aspx



Program Change Requests (PCRs): For WT1 projects, Testing Advocates should list all approved PCRs relating to their projects in the Projects SDLC Document. For WT2 projects, Testing Advocates should list all approved PCRs relating to their projects in their application detail test plan. A list of all PCRs are located http://secure.macyspartners.com/sites/dunnhumby/Program Documents/Forms/AllItems.aspx?RootFolder=%2fsites%2fdunnhumby%2fProgram%20Documents%2fChange%20Management&FolderCTID=&View=%7bAFD18C61%2dEDDF%2d46F4%2d92D6%2d61EFD4F4661B%7d

1.2 Requirements Not to Be Tested

MST will not be testing any requirements relating to the testing activities of third-party vendor Acxiom or out of scope to the tender neutral loyalty program for Pilot.

2 Testing Levels

All application groups participating in the tender neutral program should incorporate the levels/phases of testing as needed for the project type.

2.1 Unit Testing

Unit testing is performed during coding and integration testing and is done during detailed design. Since these are developer activities, they would be included in the unit test plan (Use the Unit Test Workbook Template on Q4M Streamline (Beta). Testing Advocates should follow-up with the Development Lead for verification.

2.2 System Testing

System testing can include many types or phases/levels of testing (Smoke Test, Functional/Component Testing, Regression Testing, Integration/Cross-FOB Testing, Beta Testing, etc.). Often these are performed concurrently and in various combinations. Testing Advocates should define and describe the test types that will be performed for their application testing effort.

2.3 Acceptance Testing

Acceptance testing will be performed as End-to-End Test of all functionality across all platforms and applications. A Program Level Acceptance Test Plan will be created prior to the End-to-End Test. Testing Advocates can also create a separate Acceptance Test Plan for their projects, if applicable.

2.4 Regression Testing

Regressing testing should be performed by every application Testing Advocate to ensure the quality of existing code has not been changed as new code is introduced.

3 Approach

The scope of the testing effort for the Loyalty Program will be based on both Waterfall and Iterative Testing Methodologies. Waterfall Testing is an approach where you complete a number of phases in a strictly ordered sequence: requirements analysis, design, implementation/integration, and then testing.Iterative Testing is an approach to testing where an evaluation or assessment of quality is conducted continuously, on smaller, more manageable units of work.



http://secure.macyspartners.com/sites/dunnhumby/Program%20Documents/Forms/AllItems.aspx?RootFolder=%2Fsites%2Fdunnhumby%2FProgram%20Documents%2FChange%20Management&FolderCTID=&View=%7BAFD18C61-EDDF-46F4-92D6-61EFD4F4661B%7D





The Loyalty System testing activity will focus on the FIT Model (Focused Iterative Testing). Focused Iterative Testing means testing iteratively against a focused area of a software product/system. A focused area usually refers to a group of specific features in the software product (for example, Offer/Reward). All other systems can elect to perform Iterative Testing or continue with their current Waterfall method of testing until End-to-End Testing is ready to be performed. There will be a separate End-to-End Acceptance Test Plan where all application-test teams will participate together at one time.

3.1 Guidelines for Iterative Testing Start with Iteration 1, Build 1.

o There may be several iterations within a Build.o For iterations performed, the next iteration should build on the previous iteration.

Record and keep track of the number of Iterations performed. Record and keep track of the number of Builds completed. For each Build, request Dev. Lead produces Release Notes so that you know what’s in each Build. This will be beneficial as the product continues to develop and will provide traceability. Each Build produced should build on the work of the previous Build.

3.2 Guidelines for Test FactorsThere are many applications interfacing for the Loyalty Program. In order for a successful testing effort, you may use the following test factors where applicable. Test factors enable the test process to be logically constructed.

Correctness – Assurance that the data entered, processed, and outputted by the application system is accurate and complete. File Integrity – Assurance that the data entered into the application system will be returned unaltered. Audit Trail – The capability to substantiate the processing that has occurred. Continuity of processing – The ability to sustain processing in the event problems occur. Reliability – Assurance that the application will perform its intended function with the required precision over an extended period of time. Ease of Use – The extent of effort required learning, operating, preparing input for, and interpreting output from the system. Maintainability – The effort required to locate and fix an error in the application system or missing requirement or misinterpretation of a requirement. Portability – The effort required to transfer data from one application to another. Web Service Communication – Assurance that messaging service are communicating between applications without error.

3.3 Application Interfaces

Integrated Application Context Diagram link

http://secure.macyspartners.com/sites/dunnhumby/Docs/MSTLoyalty/Program%20Documents/Visio-Customer,%20Loyalty%20and%20Offers%20Integrated%20System%20Context%20Diagram%20v16.pdf







5 Environments and Data

The following environment information is at a high-level and continues to be a work in progress and subject to change. If changes are made, this document will be updated to reflect those changes. Note: Figures 1, 2, and Table 1 were retrieved from the Loyalty Program Level Environment Plan.





Figure 1: Environment Readiness Timeline





Figure 2: Test Environment Resources

5.1 Inventory of Environment Resources





This section lists the resources that are used by each system in each environment. The reference environment names are those used by the new Loyalty system and their mappings to other nomenclatures are indicated. New resources are emphasized.

Table 1: Environment Resource Inventory

Development Test Pre-Production Stress Production

Loyalty esul1084 Redhat Linux 5.3 server (TIBCO Syndera Dashboard, TIBCO Business Works, TIBCO Enterprise Messaging System, TIBCO Business Events, Coherence DataGrid)

Sun M5000 Solaris server board, shared with other non-production environments (Oracle 11g (schemaName))

esul1085 Redhat Linux 5.3 server (TIBCO Syndera Dashboard, TIBCO Business Works, TIBCO Enterprise Messaging System, TIBCO Business Events, Coherence DataGrid)


esul1086, esul1087, esul1088, esul1089 Redhat Linux 5.3 servers (TIBCO Syndera Dashboard, TIBCO Business Works, TIBCO Enterprise Messaging System, TIBCO Business Events, Coherence DataGrid, RT View)


CSS Load Balancer

Initial Stress environment will be Production.

Subsequently, a duplicate of the Production environment will be setup in Lorain and will double as a disaster recovery and stress test environment.

esu1l162, esu1l163, esu1l164, esu1l165, esu1l166 Redhat Linux 5.3 servers (TIBCO Syndera Dashboard, TIBCO Business Works, TIBCO Enterprise Messaging System, TIBCO Business Events, Coherence DataGrid)

esu1l167 Redhat Linux 5.3 server (RT View)

2 x Sun M5000 Solaris server boards (Oracle 11g (schemaName))

CSS Load Balancer

Customer TC1CICD mainframe DEV region (CICS, DB2)

TC1CICB mainframe BIZ region (CICS, DB2)

TC1CICQ mainframe REL region (CICS, DB2)

[regionName] mainframe PRD region (CICS, DB2)

FedFIL (including XML MidTier)

TFLCICX mainframe DEV region (CICS, XML/TRANSL, DB2)

FZ000XSWEB90 Windows 2003 DEV server (ASP, VB6)

TFLCICB mainframe BIZ region (CICS, XML/TRANSL, DB2)

FS000XVXML92 Windows 2003 BIZ server (ASP, VB6)

TFLCICQ mainframe REL region (CICS, XML/TRANSL, DB2)

FZ000XSWEB91 Windows 2003 REL server (ASP, VB6)

[regionName] mainframe PRD region (CICS, XML/TRANSL, DB2)

[serverName(s)] Windows 2003 PRD server(s) (ASP, VB6)






SPOS Windows XP Register (.NET)

[serverName] Linux server (C scripts)

Windows XP Register (.NET)








MCOM ibm44p15 AIX server (Websphere Application Server)

ibm52p20 AIX server (DB2 (mci252))

ibm64p1 AIX server (Websphere Application Server)

ibm64p2 AIX server (DB2 (muq8))

ibm44p20 AIX server (Websphere Application Server)

ibm44p9 AIX server (DB2 (mut1))

[serverName(s)] AIX server (Websphere Application Server)

[serverName] AIX server (DB2 (instanceName))

RPS TDNCICD mainframe DEV region (CICS, Datacom)

TDNCICB mainframe BIZ region (CICS, Datacom)

TDNCICQ mainframe REL region (CICS, Datacom)

[regionName] mainframe STR region (CICS, Datacom)

[regionName] mainframe PRD region (CICS, Datacom)

FCS TFACICR mainframe FIX region (CICS, Datacom) FACICR0 mainframe PRD region (CICS, Datacom, DB2)

PACICR0 failover region.

ICM WindowsXP desktop (.NET, C++, SQL Server, Development configuration files)

WindowsXP desktop (.NET, C++, SQL Server, Test configuration files)

WindowsXP desktop (.NET, C++, SQL Server, Pre-Production configuration files)

WindowsXP desktop (.NET, C++, SQL Server, Stress configuration files)

WindowsXP desktop (.NET, C++, SQL Server, Production configuration files)

RDS TDNCICD mainframe DEV region (CICS, Datacom, DB2)

TDNCICB mainframe BIZ region (CICS, Datacom, DB2)

TDNCICQ mainframe REL region (CICS, Datacom, DB2)

[regionName] mainframe PRD region (CICS, Datacom, DB2)






SOCR esu2v111 Redhat Linux 4.1.2-14 server (Websphere Application Server 6.1)

mt001xsbti90 Windows 2003 server (btwebsvcdev, ASP.NET (VB))

TDNCICD mainframe DEV region (CICS, Datacom, DB2)

esu2v115 Redhat Linux 4.1.2-14 server (Websphere Application Server 6.1)

mt001xsbti90 Windows 2003 server (btwebsvcbiz, ASP.NET (VB))


esu2v136 Redhat Linux 4.1.2-14 server (Websphere Application Server 6.1)

mt001xsbti90 Windows 2003 server (btwebsvcrel, ASP.NET (VB))


esu1l138 & esu1l139 AIX 5.3 servers (Websphere Application Server 6.1), load-balanced by esu1l137

ma001xsbti01 & ma001xsbti02 Windows 2003 server(s) (ASP.NET (VB))


Offer Mgmt

Dunnhumby server of some kind

CIM Acxiom FTP server

DCR [serverName] Windows 2003 server (TBL, C#.NET)

[serverName] Linux [N.n?] server (Oracle N.n)

[serverName] Windows 2003 server (TBL, C#.NET)

[serverName] Linux [N.n?] server (Oracle N.n)

MA000XSDCR01, MA000XSDCR02, MA000XSDCR03 & MA000XSDCR04 Windows 2003 servers (TBL, C#.NET)

esu1l075, esu1l076 & esu1l077 Linux [N.n?] server (Oracle N.n)

Credit Multiple mainframe TEST regions (CICS, Datacom) – “several since Loyalty has different expectations by market” per Jan Altfield.

TM3CICC – Cleveland marketTPCCICC – Sacramento marketTDYCICC – NY EastTI0CICC – outside of test market store but zip code falls within target zip code areaTFVCICC – Cobrands in Sacremento/NY East marketsTF2CICC – Cobrandds in Cleveland marketTLGCICC – NAPS

Multiple mainframe PRD regions (CICS, Datacom)

[regionNames]






StrongMail / OES

?

WindowsXP desktop (Websphere Application Server)

[serverName] [OS?] mail server

OES2:

[serverName] AIX server (Websphere Application Server, MQ Series)

[serverName] AIX server (Oracle 10g)

[serverName] [OS?] mail server

[serverName] AIX server (Websphere Application Server, MQ Series)

[serverName] AIX server (Oracle 10g)

Support Structures

CAPS ibm64p4 & ibm64p3 AIX servers (DB2 (“dev”), DataStage)

ibm64p5 & ibm64p6 AIX servers (DB2 (“qa”), DataStage)

ibm66p1 & ibm67p1 AIX servers (DB2, DataStage)

DDW fsgncr10 AIX server (Teradata N.n (EDW_PROD / EWPTMP)) fsgncr10 AIX server (Teradata N.n (EDW_PROD / RRPMST & RRPMVP))

GL TH3CICF mainframe test region (CICS, Datacom?)

PCS TDNCICD mainframe DEV region (CICS, Datacom, DB2)



[regionName] mainframe STR region (CICS, Datacom, DB2)


STK

SAL

Test Data

The test data required to support the testing scenarios listed in the Approach section of this document will be outlined in the individual application’s SDLC or RDD documents. Contact the Quality Control Organization (QCO) at mailto:MST QCO [email protected] if help is needed to load application data.



mailto:MST%20QCO%[email protected]



6 Enterprise Test Tools

Update the following chart to reflect the testing tools used on a project.

Tool Purpose Link to the Tool

Testing Scheduler (TSC) Testing resource scheduling http://tsc/

Bug Tracker Defect management http://bugtracker/bug/(uf0a3b55rmt1z5550f3ktw45)/default.aspx

QA Director & Changepoint Testing script depository and execution tool. Defect management.

http://fs000xscar91:9197/qadirector/default.aspx

7 Test Deliverables – Project Teams

The Testing Advocates are responsible for the following work products.

Deliverable – Work Product Purpose

Test Plan Describes the scope, approach, resources, features to be tested, testing tasks, and risk contingency planning.

For WT1 projects: Enter the link to Loyalty Master Test in Section 6.1 of the SDLC Document.

For WT2 projects: See the Q4M Streamline (Beta) intranet site, Q4M (Beta) Assets link for the Test Plan Template http://mymacys/applications/Q4M/Q4MBETA/default.aspx

Test Cases Specifies test inputs, execution conditions, test outputs, expected results, actual results, and test pass/fail results.

For WT1 projects: Enter the link to your test cases Section 6.4 of the SDLC Document.

For WT2 projects: See the Q4M Streamline (Beta) intranet site, Q4M (Beta) Assets link for the Test Case Template http://mymacys/applications/Q4M/Q4MBETA/default.aspx

Test Summary Report Test Summary Report summarizes the application testing results for this project.

For WT1 projects: Enter the summary information in Section 6.3 of the SDLC Document.

For WT2 projects: See the Q4M Streamline (Beta) intranet site, Q4M (Beta) Assets link for the Test Summary Report http://mymacys/applications/Q4M/Q4MBETA/default.aspx

Test Scheduler (TSC) This is a testing resource scheduling application. Testing Advocates are responsible for creating their own application TSC entries for this project. http://tsc/



http://tsc/






http://bugtracker/bug/(uf0a3b55rmt1z5550f3ktw45)/default.aspx



http://tsc/



8 Staffing, Responsibilities, and Training

Team Member Role Responsibilities Contact

Russ Summers Enterprise Program Manager Project management for the Loyalty Program

[email protected]

(678) 474-2085

Diane Nachazel Sr. Enterprise Program Manger Project management for the Loyalty Program

[email protected]

(678) 474-2136

Violetta Felgin PPQA Analyst PPQA Analyst for the Loyalty Program

[email protected]

(678) 474-3236

Ginene VanLierop Program Testing Advocate Coordinating the testing efforts for the Loyalty Program

[email protected]

(678) 474-2256

Gareth Davies Program Operations Advocate Coordinating development and test environments for the Loyalty Program

[email protected]

(678) 474-3899

QCO Team Test Environments and Data Set-up Support and guide the application teams with environment and data configurations.

[email protected]

(Test Management)

(678) 474-3024

[email protected]

(Data Loads)

(678) 474-3232

[email protected]

(Test Environments)

(678) 474-3134

Enterprise Tools Team Bug Tracker, Test Scheduler Tools Resolve tool problems and answer questions about Test Scheduler and Bug Tracker

mailto:MST [email protected]

9 Cross-Business Unit/Third Party Participation by Application

Business Unit/Company Name

Team Name/Applications

Contact Person, Phone, E-mail

Comments

Marketing CUS Ginene VanLierop

Meenakshi Tarun

Marketing Loyalty System Charanya Govindarajan

POS - Lorain SPOS Matthew Johnson MST/Lorain

Logistics RDS Tina Arrowood



mailto:MST%[email protected]

mailto:MST%[email protected]

mailto:[email protected]










Business Unit/Company Name

Team Name/Applications

Contact Person, Phone, E-mail

Comments

Direct to Consumer D2C-FedFil James Wiggins

Stores CVT Marc Bergroschtje

Stores FCS Rosa Summers

Stores RPS Cecilia Unger (Bonnie)

POS Credit Andrea Perine

Direct to Consumer MCOM Roland Demeter

10 Test Communication Plan

10.1 Meeting Schedules and Purpose

The Loyalty Program Testing Advocates began meeting on Monday, November 11, 2009 and will continue to meet on Mondays from 3:15 p.m. to 4:15 p.m. to discuss all related items surrounding the testing efforts for this project. During End-to-End Testing the application test teams will meet daily.

10.2 Metrics and Measurements

Defect Tracking Metrics: Reports from Bug Tracker will be produced weekly and distributed to each application’s Project Manager, Development Lead, and Management.

The Testing Advocate for RDS will produce and submit a weekly defect summary report from QA Director to the Program Level Testing Advocate, who will incorporate with the Bug Tracker reports and distribute to all applicable parties.

10.3 Link to Bug Tracker

All test teams will use Bug Tracker for defect management with the exception of RDS, which is using QA Director. There is one project level entry in Bug Tracker for the Loyalty Program. The Bug Tracker link for this project is http://bugtracker/bug/(144skzvyk04ori45isa5rrju)/default.aspx

11 Testing Schedules

The testing schedule for the Loyalty Program will be based on the overall project schedule and the details for the project schedule are still a work in progress. The current project schedule section for the Loyalty Pilot – Development & System Test Phase currently starts in the project plan on ID 599 – 607 (this is subject to change). The Loyalty Program Project Schedule link is http://secure.macyspartners.com/sites/dunnhumby/Docs/MSTLoyalty/Program Documents/Loyalty Program Schedule (PDF).pdf

Note: Testing Advocates should start testing as soon as Developers have completed Unit Testing and there are available product areas ready to test.

11.1 High-Level Testing Milestones



http://bugtracker/bug/(144skzvyk04ori45isa5rrju)/default.aspx



Task/Milestone Testing Range Date

Pre-System Testing 01/18/2010 – 02/18/2010

System Testing 02/18/2010 – 04/19/2010

Integration Testing 02/18/2010 – 04/19/2010

Regression Testing 02/18/2010 – 04/19/2010

Acceptance Testing (E2E) Development & QA 02/18/2010 – 04/19/2010

UAT (Business Partners) 04/01/2010 – 04/19/2010

11.2 Link to Test Scheduler

Each Testing Advocate will setup a separate Test Scheduler entry for their application. The link to Test Scheduler is http://tsc/

12 Risks and Contingencies

Risks and contingencies are being tracked at the project level. If a project risk affects the overall testing, notify Ginene VanLierop to escalate the risk.

13 Assumptions, Constraints, and Dependencies

13.1 Assumptions

13.1.1 A Testing Advocate, Project Manager, Tech Lead, Development Lead, and Operations Advocate shall be assigned for each application area.

13.1.2 All projects shall record defects in Bug Tracker, Project Name: Macy’s Loyalty Program, Release Pilot with the exception of RDS, which will be using Changepoint.

13.1.3 Development Leads and Operations Advocates shall contact the QCO with any data or environment issues.

13.1.4 Testing Advocates shall verify their teams have access to all testing environments. Access shall be verified prior to the Ready To Test (RTT) checkpoint.

13.1.5 Testing environments shall be ready for each testing phase/level.

13.1.6 All application testing teams shall have their application’s data loaded into the various testing environments prior to testing.

13.2 Constraints

Resources available to perform testing may impact application team’s ability to produce quality results.

Un-configured environments may impact application team’s development and testing activity.



http://tsc/



13.3 Dependencies

The Loyalty Program application teams will identify testing dependencies.

Examples of testing dependencies are:

1. A requirement for another application team to provide (load or create) test data.

2. A requirement for another application to be functional in the test environment during testing.

3. A requirement for another team to process or validate output from testing.

14 Document References

Document Path/Location

Q4M Streamline (Beta) Document Assets for WT1

http://mymacys/applications/Q4M/Q4MBETA/Q4M BETA Release/Forms/Work Type 1.aspx

Q4M Streamline (Beta) Document Assets for WT2

http://mymacys/applications/Q4M/Q4MBETA/Q4M BETA Release/Forms/Work Type 2.aspx

15 Glossary of Terms

MST Glossary

http://intrafsg/glossary/FSG_Glossary.htm

16 Document History

Version Date Change Author

.01 12/11/09 Initial document creation Ginene VanLierop

1.01 1/12/10 Updated environment section. Updated link to the latest system context diagram.

Ginene VanLierop



http://intrafsg/glossary/FSG_Glossary.htm

http://mymacys/applications/Q4M/Q4MBETA/Q4M%20BETA%20Release/Forms/Work%20Type%202.aspx






17 Reviewers and Approvers

Version Name / BU®eviewer, (A)pprover or (B)oth

Disposition Date

1.0 Marc Bergroschtje / Stores Testing Advocate

R 12/17/09

1.0 Tina Arrowood / Logistics Testing Advocate

R 12/16/09

1.0 Matthew Johnson / POS Lorain Testing Advocate

R 12/15/09

1.0 James Wiggins / D2C Testing Advocate

R 12/17/09

1.0 Rosa Summers / Stores Testing Advocate

R 12/17/09

1.0 Cecilia Ungers (Bonnie) / Stores Testing Advocate

R 12/17/09

1.0 Andrea Perine / POS Credit Testing Advocate

R 12/17/09

1.0 Tammerra Tillman (Tami) Product Manager

R 12/17/09

1.0 Roland Demeter R 12/17/09

18 Appendix

N/A





19 Process Asset History

Release Date Change Author

Rel 3.3, Template v3.1

3/24/09 Added Process Asset History section to the template; FMT #9229 - Removed any guidance that allowed deletion of sections of the template (Introductory guidance, section 2 guidance and section 4 guidance were changed)

K.Hadfield

Rel 3.3.2

Template v3.2

8/25/09 Changed CARS to Quality Manger (QM) in guidance (3 places)

K.Hadfield



Loyalty Program Master Test Plan

Documents

Transcript of Loyalty Program Master Test Plan