Building A Migration Testing Strategy For Early Defect Detection

1y ago
32 Views
2 Downloads
645.11 KB
10 Pages
Last View : 5d ago
Last Download : 6m ago
Upload by : Julia Hutchens
Transcription

Building A Migration Testing StrategyFor Early Defect DetectionWhite Paperwww.indiumsoftware.com

IntroductionOrganizations always explore many waysto control the strength of their existingsystem while attempting to improve theiraccessibility or while considering anapplication re-design. More often the resultwill be moving from a traditional system toa client/server or web based architecture.The major reason for the conversion is tomake them available more broadly – thisoften includes the end users outside of theorganization and the consumer market. Inmany cases, these users expect a singlesign-on access, with some privacy as to theidentity or characteristics of the user. Atthis juncture the migration testing takes upits role.Generally, software migration requiresMigration Testing- The 3 W’sWhat?Mechanism to leverage the strength ofthe existing system while attempting toimprove the accessibility or whileconsidering an application's re-designWhy?Ensure CompatibilityEnsure existing FunctionalityHigh possibility of large number ofdefectsWhen?» Traditional Process – Post-MigrationTesting» New Process – Pre-Migration TestingTypes Of Migrationand distinct. The migration testing doesnot verify the function of the applicationsystem, but rather, the process that placesthat application system into a productionstatus. The process is attempting tovalidate the following:Proper programs are placed into theproduction status.Needed data is properly prepared andavailable.Operating and user instructions areprepared and used.performed until the results expected fromthe software migration have beenidentified. The results should bepredetermined and then tests can beperformed to validate the expected results.Most defects occur in the early stages of aproject but most defects are also found inits later stage, this costs 10 to 100 times asmuch to fix a defect in the later phases of aproject. Finding defects in the early stageof software development helpsorganizations significant savings to theirbottom line performance and also reducesthe impact on their brand. So there is aneed to get hold of the defects before theygain momentum.Database MigrationApplication MigrationOS MigrationServer MigrationHybrid MigrationDatabase MigrationUnderstanding DataResource SchedulingScoping the Requirements Accuratelyand On TimeData Quality FrameworkData Validation vs. Data TestingStrategyExample – Migrating from an older versionof database to a higher version (Oracle 9ito 10G)Testing ChallengesData in the source databases may getupdated during the testTable level and field level mappings arefrequently changedwww.indiumsoftware.com Indium Software

Application MigrationApplication ConsolidationApplication DevelopmentExisting-Application EnhancementTesting ChallengesUnderstanding the migration rulesFrequent data model changesDataExample – Migrating a system from ASP toASP .Net technology.Testing ChallengesMore time is spent in the requirementsphase to identify the scope of themigrated applicationCollecting information about businessflows/processes in absence of proper orcomplete documentation of legacyapplicationApplication MigrationIn information technology, migration is theprocess of moving from the use of oneoperating environment to anotheroperating environment i.e. in most cases, isthought to be a better one. Migration canbe small-scale, such as migrating a singlesystem, or large-scale, involving manysystems, new applications, or a redesignednetwork.Example – Migrating to Linux platform fromwindows platform.Testing ChallengesUnderstanding user applications andsettingsThe process flow in the new OS may varyfrom the existing OSServer MigrationThe process of moving data from onestorage pool to the next storage pooldefined in the hierarchyExample – Migrating from Windows Serverto Mainframe versOSNewDriversServer MigrationTraditional Migration TestingTraditionally, migrations have been testedas a form of post-migration testing. Wherein this strategy makes testing to startrelatively late in the overall process,becomes labor intensive and causes manydata-level errors. These limitations comeinto play particularly in highly regulatedcompanies where the required margins oferror are not feasible.Post-Migration TestingPost-Migration testing is performed oncethe migration is completed and the newenvironment is readily available forcarrying out the testing process.Post-migration is typically performed in atest environment and includes:Phase 1TestMigrationPhase 2PilotMigrationPhase 3ProductionMigrationPhase 4OperationPost-Migration ProcessTesting the throughput of the migrationprocess (number of records per unit time)Comparing the Migrated Records toRecords Generated by the DestinationSystem.Summary Verification.Comparing Migrated Records withSource.Migrated content has special considerations.www.indiumsoftware.com Indium Software

Additionally, an end-to-end testing can be carried out to ensure that maximum defects areaddressed.In the above approach, the sum of errors identified are very significant and with a muchA New Migration Testing StrategyPre-Migration TestingThe concept of pre-migration testing is not often covered during migration planning. Theprofessionals involved in migration planning are not much aware of comprehensivepre-migration testing and the value it can add to a migration and particularly thosemigrations that are considered complex. Pre-migration testing takes place prior to the actualmigration of any data, including test migrations.Phase 1PlanningPhase 2AnalysisPhase 3SetupPhase 4TestMigrationPhase 5PilotMigrationPhase 6ProductionMigrationPhase 7OperationTest Migration CompleteData Quality VerifiedPre-Migration ProcessPre-migration testing will assist withDefect Detection in Early Phase - Major Defects will be identified in the early phase ofmigration process. This at times will result in identifying incorrect requirements resulting inreduction of huge number of defects.Risk Reduction - We will be able to complete the migration ahead of the schedule. Defectsidentified/fixed in the earlier stages will result in high quality. Since all pre-measures havebeen taken care before the production migration, the actual down time is reduced. So riskwith respect to Schedule, Quality and Downtime is reduced in Pre-Migration testing.those are less when compared to the defects identified in the later stages. Overall cost ofthe project can be reduced in the Pre-Migration testing.Less challenges during production migration.Dawn of the New Migration Testing Strategybecause the basic requirement is that the new system will provide the correct outputscomparing to the old one. This requirement is reasonable, but very durable to achieve,because usually there is no similarity between the new and the legacy systems. Moreover,parameters, interfaces, etc.The method of testing migrated software which described below need to be fitted accordingto the special conditions that exist in each projectwww.indiumsoftware.com Indium Software

The testing group will be divided to three active teams.Acceptance Test (AT) Team – The famous testing team which approves the quality ofchanges or/and regression tests into real live environment.Operational Team – This team includes all the people that will use the system on a dailybasis in real live.Business Component Team – This team includes the business people from the legacysystem.The first two teams (AT and Operational) should work in parallel, but separately. Both will usemeaning some of the test cases will be executed by both teams and others will run only byon their regular test environments, while Operational will execute the test cases using thereal live configured machines.The Business Component team will spend equal time with each one of the other teams.Acceptance Test and Business ComponentAT team is responsible for designing, running and analysing all the business test case’sscenarios. Though it looks like a regular task for AT’s testers, it may require demanding(migrated), their business background and knowledge of the new system is zero or close tozero. Business Component team will guide and direct the AT team and more important, itwill verify and approve that the system results are accurate.In order to achieve the main system test role, it is mandatory to have many professionaltesters as possible. Professional tester must be well aware of the system and should alsobe talented, assertive, accurate and fluent.In order to approve the system quality, AT and Business teams will go over each result andapprove the correctness of: rates, wording, error handling, values, buttons, menus, files etc.Operational and Business Componenttests will be done on the intended real live machine which is configured with all the relevantparameters. The purpose is to approve connectivity, operability and infrastructure abilityof the entire system.Since Business Component team is familiar with the general system behavior, they willwork with the Operational team to approve elements like system performance, backups,recovery, daemons, down times etc. Stabilizing the entire system running is a timeconsuming issue and requires several testing intervals.www.indiumsoftware.com Indium Software

Different Phases of Migration TestingPhase 1: Pre-Migration Planning- Assess the feasibility of your migration with apre-migration impact assessment- Identify the key project resources and assignthemPhase 2: Project Initiation- Have a configuration management policy and- Create a stakeholder communication plansoftware in placeand stakeholder register- Create a high-level first-cut project planPhase 3: Landscape Analysis- Create a comprehensive data dictionary- Define the hardware and softwarerequirements for the later phases- Create a high-level source to target mappingspecification- Share the risk management process with thePhase 4: Solution Designteam and have them update the risk register- Create an edge design specification- Refine your project estimates- Define your production hardwarerequirementsPhase 5: Build & Test- Agree on the service level agreements for- Create a migration retreat policythe migrationlevels in the target- Create a gap-analysis process for measuringPhase 6: Execute & Validateactual vs. current progress- Keep an accurate log of SLA progress- Independently validate the migrationPhase 7: Decommission & Monitor- Complete your system retirement validation- Hand over possession of the data qualitymonitoring environmentUser Acceptance TestingUser acceptance testing provides an opportunity for the user community to interact withlegacy data in the destination system prior to production release and most often, this is thefirst such opportunity for the users. Attention should be given to reporting, downstreamfeeds, and other system processes that depend on migrated data.Production MigrationThough all of the testing is completed prior to the production migration, it does notguarantee that the production transition process will be smooth. Challenges seen at thispoint include procedural errors, and at times, production system configuration errors. If anautomated testing tool has been used for post-migration testing of data and content,executing another testing run is straightforward and recommended. If an automatedapproach had not been used, some level of sampling or summary verification is stillrecommended.www.indiumsoftware.com Indium Software

Migration Success Roadmapwww.indiumsoftware.com Indium Software

Analysis on Defects, Risk & Cost1. Defect Detection in Early PhasePost/Pre-Migration Testing – Defect ComparisonReduction of defects using Pre-Migration methodEarly defect identification results in transparency of requirementsEase in rework2. Risk ReductionPost/Pre-Migration Testing – Risk Level ComparisonEarly Completion of Development/TestingHigh in QualityReduction of Downtimewww.indiumsoftware.com Indium Software

3. Cost ReductionPost/Pre-Migration Testing – Cost Level ComparisonEarly Defect leads to low cost.Earlier a defect is found/fixed, the cost is less.Overall Cost is reduced in Pre-Migration testing.ConclusionThis new technique of early defect detection in migration testing fine-tunes the applicationpoint of iles/Migration Project Testing V3 fhelp/current/index.jsp?topic %2Fcom.ibm.ztpf-ztpfdf.doc org/wiki/Data migrationwww.indiumsoftware.com Indium Software

Chennai Bengaluru MumbaiToll-free: 1800-123-1191Sales Inquiriessales@indiumsoftware.comLondonGeneral Inquiriesinfo@indiumsoftware.com

A New Migration Testing Strategy Pre-Migration Testing The concept of pre-migration testing is not often covered during migration planning. The professionals involved in migration planning are not much aware of comprehensive pre-migration testing and the value it can add to a migration and particularly those migrations that are considered complex.

Related Documents:

Data Migration Planning Analysis, Solution Design and Development Mock Migration Pilot Migration Released Data Migration Active Data and User Migration Inactive Data Migration Post Migration Activities Small Bang The details for each step include: Data Migration Planing - Develop the migration strategy and approach, and define the scope,

Migration overview In the context of Migration Manager, migration is the process of promoting . A migration group can be either internal or user-defined. Internal migration groups are included with the product and are linked to other logically related migration groups called dependencies. You cannot modify internal migration

Resume a Migration Job 7-13 Suspend and Resume a Migration Job 7-15 Rerun a Migration Job 7-16 Terminate a Running Migration Job 7-16 Zero Downtime Migration Centralized Fleet Migration Management 7-16. 8 . Migrating from Amazon Web Services RDS to Oracle Autonomous Database. Setting Amazon

A data center migration is the movement of one (or more) . - Final Data Migration Plan - Test Migration - Migration - Post Migration Transition - 24/7/365 Support . hand and are using it relative to the migration project. You would be amazed how many people never ask, "Will this work for us in year two and .

HOW WE TALK ABOUT MIGRATION: THE LINK BETWEEN MIGRATION NARRATIVES, POLICY, AND POWER HOW WE TALK ABOUT MIGRATION: THE LINK BETWEEN MIGRATION NARRATIVES, POLICY, AND POWER 6 There is often a tipping point when feelings of acceptance shift and feelings of insecurity begin to dominate. Welcoming stances toward migration are not always permanent.

planning their migration to Amazon Web Services. In the current version, MPA consolidates the portfolio data in one place, helps in migration planning and provides the information required for validating the migration business case: On-Premises and equivalent AWS cost estimation, EC2 recommendations, migration strategy and migration project cost.

The Data Conversion & Migration strategy document aims to provide an overview of the BearingPoint . 1 The data conversion & migration strategy for the MTS project is heavily related to the cutover strategy, aswell as to the interface strategy. For both, a strategy document and detail plan will be produced (which are separate deliverables). .

Often academic writing is full of technical jargon-technical jargon is an essential ‘tool of the trade’ -jargon eases communication –speeds up exchange of ideas between other professionals-BUT it can also obscure: creates ‘them’ (ordinary ‘laypeople’ culture and [implied] elite ‘professionals’) Beginners don’t always know enough to see errors. Strategies for ‘Being