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

Huawei TechnologiesHuawei APS ProjectIntegrated Testing StrategyRevision 1.0 / 4-September-2002TABLE OF CONTENTSPURPOSE3INTRODUCTION3SCOPE4Functions/Scenarios5ARCHITECTURE10Test Environment Requirements10Demand Planning to Forecast Netting10Forecast Netting to S&OP, Master Planning & Production Planning FP11Master Planning SCP to Factory Planning FP12Factory Planning FP to Master Planning SCP13Master Planning SCP to Allocation Planning / Order Promising DF14S&OP SCP to Supplier Collaboration SCC15Supplier Collaboration SCC to Master Planning SCP17REVISION HISTORY19MAJOR CHANGES SINCE LAST REVISION19REQUIRED APPROVALS20PurposeThis 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.Functions/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 LevelDP-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-13Demand ForecastGenerate Total Demand ForecastDP-14Generate 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-1Forecast NettingOrders 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-8Backward & Forward NettingSupply Planning Business Scenarios Serial NumberCategories of ScenariosTarget User Scenarios within Category/CommentsSCP-1Procurement PlanningGeneration 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-6Purchase Orders for Import Items Arriving in Hong KongSCP-7Material PlanningAllocation of Constrained Material Within a Demand LayerSCP-8Engineering Change Order PlanningSCP-9Version Switch PlanningSCP-10Substitute ComponentsSCP-11AI-ATO-PTO Pegging Information for ForecastSCP-12Inventory PlanningCritical Item-Level Inventory PlanningSCP-13AI-Level Inventory PlanningSCP-14Capacity PlanningAllocation of Constrained Capacity Within a Demand LayerSCP-15Build-Ahead Limits in Capacity Constrained ConditionsSCP-16Order PlanningDemand PrioritizationSCP-17Demand ExpirationSCP-18Shipset PlanningSCP-19ATO and POC should be delivered and planned togetherSCP-20ReportingIdentification of Constraining ItemsFactory Planning Business Scenarios Serial NumberCategories of ScenariosTarget User Scenarios within Category/CommentsFP-1ICP - DemandsMaterial 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-10Operation Level Material ConsumptionFP-11ICP - SuppliesConsume From Inventory BuffersFP-12Alternate part FunctionFP-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-17Review factory problemsRelease Work-order with Material shortageFP-18Review late orders and material assignmentFP-19Review frozen scheduleWIP Reporting And PlanningFP-20Schedule frozen periodFP-21Finite capacity balancingResource grouping for Production planningFP-22Multiple parallel resource planningFP-23Finite capacity balancing ruleFP-24Minimum Utilization Required For Subcontractors Manual ProcessFP-25Review capacity planReview Capacity PlanFP-26Revise capacity planRevise capacity planFP-27Generate scheduleScheduling RuleFP-28Adjust scheduleAdjust ScheduleFP-29Procurement recommendationConsolidate 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-34Each 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-1Import customer allocations and ATPThe net ATP and the AATP for each customer tier should be represented in DF and visible in DF WEB UI. OrPr-2Adjust Allocations - A planner should be able to increase or decrease allocation among different tiers of customers.OrPr-3 New Order processingOrder processing should be done on the basis of customer segmented availability pictureOrPr-4Order processing should use the shipset information for an order so that all the line items belonging to a set are delivered on same time.OrPr-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-10 Order Rescheduling(Customer initiated)Order 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-11Configuration 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-1Forecast CollaborationHuawei publish long term forecastSCC-2Supplier publish forecast commitSCC-3Review forecast mismatch exceptionSCC-4Review forecast/commit mismatch differenceSCC-5VMI - ConsignmentHuawei publish Pull forecastSCC-6Huawei publish current Inventory levelSCC-7Supplier publish scheduled shipment quantitySCC-8Review projected inventorySCC-9Review stock out exceptionSCC-10VMI - JITHuawei publish Material requestSCC-11Supplier publish scheduled shipment quantitySCC-12Supplier publish current Inventory levelSCC-13Review projected inventorySCC-14Review stock out exceptionSCC-15Order Collaboration (PO)Huawei publish new POSCC-16Huawei publish new delivery dates based on expedite POSCC-17Supplier updates PO (promise date)SCC-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-24Order Collaboration (ASN)Supplier create ASNSCC-25Huawei Review ASNSCC-26Review over/under shipment exceptionSCC-27Review inbound delay of ASN exceptionSCC-28General Exception HandlingReview exception listSCC-29Review alert messagesSCC-30Send message to Huawei/SupplierArchitectureThe 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.Test 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 CasesCommence 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 Strategy· Test plans for unit, and internal integration by module teams· Detailed Test Plan for SIT & UAT· Test Schedules for each level of testing· Test Objectives/Conditions Matrices· Test Cases· Test Results· Test 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 to· The user or the client?· The developer from a system perspective?· The 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