Model driven testing (MDT) provides several advantages over traditional code-based testing approaches. MDT allows testing to be integrated into the design process, enabling frequent and early testing. Test architectures and test cases can be automatically generated from models, using techniques like animated sequence diagrams to simulate scenarios and effectively record test cases. This helps improve requirements and code coverage at lower cost and in less time compared to traditional testing approaches.

1. Model Driven Testing (MDT): Los modelos al servicio de las pruebas Francisco J. López Minaya Rational Technical Sales Specialist

3. Today’s Systems are complex…

15. Development Process is Evolving… Model Driven Development MDD t 1960 1970 1980 1990 2000 2010 ASM C

16. Embedded Market Forecasters Documented in “ What Do You Do When the Horse You’re Riding Drops Dead? Why Model Driven Design is Emerging as a Preferred Best Practice”, March 2007 Advantages of Model Driven Development - Proven!

37. Manually Define a TestArchitecture (aka TestBench) for each class/SUT Develop TestCases Manually by writing code Execute Test Cases on Host (code level) Execute Test Cases on Target (code level) Code Level Testing Model Driven Testing Basic Testing Process: Code vs. Model Automatically Generate a TestArchitecture (aka TestBench) for each class/SUT

38. Basic Testing Process: Code vs. Model Automatically Generate a TestArchitecture (aka TestBench) for each class/SUT Let ATG Automatically Generate TestCases Develop TestCases Interactively Code Flow Charts Manually Define a TestArchitecture (aka TestBench) for each class/SUT Develop TestCases Manually by writing code Execute Test Cases on Host (code level) Execute Test Cases on Target (code level) Animated Sequence Diagrams Requirements Sequence Diagrams Auto Generated TestCases Code Level Testing Model Driven Testing

39. Basic Testing Process: Code vs. Model Automatically Generate a TestArchitecture (aka TestBench) for each class/SUT Let ATG Automatically Generate TestCases Develop TestCases Interactively Code Manually Define a TestArchitecture (aka TestBench) for each class/SUT Develop TestCases Manually by writing code Execute Test Cases on Host (code level) Execute Test Cases on Target (code level) Regression (Animated)Sequence Diagrams Requirements Sequence Diagrams Activity Diagrams Code Level Testing Model Driven Testing Hand written TestCases  I II III IV V Auto Generated TestCases

40. Basic Testing Process: Code vs. Model Automatically Generate a TestArchitecture (aka TestBench) for each class/SUT Let ATG Automatically Generate TestCases Develop TestCases Interactively Code Activity Diagrams Manually Define a TestArchitecture (aka TestBench) for each class/SUT Develop TestCases Manually by writing code Execute Test Cases on Host (code level) Execute Test Cases on Target (code level) Execute Test Cases on Host (code/model level) Execute Test Cases on Target (code/model level) Regression Sequence Diagrams Requirements Sequence Diagrams Code Level Testing Model Driven Testing

41. Basic Testing Process: Code vs. Model Very high very early Very low; measured late Typical Requirements Coverage Models (and optionally source code) Source code Configuration managed artifacts Yes, as Sequence Diagrams No Automatic Test Case Generation Part of the Model Requires external tools Traceability to Requirements Model (defect sequence diagrams) Code and text Communicating defects Very Positive Very Negative Competitiveness Models; Easy to do; Done very early Code; Hard to do; Done late Requirement Based Testing Change configuration parameters Review and rewrite all appropriate code Porting test cases to new platform/OS Code, Flowcharts, Sequence Diagrams Scripts, code Test Case authoring Model-Driven Testing Code-Driven Testing Aspect

46. © Copyright IBM Corporation 2008. All rights reserved. The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. References in these materials to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities referenced in these materials may change at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. IBM, the IBM logo, Rational, the Rational logo, Telelogic, the Telelogic logo, and other IBM products and services are trademarks of the International Business Machines Corporation, in the United States, other countries or both. Other company, product, or service names may be trademarks or service marks of others. Francisco J. López Minaya Rational Technical Sales Specialist [email_address]