1. From Desktop to Wearable to Testing Belgium Testing Days 2015 Alfonso Nocella, Maveryx

2. 2 Summary  From Desktop to Mobile to Wearable  Testing : Diversity leads to Complexity  “SHE” : Shrink, Hide, Eliminate All trademarks referenced herein are the properties of their respective owners.

3. 3 Summary All trademarks referenced herein are the properties of their respective owners.

4. 4 From Desktop to Mobile to Wearable UNIVAC I – 1951 Apple II – 1977 IPhone – 2007 Glass – 2012

5. 5 Different devices, architectures … 5.8’’ – … – 10’.7’ 2.8’’ – … – 6’’

6. 6 Different operating systems …

7. 7 Different frameworks …

8. 8 And now… (?!?) Devices… Applications…

9. 9 Cross-Platform App Development Companies are requested to deliver their software products not only for PC but also, and sometimes primarily, for mobile devices And Testing? (automation)

10. 10 Summary All trademarks referenced herein are the properties of their respective owners.

11. 11 Diversity is often synonym of Complexity Problem: proliferation of test artifacts (tools, scripts, data, UI maps …) to be developed, captured, & maintained upon passing from one environment to another, with a significant impact on time, effort and costs.

12. 12 Summary All trademarks referenced herein are the properties of their respective owners.

13. 13 “SHE” : handle diversity “SHE” : Shrink, Hide, Embody (design principle) [J. Maeda : The Laws of Simplicity]  “SHE” : Shrink, Hide, Eliminate (software testing) Shrink Shrink : test design Hide Hide : complexity Eliminate Eliminate: unnecessary artifacts (UI Maps et al.)

14. 14 An Example Test Tool : Maveryx Test Data : Excel Test IDE : Eclipse (Juno) JDK / JRE : v1.8 Android : v5.0

15. 15 Shrink. Test Design. Write once, run many. Design tests that can be run without modification on different devices. Pros: reduced number of scripts to be developed and maintained Cons: could add a little bit complexity into the tests

16. 16 Shrink. Method. 1.Identify common features 2.Create the tests (common features) 3.Identify differences 4.Manage differences 5.Create new tests (for unmanageable differences) (*) Use a Data-driven approach (both for UI and test data) (**) Could use a Keyword-driven approach

17. 17 Shrink. Method. 1.Identify common features 2.Create the tests 3.Identify differences 4.Manage differences 5.Create new tests Common features are all characteristics (functional, UI…) that can be tested “as is”, without any modification.

18. 18 Shrink. Method. 1.Identify common features 2.Create the tests 3.Identify differences 4.Manage differences 5.Create new tests … and much more …

19. 19 Shrink. Method. 1.Identify common features 2.Create the tests 3.Identify differences 4.Manage differences 5.Create new tests Differences occur in: Labels (in yellow) Paths (e.g. menus, screens…) … And are: Manageable (in the same script) Un-manageable

20. 20 Shrink. Method. 1.Identify common features 2.Create the tests 3.Identify differences 4.Manage differences 5.Create new tests Use a data driven approach to store data for each platform.

21. 21 Shrink. Method. 1.Identify common features 2.Create the tests 3.Identify differences 4.Manage differences 5.Create new tests

22. 22 Hide. Complexity. Supporting, device-dependent functions should be “hidden” to the testers and managed into the framework or in high-level libraries. Pros: more readable and maintainable tests. Testers stay focused on writing tests rather than on supporting functions.

23. 23 Hide. Complexity. Supporting / device-dependent functions concern: Launching the application-under-test Switch between “views” (click, swipe, …) Select the device / platform to run the test on Using Navigation buttons ( ) …

24. 24 Hide. Complexity. Example Select the device / platform to run the test on In general you can use JUnit’s @Rule feature or custom annotations

25. 25 Eliminate. The Unnecessary. Automating GUI-based applications on multiple devices and platforms require many sets of GUI Maps (aka Test Object Maps) to be captured and maintained. It is a huge set of data to handle and a time consuming task. Pro: …work on the important: write more tests. Cons: you have to learn or develop a “new” Test Engine.

26. 26 Eliminate. GUI Maps. A GUI Map describes the test objects in the application-under-test It is used by the automation tool to recognize the UI objects to test Each script is associated with a GUI Map Our Approach A test automation engine in continuous development at Maveryx together with the Engineering dept. of Napoli University to which contributed also people from Nokia and Intel

27. 27 Eliminate. GUI Maps. At runtime during test execution takes “snapshots” of the current user interface  …and turn them into a XML documents Information about UI elements includes: Name / Identifier {caption, tooltip …} Role / Type {button, text, checkbox …} Status {enabled, editable …} … GUI MAP or Image

28. 28 Eliminate. GUI Maps. “Classical” to Fuzzy matching algorithms to unambiguously recognize and locate objects during test execution “Geolocation” of objects in the User Interface (TOP, BOTTOM, LEFT, RIGHT …) Automatically accommodate UI changes without modifying the tests TOP BOTTOM LEFTLEFT RIGHTRIGHT CENTER TOP BOTTOM LEFTLEFT RIGHTRIGHT CENTER

29. 29 Conclusions Nowadays SW applications are designed to run on different devices, from desktop to mobile to wearable The issue: proliferation of test artifacts (tools, scripts, data, UI maps…) to be developed, captured, and maintained  impact on time, effort & costs A viable solution “SHE”: Shrink  Test Design Hide  Complexity Eliminate  Unnecessary

30. 30 alfonso.nocella@maveryx.com