Data Migration Test and Strategy Plan - Vdraft

Download as doc, pdf, or txt
Download as doc, pdf, or txt
You are on page 1of 9
At a glance
Powered by AI
The key takeaways are validation and testing of data migration, different validation approaches like spot checking and record count, roles in data migration testing, assumptions made for testing.

The purpose of validation and testing is to verify compliance to requirements, perform sanity checks like data consistency and completeness.

The roles and responsibilities in data migration testing include project sponsor overseeing testing, business analyst defining test scenarios, and testers conducting the actual tests.

DATA MIGRATION VALIDATION AND TESTING

Origin/Author Approved by Date Approved

: : :

Document Version: [1.0]

Contents
1 DOCUMENT MANAGEMENT........................................................................3 1.1 Contributors...........................................................................................................3 1.2 Version Control......................................................................................................3 2 VAL DAT ON AND TE!T NG........................................................................" 2.1 Vali ation S!o"e.....................................................................................................# 2.2 Vali ation A""roa!$es..........................................................................................# 2.2.1 Spot Checking...................................................................................................4 2.2.2 Record Count.....................................................................................................4 2.2.3 Report ...............................................................................................................5 2.2.4 Test Types.........................................................................................................5 3 DATA M G#AT ON TE!T $DMT%...................................................................& 3.1 De%inition.................................................................................................................& 3.2 Roles an Res"onsibilities.....................................................................................& 3.3 Test Re'uire(ents ..............................................................................................) 3.# Test *arti!i"ants ....................................................................................................) 3.3 Test S!$e ule .........................................................................................................+ 3.# Assu("tions ...........................................................................................................+ " DATA M G#AT ON TE!T! AND OUTCOME!.............................................' #.1 Data Mi,ration Test S!enarios %ro( -usiness Re'uire(ents Do!u(ent ........+ #.2 Ot$er DMT S!enarios ............................................................................................ #.3 O"en Issues.............................................................................................................. #.# Do!u(ent Si,n O%%..................................................................................................

_______________________________________________________________________________ Page 2 of 9

1 Document M(n()ement
When completing this document, please mark any section that is not required as N/A. A brief description of why the section is not required should also be included.

1.1 Contri*utors
Please provide details of all contributors to this document. #o+e Sponsor Business Analyst (Owner) Application Analyst De eloper Testers Unit Capgemini Capgemini Capgemini Capgemini N(me

1.2 Version Contro+


Please document all changes made to this document since initial distribution. D(te Version "#$ Aut,or !ection A++ Amen-ment niti(+ Document .ersion 1.0

_______________________________________________________________________________ Page 3 of 9

2 V(+i-(tion (n- Testin)


2.1 Validation Scope This validation will need to ta e place to achieve the following!
%eri&ication o& the compliance to the requirements o& each o'(ect as de&ined in the C%$)$ as well as in the &ile layouts pro ided 'y !he *+tract !eam# ,eneral sanity checks such as row count, data consistency and completeness ('etween the Source and Oracle instances)# Spot checking - sampling o& data within the e+tracted &iles against the source system# Sign o&& the data &iles prior to their load into the D.! en ironment#

2.2 Validation Approaches "#$s will be responsible for %ata &alidation activities and will adopt the following approach!
Checking each o& the supplied data e+tract &iles against 'oth the corresponding C%$)$ /unctional Design and the layouts pro ided 'y !he *+tract !eam# 0ser &ield mappings (&ields on the Oracle ""i screens) will 'e pro ided in the data e+tract &iles and !he *+tract !eam will pro ide layouts to assist with this so that a column in the supplied data e+tract &ile can easily 'e re&erenced 'ack to &ield in ""i Spot checking a su'1set o& records in the data e+tract &iles against the data held in ""i 2eporting o& any data anomalies which can then 'e addressed 'y the Data *+tract !eam#

!he *+tract !eam will pro ide support to the S.*s in ad ance o& this acti ity to help them understand how data alidation can 'e per&ormed and which supporting tools - techniques can 'e used# 3n addition, the Capgemini &unctional team will 'e on hand to answer any queries during the data alidation acti ities 'eing undertaken 'y #
2.2.1 !/ot C,ec0in)

!his will in ol e checking &ields on the e+tract against the &ields on the &orm# !he purpose o& the spot checking is to pro ide con&idence that the e+tract process is e+tracting the correct &ields# 3n some cases, the S.*s would 'e reasona'ly e+pected to know in which &orm the rele ant data is iewa'le# 3n many cases, the detail o& which &orm shows the data has 'een included in the detail column,
2.2.2 #ecor- Count

_______________________________________________________________________________ Page 4 of 9

!his will in ol e checking the num'er o& records in the e+tract &ile against the detail o& where to &ind out the e+pected record count#

2.2.3

#e/ort

Standard or e+isting custom reports may need to 'e run in order to eri&y that the scope o& e+tract is correct# !he report &ield names may not match the &ield names in the e+tract#
2.2." Test T1/es

!he areas to 'e co ered 'y Data %alidation and 2econciliation !esting include4 %eri&ying data e+tract &ile quality %eri&ying data e+tract &ile completeness 3denti&ication o& any data gaps or issues with the supplied data e+tract &iles 2econciliation o& alues and record counts o& the data e+tract &iles

3 3.1

D(t( Mi)r(tion Test $DMT% De2inition

!he purpose o& Data .igration !est(D.!) is to ensure that the solution 'y the pro(ect meets the &unctional and non1&unctional requirements speci&ied in the 'usiness requirements# D.! may also identi&y issues that ha e not 'een speci&ied in the B2D such as those relating to usa'ility# D.! is the &inal step 'e&ore rolling out the solution# D.! is typically carried out 'y end users in an en ironment that closely models the real world# A well1managed D.! process will gi e the 5ro(ect Sponsor, pro(ect team and end users con&idence that the solution 'eing deli ered meets the requirements# !his document outlines the plan &or D.! o& the pro(ect deli era'les# !his document is a high le el guide and will initially 'e de eloped during requirements gathering as part o& the Business Analysis stage# Detailed test scripts-cases will 'e de eloped as part o& the D.! 5lan and will 'e used to record the results o& user testing# !esting itsel& and the &ormal recording o& D.! results takes place during the Acceptance stage#

3.2

#o+es (n- #es/onsi*i+ities


#es/onsi*i+ities Assist 5ro(ect Sponsor and-or 'usiness representati es with the creation o& a detailed test plan and schedule 2e iew scripts-cases and scenarios &or accuracy, completeness and sequencing# Con&irm appropriate test data is de&ined and made a aila'le &or testing Agree &ormat and scope o& D.! plan De&ine and agree acceptance criteria *nsure (with 5ro(ect .anager) that N(me

#o+e Business Analyst

5ro(ect Sponsor

_______________________________________________________________________________ Page 5 of 9

De eloper and Application Analyst !esters

detailed test scripts-cases, scenarios and instructions are made a aila'le to testers prior to the start o& D.! *nsure (with 5ro(ect .anager) that the test schedule is communicated and that D.! takes place at the agreed time &rame *nsure that 'usiness issues identi&ied during D.! are logged in the !est 6og %alidation o& D.! en ironment *+ecute test scripts-cases 2ecord test results

3.3 Test #e3uirements


D.! will take place 'eginning on 7insert date8 and end on 7insert date8 D.! will take place in 7insert location8# (Some testers may choose to per&orm some testing &rom their regular work location where this is possi'le and is agreed in ad ance with the 5ro(ect .anager and 5ro(ect Sponsor 5articipants will recei e training, guidance and instructions prior to the start o& D.! A &ully con&igured !*S! en ironment including all o& the &unctionality and adequate !*S! data will 'e pro ided &or D.! !est scripts-cases and scenarios will 'e prepared prior to the start o& D.! !echnical and 'usiness support will 'e pro ided &or test participant during D.! D.! participants will conduct the tests and record results in the !est 6og-932A or other &ormat speci&ied 3ssues recorded in the 932A !est 6og (and-or other test documentation) will tracked 'y the 5ro(ect .anager and 5ro(ect Sponsor

3."

Test 4(rtici/(nts

!esting participants must include representati es &rom all areas who will use or 'e impacted 'y the solution# N(me Unit #e/resenteTestin) Are( o2 #es/onsi*i+it1 *nsure the 'usiness requirements are met 'y testing, the en ironment and any re1work# %alidate the test criteria and ensure the test en ironment allows testing o& the 'usiness requirements# 2e1work code where necessary to allow success&ul test results# !est the 'usiness requirements according to the tests de&ined in this test document and record the results o& tests

_______________________________________________________________________________ Page of 9

3.3 Test !c,e-u+e


Acti.it1 Con&irm testers &or D.! Con&irm test scenarios, test data and scripts-cases *nsure D.! en ironment is con&igured &or testing i#e# new &unctionality and test data is migrated to the !*S! en ironment prior to the start o& D.! O ersee testing 'y D.! participants #es/onsi*i+it1 5ro(ect Sponsor - Business Assurance Coordinator 5ro(ect Sponsor - Business Assurance Coordinator Business Analyst 5ro(ect Sponsor - Business Assurance Coordinator Business Analyst Systems Analyst - Designer !echnical Architect 5ro(ect Sponsor - Business Assurance Coordinator T(r)et D(te D(te Com/+ete-

3.4 Assumptions
!he D.! en ironment will 'e a aila'le and &ully con&igured ahead o& the D.!# !he 'usiness team has re iewed and accepted &unctionality identi&ied in the Business 2equirements Document (B2D) and System Design Document (SDS)# Code walkthroughs-re iews ha e 'een completed 'y the De elopment !eam and signed o&& as part o& the 5eer 5ro(ect Build 2e iew (55B2) 3ntegration testing, including where rele ant load and testing, has 'een completed and signed o&& as part o& the 5eer 5ro(ect 3ntegration 2e iew# !esters will test the &unctionality documented in the appro ed B2D (taking into account any changes in 'usiness requirement su'sequently agreed 'y the 5ro(ect !eam) 2esources identi&ied in this plan are a aila'le to conduct the D.! and address issues as they are raised 'y the test team# 'usiness Analyst should record any additional assumptions here

!he 5ro(ect .anager must noti&y the 5ro(ect Sponsor i& any o& these assumptions are not correct 'e&ore commencing the D.!#

" D(t( Mi)r(tion Tests (n- Outcomes


".1 D(t( Mi)r(tion Test !cen(rios 2rom 5usiness #e3uirements Document
0ser testing should 'e 'ased on the test scenarios and acceptance criteria identi&ied in the Business 2equirement Document# Any de iation &rom these scenarios should 'e noted here#

_______________________________________________________________________________ Page ! of 9

5#D #e2

!cen(rio 6 Acce/t(nce Criteri(

Teste51

D(te Teste-

Outcome $4A!! 6 7A L%

5#D #e2

Notes on Test (n-6or Test Outcome

4.2 Other DMT Scenarios


Additional test scenarios used in testing 'ut not sourced &rom the Business 2equirements Document should 'e identi&ied here# !he (usti&ication &or including the scenario in the D.! must also 'e recorded#
#e2 Test !cen(rio (n- Acce/t(nce Criteri( Teste51 D(te TesteOutcome $4A!! 6 7A L%

#e2

Notes on Test (n-6or Test Outcome

".3 O/en ssues


Any issues identi&ied during D.! must 'e added to the !est 6og# 5lease summarise or insert a copy o& any open issues &rom the 932A !est 6og# 3t may 'e agreed that D.! can 'e signed o&& while some issues remain open please pro ide details o& the D.! impact o& each open issue#
5#D #e2 8 #A Test Lo) #e2 ssue !umm(r1 m/(ct on DMT !i)n O22

(in to updated )*+A Test (og

"." Document !i)n O22


Please add other signatories where required
4ro9ect M(n()er Name %ate "igned ,ff

_______________________________________________________________________________ Page " of 9

4ro9ect !/onsor 5usiness An(+1st Add other signatories here

Name Name

%ate "igned ,ff %ate "igned ,ff

_______________________________________________________________________________ Page 9 of 9

You might also like