from desktop to wearable to testing belgium testing days 2015 alfonso nocella, maveryx
TRANSCRIPT
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
