automate you appium test like a pro!

Automate your Appium tests like a pro

Wednesday, April 27th

AboutQualiTest

QA and testing isall that we do!

World’s 2ndlargest pure play

TestingCompany

Over 2,700 testingprofessionalsworld wide

Business Assurance

QA &TestingFocus

ResultsBasedTesting(RBT)

Contractual guarantees forquality improvement &

cost reduction

ManagedTesting

Solutions(MTS)

Long term, SLA-based testingoutsourcing

Industry & Technology Expert

2

GlobalServiceDeliveryModel

Onshore, Near-Shore,Offshore and Crowd

Testing

What is Appium?

| Android and iOS Devices Automation Toolkit

| Provides real device control on Native, Mobile Web and Hybrid apps

| Based on the hugely successful Selenium WebDriver technologies

3

What are the benefits to Appium?

|Object-based recognition, more resilient to minor GUI changes than image-based

|No side-loaded software or libraries on the device

|Widely supported, time-tested foundations| Part of the WebDriver family of technologies

| Many of the concepts and approaches are already known to experienced WebDriver engineers

|Open-source project, minimal cost

4

What are the disadvantages to Appium?

| Limited avenues for commercial or SLA support

| Code-heavy solutions

| Limited to Android and iOS testing

5

How does Appium work?

| A lightweight, NodeJS server sits alongside mobile-vendor provided SDK

| For Android we leverage Google’s own Android Developer Tools

| For iOS we leverage Apple’s iOS SDK

| The server is listening for traffic coming in using WebDriver’s JSON wire protocol

| When traffic comes in, it passes through to a connected device using the SDK

6

How Does Appium Work?

Appium Host Test Automation Suite

iOS/Android Device NodeJS ServerAndroid/iOS SDK RemoteWebDriverImplementation

Automation Scripts (Java, C#, Ruby, etc.)

JSON Wire Protocol

Can be same machine or separate

7

How do we write Appium tests?

| Because Appium listens via neutral protocols, test developers can choose from a variety of languages to use.| Appium project provides language

bindings for Java, C#, Ruby, PHP, Python and JavaScript

| Developers can write their own bindings

8

Knowing what to look for

| Traditional WebDriver tests use HTML structure details to interact with the page

| iOS and Android GUI elements can be located using identifiers, Xpath expressions and text just like web page elements

| We find these using mobile tools in Appium and SDKs rather than a browser

9

10

So what does this mean?

|A standard app development environment is easily adapted to an Appium test environment

|We can take a lot of WebDriver’s principles and apply them to mobile testing

|Appium tests look and feel very like WebDriver web tests; but we point to a device not a browser.

|We can re-use lessons learnt, frameworks and best practices from WebDriver testing in Appium.

11

Appium Test Best Practices

|De-couple test fixtures from test logic

|LoginPageObject.java

| Use page object patterns to keep tests resilient to application changes

12

Appium Test Best Practices

|Test Scripts should be high-level |LoginTests.java

| Test Scripts document a Journey through a system

| Scripts call lower level functionality at business and page layers to drive interaction

| Use Data-Driven techniques to create scalable tests

13

Appium Test Best Practices

| Invest in automation infrastructure| The faster and more regularly we run

automated tests, the faster they find problems, the faster we drive up quality

| Dedicated environments and software build phases are instrumental to this

14

Appium Test Best Practices

|Automate from the bottom up| Appium tests are integration tests, covering

more functionality than unit tests, but are harder to set up and slower to run. If unit test coverage is high, we need less of them

| If unit test coverage is low, integration test failures become less-efficient at pinpointing defect areas

15

Appium Test Best Practices

| Empower test developers| They should be provisioned with all they need

to run tests locally, instead of leaning on shared build- servers and environments to identify failure

| The software build should be chained not to run integration tests if unit tests failed

| There’s no point in running slow tests when fast tests already told us there’s a defect

| Test your tests!

16

About the Demo: giffgaff

| giffgaff are a mobile telephone network based in the UK

| Founded in 2009 with a vision to disrupt the market

| Built around their core values of being lean, disruptive and driven by their members

| giffgaff is ’run by you’ with hundreds of implemented ideas generated by the ’community’

17

About the Demo: giffgaff

| Some of the functionalities of the app include allowing users to:

| View their balance| Topup their phones

| Talk on the community

| Change their account settings

18

About the Demo: The Tests

| The test cases implemented for this demonstration cover the following scenarios:

| Able to successfully log in and out as a giffgaff member

| Unable to log in with an invalid password

19

About TestObject

Mobile Automated

Testing

Open sourceTesting

Frameworks

MobileManual Testing

2 Offices in Germany

App TestingSpecialists

Our Clients

200+Satisfied

Customers

20

Typical Appium Test Script

21

Typical Appium Test Script

| Not using abstraction to our advantage: low level and high level mixed together;

| Low readability;

| Low maintainability: bad news if you have a new release every two weeks.

22

The PageObject Pattern

| The goal:| Enhancing test maintainability by increasing

readability and reducing code duplication.

| How to achieve it:| Every* page in a website / every* screen in an

app is represented by a class;| Every PageObject encapsulates the

interactions the user can have on said page/screen, hiding the underlying widgetry.

23

The PageObject Pattern

24

The PageObject Pattern

| If we have this in place…| tests become more readable (as you will see in

a moment – they will read as a sequence of user interactions on a screen) and high-level;

| if the UI changes for the page, all changes to support that new UI are located in one place (the PageObject class for that page).

25

Questions and Answers

26

THANK YOU!

Daniel Geaterdaniel.geater@qualitest.co.uk

Giovanni Ragogiovanni.rago@testobject.com