From Desktop to Wearable to Testing

Belgium Testing Days 2015

Alfonso Nocella, Maveryx

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

SummaryFrom 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.

4

From Desktop to Mobile to Wearable

UNIVAC I – 1951

Apple II – 1977

IPhone – 2007

Glass – 2012

5

Different devices, architectures …

5.8’’ – … – 10’.7’

2.8’’ – … – 6’’

6

Different operating systems …

7

Different frameworks …

8

And now… (?!?)

Devices…

Applications…

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

SummaryFrom 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.

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

SummaryFrom 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.

13

“SHE” : handle diversity

“SHE” : Shrink, Hide, Embody (design principle)

[J. Maeda : The Laws of Simplicity]

“SHE” : Shrink, Hide, Eliminate (software testing)

Shrink : test design

Hide : complexity

Eliminate: unnecessary artifacts (UI Maps et al.)

14

An Example

Test Tool : Maveryx

Test Data : Excel

Test IDE : Eclipse (Juno)

JDK / JRE : v1.8

Android : v5.0

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

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

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

Shrink. Method.

1. Identify common features

2. Create the tests

3. Identify differences

4. Manage differences

5. Create new tests

… and much more …

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

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

Shrink. Method.

1. Identify common features

2. Create the tests

3. Identify differences

4. Manage differences

5. Create new tests

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

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

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

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

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

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 MAPor

Image

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

LEFT

RIGHT

CENTER

TOP

BOTTOM

LEFT

RIGHT

CENTER

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

alfonso.nocella@maveryx.com