Product Modeling and Model Testing SAP s Product Modeling Environment (PMEVC) + espline s Avenue Enhancements

Transcription

1 Product Modeling and Model Testing SAP s Product Modeling Environment (PMEVC) + espline s Avenue Enhancements Demonstration and Discussion SAP Product Configurator Info Day Chicago 12 March 2013 David Silverman Governance and Compliance to Best Practices for your VC Model Changes

2

3 Software Built for You Governance Control Model Changes Collaborate on model development using Team Edition View Model Changes or compare across systems, clients Document Models automatically, add & share comments Model Health Check Report best practice deviations, IPC incompat. Auto-Test VC Changes or whole models Integrate with SAP: VC/IPC Master Data (incl. BOM, Routings), Quotes & Orders. Transform & Translate Models, eg. to/from non- SAP Configurators, Mass Changes Governance and Compliance to Best Practices for your VC Model Changes

4 PMEVC with Custom Buttons Governance and Compliance to Best Practices for your VC Model Changes

5 Introducing the VC App Exchange Find and Try Innovative VC Apps from PMEVC

6 Display Current Model as a Web Page

7 Health Check Reports Issues Specific to Your Models IPC Compat., Perf, Style,

8 Compare Two Model Revisions Over Time, or Across Systems/Clients

9 Run Automatic Testcases for the Current Model in ConfigScan

10 Edit Automatic Testcases for the Current Model in ConfigScan

11 PME VC Buttons and Apps

12 Addendum Do More with Less Effort and Higher Quality via Automatic Testing Still relevant; Originally presented at: Tuesday October 6 th 2009 Track 3 Partner solution 2009, Fysbee - espline

13 Presentation Flow 1. Why Improve Testing Practices? 2. Usage Scenarios for Automatic Testing 3. How ConfigScan Meets the Requirements 4. Illustrated Usage Scenarios Taming Wild Modeling Change-Driven Testing 5. ROI and Benefits of Auto-Testing 6. Q&A

14 Raise Your Hand If You implemented VC do you still get incorrect orders? Ever unable to sell an option to a customer? Can you present the entire offering in the configurator? Modeling errors sometimes get caught by users? You do NO testing? You only test in Production? You do only MANUAL testing? You do AUTOMATIC testing?

15 Why Invest in Automatic Testing? -1 Related to: Why did your company invest in VC? Avoid order rejections due to inconsistencies, guide users towards valid configurations, lower the cost of maintaining product data, expose the whole product range for sale, handle combinatorial explosion of possible configurations, reduce time to create an order The same arguments apply to automatic testing. Without testing, the chance that you have not solved these problems is very high. With manual testing, your chances are better, but why not apply the same reasoning and efficiencies as you did when you decided to go variant? This implies an automatic testing requirement.

16 Why Invest in Automatic Testing? -2 Three common objections why NOT: Time, Money, Inertia. Testing costs time, manual testing costs lots of time, and seems to only verify what your modelers knew already, the basics basically work because they already spent a lot of their time manually testing and correcting! TIME: Write Once, Run Many Times / More Quickly, Reliably MONEY: You run tests much more frequently, thus catching errors before their costs escalate. Your modelers and testers become more productive do more with less. INERTIA: You can safely "refactor" your rules without adding risk due to destabilization of your working

17 Why Invest in Automatic Testing? -3 Automatic testing with a test development environment provides crucial business benefits, including: Early detection of defects => lower cost per defect Productivity improvements for creating and maintaining models, tests Reduced risk of errors when changing or introducing new models Shorter delays between specification change and delivery Shorter release cycles Metrics on quality, model development velocity Happier and more productive staff, with more time to focus on business needs!

18 Why a Test Development Environment-1 For modelers and testers: A surprising fact from the programming world: automatic test frameworks for building and running tests increase developer productivity. This is true for modeling, too. => You need ways to create and maintain testcases quickly. Reduce delays between specification of a new product or feature or change, and its availability to users A good part of the delay is due to modelers searching for a solution, verifying that it works, verifying that it does not break other parts of the solution or other products configurations. Similarly for delays in implementing model corrections.

19 Why a Test Development Environment-2 This can be directly addressed by: Creating a shared testcase repository that enforces the business specification of your products Giving modelers the ability to run the testcases during development. (See prior CWG talk on Test-Driven Development, Extreme Modeling ). Multiple testing runs cost almost nothing!

20 Why a Test Language? Configurator-independent abstract language enables reuse of testcases across configurators eg. for migration projects, comparison of 2 configurators The requirement: be able to specify a large number of configurations in an output-oriented way ignoring the internals of a specific product model or even configurator. Without recreating your rules, in other words.

21 Why a Test Engine? Stop rewriting and maintaining code to run tests, in every testcase Declarative tests require less maintenance = more tests/quality per $

22 Why a Test Repository? Central maintenance, access enables control, collaboration, reuse of testcases, metrics Integrate into your development methodology and release process

23 Why Not Solve with Offshore Resources? Many possible configuration combinations means even your offshore resources would be unable to keep up. Hard to verify that manual tests were done correctly or done at all. By switching to automatic testing, you can reduce testing staff, do more with less, get verifiable results quickly, and focus your human resources on: creating and maintaining testcases once running frequently further increasing quality specific to a release

24 Presentation Flow 1. Why Improve Testing Practices? 2. Usage Scenarios for Automatic Testing 3. How ConfigScan Meets the Requirements 4. Illustrated Usage Scenarios Taming Wild Modeling Change-Driven Testing 5. ROI and Benefits of Auto-Testing 6. Q&A

25 2. Usage Scenarios for Automatic Testing-1 Releasing New Products Updating Existing Products Evaluating Alternative Solution Approaches, Model Designs Configurable Product Data Migration Into or Out of SAP Compare legacy configurator to SAP Compare SAP configurator to 3rd-Party Compare VC to IPC KB Compare SAP System/Client to SAP System/Client Troubleshooting Urgent Errors in Production Modeler Productivity Optimization Tester Productivity Optimization

26 2. Usage Scenarios for Automatic Testing-2 Refactoring Models for Performance Optimization For Lower Cost of Maintainence Documentation of Solution / Anti-Solution Patterns Capture and retain your staff s and consultants expertise, and hard-won knowledge, by creating sample models and illustrative testcases.

27 Presentation Flow 1. Why Improve Testing Practices? 2. Usage Scenarios for Automatic Testing 3. How ConfigScan Meets the Requirements 4. Illustrated Usage Scenarios Taming Wild Modeling Change-Driven Testing 5. ROI and Benefits of Auto-Testing 6. Q&A

28 How ConfigScan Meets Auto-Testing Requirements-1 ConfigScan has a broad feature set for testing VC models within your ERP environment, including: Innovative, Hi-Productivity Test Development Environment, Create/Maintain/Run/Report Testcases that come from: Sales or Purchase Order History CU50 Configuration Simulation inside SAP ERP. External sources eg. by a test generator program or external GUI, import from Excel or XML Testcase Editor knows and shows all the objects in your model, saves you from having to know and remember yet another language s syntax or retype names.

29 How ConfigScan Meets Auto-Testing Requirements-2 Clear and complete testcase language you already know Reusable testcases, hierarchical organization Central storage of testcase repository in Document Management System, other options Results are stored in standard SAP Application Log. Performance test support

30 Presentation Flow 1. Why Improve Testing Practices? 2. Usage Scenarios for Automatic Testing 3. How ConfigScan Meets the Requirements 4. Illustrated Usage Scenarios Taming Wild Modeling Change-Driven Testing 5. ROI and Benefits of Auto-Testing 6. Q&A

31 Taming Wild Modeling Change-Driven Testing-1 Feedback from Testing Workshop at last year s CWG Berlin 2008 how do you test? We focus our effort on what has changed, since it is most likely to cause problems. In an ideal world, Business would pass specification of new products, changes, and defects to the modeling team. These specs would be translated into testcases that would be implemented in parallel with the implementation of the requirement.

32 Taming Wild Modeling Change-Driven Testing-2 In practice, it is not uncommon (raise your hand if ) for the modeling team to get working immediately with no thought of creating a testcase until later in the process, with some specs handed over orally and forgotten by UAT and pre-release testing time. ( all drivers think they are above average, and all modelers and programmers expect their code to run the first time). The opposite of Wild = Governance In this scenario, by detecting changes with an automatic tool (whether you implemented ECM or not), you won t leave changes to chance, and can ensure that each change to a rule, characteristic, BOM item, etc. has a test. <<Integration between espline Avenue Compare and Fysbee ConfigScan>>

33 Presentation Flow 1. Why Improve Testing Practices? 2. Usage Scenarios for Automatic Testing 3. How ConfigScan Meets the Requirements 4. Illustrated Usage Scenarios Taming Wild Modeling Change-Driven Testing 5. ROI and Benefits of Auto-Testing 6. Q&A

34 ROI of the Testing Process with ConfigScan Creation Maintenance Regression Testing Old Process With ConfigScan 10 Modelers 5 Testers Gain 40% on Test 10 Modelers 3 Testers 10 Modelers 5 Testers Gain 60 % on Test 10 Modelers (*) 2 Testers?? Push Button! At no Cost Indicator Old Process With ConfigScan Testing Duration (Creation) Testing Duration (Maintenance) Regression Testing Testing Schedule Traceability Quality 30% to 100% of Modeling Time depending on model complexity 10% to 100% of Modeling Time depending of model/change complexity No time to do it (it worked => it will work ) Sequential (after delivery) Bug Tracking System (Mantis), but no visibility on really passed tests. Hard work to build quality indicator Less than 30% of Modeling Time Less than 30% of Modeling Time For free! Test spec. in parallel All Scenarios have a log Measured for complete validation campaign

35 KEY Points Testing Costs Money! Not testing costs MORE money! The ability to use formal testcases for error reporting and communication between tester and modeler avoids a lot of misunderstandings! Breakpoint / Stop-at-Error facility helps modelers avoid spending all day long in CU50! Using a growing regression test base provides business continuity, especially with multilevel configuration. With ConfigScan it is almost at no Cost! Quality and Automatic Testing save money!

36 Presentation Flow 1. Why Improve Testing Practices? 2. Usage Scenarios for Automatic Testing 3. How ConfigScan Meets the Requirements 4. Illustrated Usage Scenarios Taming Wild Modeling Change-Driven Testing 5. ROI and Benefits of Auto-Testing Q&A

37 Customer Testimonial "...We've been using the ConfigScan Suite for the past 2 years. We have implemented an automated testing process for our configuration models. With ConfigScan, only two offshore resources are necessary for testing all our models. No doubt, ConfigScan is a major asset for ensuring our models' quality and significantly reducing maintenance cost..." Alain Desry Spring 2009

38 For More Information See New SAP VC Book espline and Fysbee contributed two chapters relevant to automatic testing, and management of VC models. 7.6 Product Model Validation with ConfigScan 7.7 Managing Variant Configuration

39 Product Modeling and Model Testing SAP s Product Modeling Environment (PMEVC) + espline s Avenue Enhancements Contact Information Don Cochran Don.Cochran@eSpline.com +1 (614) David Silverman David.Silverman@eSpline.com Governance and Compliance to Best Practices for your VC Model Changes