i2 Integrated Testing Strategy [IBM—华为供应链全套方案]

2001 i2 Technologies, PROPRIETARY and CONFIDENTIALHuawei TechnologiesHUAWEI APS PROJECTINTEGRATED TESTING STRATEGYREVISION 1.0 / 4-SEPTEMBER-2002Overall Solution ArchitectureHuawei APS Project 2001 i2 Technologies, PROPRIETARY and CONFIDENTIALTABLE OF CONTENTSPURPOSE. 3INTRODUCTION. 3SCOPE. 4FUNCTIONS/SCENARIOS. 5ARCHITECTURE. 10TEST ENVIRONMENT REQUIREMENTS.10DEMAND PLANNING TO FORECAST NETTING.10FORECAST NETTING TO S&OP, MASTER PLANNING & PRODUCTION PLANNING FP. 11MASTER PLANNING SCP TO FACTORY PLANNING FP.12FACTORY PLANNING FP TO MASTER PLANNING SCP.13MASTER PLANNING SCP TO ALLOCATION PLANNING / ORDER PROMISING DF.14S&OP SCP TO SUPPLIER COLLABORATION SCC.15SUPPLIER COLLABORATION SCC TO MASTER PLANNING SCP.17REVISION HISTORY. 19MAJOR CHANGES SINCE LAST REVISION.19REQUIRED APPROVALS.20Overall Solution ArchitectureHuawei APS ProjectPage 3 of 28PURPOSEThis is a communication vehicle for the entire ISC project team including the APS team as well as the ERP team. It should be used by all of those who will be responsible for planning preparation and execution of test components. This document will be further substantiated by the Test Plans, which will define in detail the specific areas of testing for each level and type of test.INTRODUCTIONThis document constitutes the Testing Strategy for the APS BR1 implementation. It describes the overall test strategy to be adopted and defines the following:What is the scope of the modules to be tested? What are the key risks within that scope? What test needs to be performed to address those risks?When should the test be done? Who is responsible for performing the key testing activities?SCOPEThis section describes the scope of the APS BR1 solution, cover at a high level, the functions included, the application architecture, technical architecture and operational changes. The diagram below defines the scope of the APS BR1 implementation. It also shows the information flows between the ERP system and i2 APS.Overall Solution ArchitectureHuawei APS ProjectPage 4 of 28DemandPlanningDPForecast NettingFcNt_DFS&OP PlanningS&OP_SCPMaster PlanningMsPl_SCPProduction Planning &SchedulingOrPl_FPNetted forecast forLevel III itemsTier levelMake to StockDemand for CriticalLevel III Tier LevelWIPAllocationPlanning /Order PromisingOrPr_DFSupplierCollaborationSCCForecast Collaborationof Critical Items RM levelweeklyweeklydailydailydaily batchdailyreal timeAllocated ATP ofAITier levelSupply Commits RM levelLevel III forecast Tier levelHierarchy,Shipment History,Contract,Revenue History i2 APSDatabase Oracle 11iStagingForecastBacklog &ShippedOrder i2 APSDatabase Oracle 11iStagingNetForecastsProcurementsBOD, BOMBucket, EnterpriseIntransit, Inventory i2 APSDatabase Oracle 11iStagingPO Info Oracle 11iStagingStatic Info i2 APSDatabase Oracle 11iStagingBOD, BOMBucket, ECN,Enterprise, Intransit Inventory, PO,ProcurementsMaster Production ScheduleManufacturing OrdersShipments i2 APSDatabase Oracle 11iStagingSales OrderPromiseNewOrdersPO Info i2 APSDatabaseSupplyCommits RM levelOverall Solution ArchitectureHuawei APS ProjectPage 5 of 28FUNCTIONS/SCENARIOSThe Table below describes at a high level the scenarios that are to be considered during the testing activities. The Detailed Test Plans will expand in detail all functional areas that are to be tested.Demand Planning Business Scenarios Serial NumberCategories of ScenariosTarget User Scenarios within Category/CommentsDP-1NavigationAbility to view the data from region to customer group and likewise from customer group and region.DP-2Regional ForecastRegional Sales Forecast at Office and Product Group / Item LevelOverall Solution ArchitectureHuawei APS ProjectPage 6 of 28Serial NumberCategories of ScenariosTarget User Scenarios within Category/CommentsDP-3Judgmental ForecastJudgmental Forecast at Customer Group and Product Group / Item LevelDP-4New Product ForecastAbility to Forecast For New Products at Customer Group LevelDP-5Customer Group ForecastCustomer Group Forecast at Customer Group and Product Family LevelDP-6Product Marketing ForecastAbility to Store Historic Data in terms of Units & Lines for Contracts Signed, Contract ShippedDP-7Price CalculationAbility to Calculate Price of Product based on Historic Sales & Revenue DataDP-8Market Demand ForecastMarket Demand Forecast at Region and Product Group / Item LevelDP-9Statistical ForecastStatistical Forecast at Customer Group and Product Group / Item LevelDP-10Baseline ForecastBaseline Forecast at Region and Product Group / Item LevelDP-11Demand ConsolidationConsolidated Domestic Sales Forecast at Region and Product Group / Item LevelDP-12Contract InformationContract InformationDP-13Generate Total Demand ForecastDP-14Demand ForecastGenerate Demand Forecast in terms of Units DP-15Planning PercentagesCalculating Planning Percentages in Demand PlannerDP-16Component DemandDisaggregate Demand Forecast (Explosion of Planning BOM)DP-17Internal OrdersInternal OrdersDP-18Combined ForecastCombine Domestic, Overseas & Channel ForecastDP-19ArchivingArchivingDP-20KPI MeasurementKPI TrackingForecast Netting Business Scenarios Serial NumberCategories of ScenariosTarget User Scenarios within Category/CommentsFcNt-1Orders less than forecast in each planning bucket of a forecast bucketFcNt-2Orders more than forecast in some planning buckets but less than total forecast for the forecast bucketFcNt-3Orders more than total forecast in a forecast bucketFcNt-4Different AIs for one Sales Order (one ATO) consume forecast from different planning bucketsFcNt-5Forecast Profiling over Partial WeeksFcNt-6Avoiding non-integer daily quantities during Forecast ProfilingFcNt-7Netting of backlog ordersFcNt-8Forecast NettingBackward & Forward NettingSupply Planning Business Scenarios Serial NumberCategories of ScenariosTarget User Scenarios within Category/CommentsOverall Solution ArchitectureHuawei APS ProjectPage 7 of 28Serial NumberCategories of ScenariosTarget User Scenarios within Category/CommentsSCP-1Generation of Net Unconstrained Material RequirementsSCP-2Procurement of Constrained Material From Prioritized Alternate SuppliersSCP-3Procurement of Constrained Material From Proportional Alternate SuppliersSCP-4Frozen Procurement PeriodsSCP-5Blanket Purchase Orders and Finite Capacity SuppliersSCP-6Procurement PlanningPurchase Orders for Import Items Arriving in Hong KongSCP-7Allocation of Constrained Material Within a Demand LayerSCP-8Engineering Change Order PlanningSCP-9Version Switch PlanningSCP-10Substitute ComponentsSCP-11Material PlanningAI-ATO-PTO Pegging Information for ForecastSCP-12Critical Item-Level Inventory PlanningSCP-13Inventory PlanningAI-Level Inventory PlanningSCP-14Allocation of Constrained Capacity Within a Demand LayerSCP-15Capacity PlanningBuild-Ahead Limits in Capacity Constrained ConditionsSCP-16Demand PrioritizationSCP-17Demand ExpirationSCP-18Shipset PlanningSCP-19Order PlanningATO and POC should be delivered and planned togetherSCP-20ReportingIdentification of Constraining ItemsFactory Planning Business Scenarios Serial NumberCategories of ScenariosTarget User Scenarios within Category/CommentsFP-1Material assignment according to Demand priorityFP-2Plan For Tier1 Orders With Order Hold StatusFP-3Assign higher demand priority if one of its work order has been releasedFP-4Material planning for POC forecastFP-5R&D Material RequirementFP-6Account Shipment time to deliver to customerFP-7PTO From The Same Shipset Will Complete TogetherFP-8Assembly coordinate for (POC and ATO) under PTOFP-9Safety Stock PlanningFP-10ICP - DemandsOperation Level Material ConsumptionFP-11Consume From Inventory BuffersFP-12ICP - SuppliesAlternate part FunctionOverall Solution ArchitectureHuawei APS ProjectPage 8 of 28Serial NumberCategories of ScenariosTarget User Scenarios within Category/CommentsFP-13Engineering Change OrderFP-14Coordinate Work orders for finished AI and semi finished AIFP-15AI Work Order Generated Based On lot sizing rule FP-16Check BOM routing errorCheck BOM, Supplier Data And Unplanned Orders.FP-17Release Work-order with Material shortageFP-18Review factory problemsReview late orders and material assignmentFP-19WIP Reporting And PlanningFP-20Review frozen scheduleSchedule frozen periodFP-21Resource grouping for Production planningFP-22Multiple parallel resource planningFP-23Finite capacity balancing ruleFP-24Finite capacity balancingMinimum Utilization Required For Subcontractors Manual ProcessFP-25Review capacity planReview Capacity PlanFP-26Revise capacity planRevise capacity planFP-27Generate scheduleScheduling RuleFP-28Adjust scheduleAdjust ScheduleFP-29Consolidate PR Based On Time And Lot Sizing RuleFP-30Procurement Suggestion With Blanket Po NumberFP-31Vendor AllocationFP-32Forecast For VMI VendorsFP-33Delivery Schedule For JIT vendorsFP-34Procurement recommendationEach Factory Building At Shenzhen Should Consume Inventory From Its Own Building First, Output Factory Location For PO For Vendor Delivery InformationFP-35Output scheduleOutput Production ScheduleFP-36ReportingReportingOrder Promising Scenarios Serial NumberCategories of ScenariosTarget User Scenarios within Category/CommentsOrPr-1The net ATP and the AATP for each customer tier should be represented in DF and visible in DF WEB UI. OrPr-2Import customer allocations and ATPAdjust Allocations - A planner should be able to increase or decrease allocation among different tiers of customers.OrPr-3 Order processing should be done on the basis of customer segmented availability pictureOrPr-4New Order processingOrder processing should use the shipset information for an order so that all the line items belonging to a set are delivered on same time.Overall Solution ArchitectureHuawei APS ProjectPage 9 of 28Serial NumberCategories of ScenariosTarget User Scenarios within Category/CommentsOrPr-5An order can of two types: Inquiry and ATP commit. Inquiry orders should not consume any ATP and ATP commit sales orders should consume ATP. The order status will be “ENTER” for inquiry orders and “BOOK-HOLD” for the ATP commit orders OrPr-6Use the following search logic for ATP check. The details are descried in the description of the scenario.OrPr-7For each ATP check, DF should provide the customer site arrival date as well as the shipment start date.OrPr-8Some order lines can be added in a sales order for POC items. Provide ATP search ability for such PTO items, if required. It should be possible to provide standard procurement lead times for such items. OrPr-9For all the sales order lines, Oracle OM will provide a target sign date. DF while searching for ATP will look for availability of ATP after the target sign date.OrPr-10Order volume changes. An order quantity can be increased or decreased. An order increase will be considered a new order with the delta quantity. An order decrease should release the delta supply without affecting promise date.OrPr-11 Order Rescheduling(Customer initiated)Configuration Changes If a configuration change is requested for an existing order, then, this would have the logical effect of an order cancellation and reentry.SCC Business ScenariosSerial NumberCategories of ScenariosTarget User Scenarios within Category/CommentsSCC-1Huawei publish long term forecastSCC-2Supplier publish forecast commitSCC-3Review forecast mismatch exceptionSCC-4Forecast CollaborationReview forecast/commit mismatch differenceSCC-5Huawei publish Pull forecastSCC-6Huawei publish current Inventory levelSCC-7Supplier publish scheduled shipment quantitySCC-8Review projected inventorySCC-9VMI - ConsignmentReview stock out exceptionSCC-10Huawei publish Material requestSCC-11Supplier publish scheduled shipment quantitySCC-12Supplier publish current Inventory levelSCC-13Review projected inventorySCC-14VMI - JITReview stock out exceptionSCC-15Huawei publish new POSCC-16Huawei publish new delivery dates based on expedite POSCC-17Order Collaboration (PO)Supplier updates PO (promise date)Overall Solution ArchitectureHuawei APS ProjectPage 10 of 28Serial NumberCategories of ScenariosTarget User Scenarios within Category/CommentsSCC-18Huawei changes request date and/or quantity in OCSCC-19Supplier cancels POSCC-20Huawei cancels POSCC-21Supplier accepts PO change request by HuaweiSCC-22Huawei accepts PO change request by supplierSCC-23Review PO status summary viewSCC-24Supplier create ASNSCC-25Huawei Review ASNSCC-26Review over/under shipment exceptionSCC-27Order Collaboration (ASN)Review inbound delay of ASN exceptionSCC-28Review exception listSCC-29Review alert messagesSCC-30General Exception HandlingSend message to Huawei/SupplierOverall Solution ArchitectureHuawei APS ProjectPage 11 of 28ARCHITECTUREThe following diagram indicates the environments that will be used during the APS BR1 Test. The specific environment requirements for the defined levels of test will be covered in the Detailed Test Plan and once the technical specification development process has been completed.Full UATIntegrationUnit TestPrototypeExtended SITLimited UATERP SITERP UATCore SITStressManualFull UATIntegrationUnit TestPrototypeExtended SITLimited UATERP SITERP UATCore SITStressManualTEST ENVIRONMENT REQUIREMENTSThe SIT and UAT Detailed Test Plans will document the necessary test environments for each of these test levels.The current plan for testing activities is provided below. ActivityEnd DateDevelop Test Strategy4 Sep 2002Sign off Test StrategyComplete SIT Detailed Test PlanComplete Development of SIT Test CasesComplete SIT Environment SetupCommence Core SIT Commence Extended SITComplete SITComplete UAT Detailed Test PlanComplete UAT Environment SetupComplete Development of UAT Test CasesOverall Solution ArchitectureHuawei APS ProjectPage 12 of 28ActivityEnd DateCommence Limited UATCommence Full UATUAT Go/No Go Checkpoint (after Limited UAT)UAT Go/No Go Checkpoint (after Full UAT)Sign Off Acceptance Production Cut over Final Go/No Go CheckpointTEST DELIVERABLESThe following deliverables will be created:Test StrategyTest plans for unit, and internal integration by module teamsDetailed Test Plan for SIT & UATTest Schedules for each level of testingTest Objectives/Conditions MatricesTest CasesTest ResultsTest Defect and Test Management ReportsTest Summary ReportsTEST APPROACHThe objective of test APS BR 1 will be to ensure the APS modules, operations and networks that are in scope perform as specified in the business and technical documentation.FOCUSThe overall objective of test is to reduce the risks inherent in systems. The process must address and minimize those risks. Thus, areas are identified to assist in drawing attention to the specific risks or issues where test effort is focused and which must be handled by the test strategy.It is virtually impossible and economically not feasible to perform exhaustive testing. The limited resources must be used optimally while reducing cycle time and costs. This means that only necessary and sufficient tests must be performed thus avoiding under-testing and over-testing. This leads to the key question: What are the factors, or risks that are most important toThe user or the client?The developer from a system perspective?Overall Solution ArchitectureHuawei APS ProjectPage 13 of 28The service provider?The answer lies in developing and selecting Test Focus areas that will address or minimize risks. Test Focus can be defined as those attributes of a system that must be tested in order to assure that the business and technical requirements can be met.The focus areas of testing will be on the following: Test Focus AreaDescriptionPriorityAuditabilityAbility to provide supporting evidence to trace processing of dataMCompletenessEverything that is supposed to happen, doesHContinuity of ProcessingAbility to continue processing if problems occur. Include the ability to backup & recover after failureHCorrectnessAbility to process data according to prescribed rules. Controls over transactions and data field edits provide an assurance on accuracy and completeness of dataHMaintainabilityAbility to locate and fix an error in the system. Can also be the ability to make dynamic changes to system environment without making system changesHOperabilityEffort required to learn and operate the system (can be manual or automated)MPerformanceAbility of the system to perform certain functions within a prescribed timeHPortabilityAbility for a system to operate in multiple operating environmentsLReliabilityExtent to which system will provide the intended function without failingHSecurityAssurance that the system/data resources will be protected against accidental and or intentional modifications or misuseMTechnologyExtent to which new technology poses a risk to performance, reliabilityMUsabilityEffort required to learn and use the systemMTEST TYPESTesting types are logical tests that are to be conducted in isolation or as combined exercises in order to address the test focus areas. They will be performed during the designated Levels of Test (for example: Integration Test, Systems Integration Test, User Acceptance Test).Types of test are broadly classified as Functional Testing and Structural Testing.The purpose of functional testing is to ensure that the user functional requirements and specifications are met. Test conditions are generated to evaluate the correctness of the application. The following are some of the categories organized alphabetically:Functional Types of TestDescription PriorityAudit & Controls testTest any audit and controls requirementsMConversion/migration testTest that all conversion and migration processes work as requiredHDocumentation and Procedures testTest that the desktop procedures work as documented.Test that the business processes work as documented.Test that help facilities work as documentedMError Handling testTest that the applications handle all error situations (data and availability) without failing and according to the documented requirements.HFunctions/Requirements testTest that all requirements have been meet and that all functions perform, as they should, regardless of platform. HOverall Solution ArchitectureHuawei APS ProjectPage 14 of 28Functional Types of TestDescription PriorityInterface/Inter-system testTest that all interfaces between systems work correctly even under error situationsMInstallation testTest that any User Installation/Setup processes work Test that the Operational installation setup works as requiredMRegression testTest to ensure that none of the existing functionality that is to remain untouched has been adversely impacted. M, however it is a High Priority in the area of customizationsTransaction Flow (Path) testingTest that end-to-end transactions work as required, regardless of application/system boundaries HUsability testingTest that the usability of the system meets the usability requirements LThe purpose of structural testing is to ensure that the technical and housekeeping functions of the system/s work. It is designed to verify that the system is structurally sound and can perform the intended tasks.Its objective is also to ensure that the technology has been used properly and that when the component parts are integrated they perform as a cohesive unit. The tests are not intended to verify the functional correctness of the system, but rather that the system is technically soundStructural Types of TestDescription PriorityBackup and Recovery testingTesting that the backup and recovery processes work as requiredLContingency/Fallback testingTesting that the contingency plans and fall back plans work as intendedH Disaster Recovery testingTesting that the Disaster Recovery plan works as intendedN/AJob stream testingTesting that all scheduling and batch job processes work as requiredMOperational testingTesting that the operational instructions work as intendedMPerformance testingTesting that performance of both the application and the supporting architecture are as per performance requirements H in particular in the