Appium Desktop tutorial and setup

Introduction

Appium Desktop is a good way to understand the Appium mechanism. You will see how the elements are identified and what type of interaction you could accomplish. After that we could start industrialization with a test factory.

Today we are focusing on an iOS application. So we will use a iOS test application and it will require a Mac environment.

There is 2 main purposes to use Appium Desktop :

  1. Investigate how the application could be automated and identify the objects.
  2. Use as Appium server instead of using Node.js

Setup

We will setup Appium Desktop on a Mac (10.12)

  1. Install “Xcode” from “App store”. It is free.
  2. Run a first time Xcode and accept the License Agreement.
  3. Start the simulator : “Xcode” > “Open Developer Tool” > “Simulator”
  4. Check the version of your Simulator like below:

    iOS 10.3 simulator
    iOS 10.3 simulator
  5. Then go download and install the latest version of Appium Desktop (https://github.com/appium/appium-desktop/releases) like below:

    Download the latest version. Here it was 1.0.1 the latest version.
    Download the latest version. Here it was 1.0.1 the latest version.

Tutorial

  1. Start Appium and let the value by default like below:

    Appium starting screen
    Appium starting screen
  2. Start a new session :

    Appium logging screen
    Appium logging screen
  3. Create a new “Desired capability”. Ensure to report the right version of your iOS simulator!
    {
         "platformName": "iOS",
         "platformVersion": "10.3",
         "deviceName": "iPhone Simulator",
         "app": "http://appium.s3.amazonaws.com/TestApp7.1.app.zip",
         "noReset": true
    }
    
    Add in "Desired Capabilities" the required properties to run the simulator and define the application to test.
    Add in “Desired Capabilities” the required properties to run the simulator and define the application to test.

    Here we use a test application that allows you to practice and understand how to use Appium. (http://appium.s3.amazonaws.com/TestApp7.1.app.zip)

  4. The Appium will show the screen of the iOS simulator (1), the inspector pan (2), the detail properties for a selected element (3). The (4) is the real simulator running on your machine, Appium is using a simulator to interact with your application. Appium is not providing its own simulator and this is a good approach, we could compare the simulator as the browser for Selenium.
    Appium Desktop (1) (2) (3) and iOS Simulator (4)
    Appium Desktop (1) (2) (3) and iOS Simulator (4)

    When you select an element in the (1) by double clicking, you will see in (2) the element name that has been selected and in (3) all the properties of the selected element. In this example you could “Send Keys”  or “Tap” in the selected field.

    How an element is defined and how you could interact with.
    How an element is defined and how you could interact with.

Conclusion

Now you can play with Appium and see how you could automate test with your App. It is a good way to see the challenge you could face when you try to automate your iOS, Android or WindowsPhone app.

Related Article

IoT testing – Devices connected to a mobile

Stress Test vs Load Test

People are often mixing Stress Test and Load Test in software development. So, let’s demystify a bit.

Stress test tries to break the application until its limits and have a clear KPI regarding the SLA. In this stress test, you have 2 aspects: Positive test using all the system working optimally and negative test having some system already broken and what is the limit of the system in degraded mode.

Load test is a scale up and a controlled volume loading test. The main aspect here is to define the bottle necks of the system at different level of volume.

Here a few tools that could do both type of tests:

  • Locust (open source system and Python)
  • JMeter (open source system and Java)
  • LoadRunner (commercial tool)
  • NeoLoad (commercial tool)

Samy Kacem

Test Automation Strategy

Before starting to automatize tests, you need to take a step back and define few aspects.

Consider the test team members

Depending on the test team members you need to think what kind of test scripts you are going to adopt. Depending on the tools like Tosca, UFT, Ranorex or Selenium, there are 3 ways of scripting:

  1. Record : This is a an easy way, but could be expensive to maintain. The profiles adopting this way of working are the Business Users.
  2. Script : This a fair quick way to script, and the maintenance is less expensive then using Record. It requires a Test Automation Expert to develop and to maintain them. Any tool is able to achieve the automation.
  3. Data Driven and Workflow : It requires both profile : business user and a test automation expert. This could take more time to implement but the maintenance is way easier and also scripts could be easily reused by the business user without requiring an expert.
    1. With HP, it will require BPT.
    2. Tosca is able to handle it if you use “modules”.
    3. Selenium and Cucumber or any other BDD are able to handle it. See a test factory as exemple.
    4. Ranorex is supporting the data driven part. But no workflow management.

Consider Manual vs Automated testing

You should not automate everything and keep some test cases for manual testing. To define which one should be automated, keep in mind the following:

  1. How much time the same script need to be repeated? If you are doing more than 4 times, you should automate.

    Y = minutes spent and X= time test execution. We base the figure on a small test scenario.
    Y = minutes spent and X= time test execution. We base the figure on a small test scenario.
  2. If your test are UAT (User acceptance test), exploratory test or complex with many asynchronous processes, you should consider manual test.
  3. Also when you prioritize the test cases based on their business criticality. More a test case is critical, more it should be automatized.

Consider Test Data Strategy

Ask yourself these following questions:

  1. Do you need real data with a state data based on a process? That means your data will change from the beginning until the end of the test. You may need a copy from a production database with data anonymization and a way to reset it. This could be a complicated task. You could also use advanced tool for Service Virtualization to avoid to copy database and have a instant “refresh”. But this path is also quiet expensive in license or in man days.
  2. Does your data drive the test? In other words, do you need more a copy of the database, but also “properties” data to drive all the test scenarios?
  3. Define the right set of data that covers all the business risks. When you generate all the test scenarios for the same workflow, you should ensure to optimize the number of scenarios without being systematic, otherwise it could fall in an exponential number of scenarios. See an example below:

    Define data set scenarios - Gender and t-shirt size are the variable to generate the data set. (*) mean critical data from business point of view.
    Define data set scenarios – Gender and t-shirt size are the variable to generate the data set. (*) means critical data from business point of view.

Consider Test Script Maintenance

When you create automated test you will require later to maintain them for 3 main reasons :

  1. “Repair” test cases based on business changes.
  2. Enhance test cases based on issue found in UAT (User acceptance test) or later in Production.
  3. Optimize or correct test based on false positive errors.

Consider the right scripting tool

Based on all your SUT (System under test) technology. You need to find the right scripting tool depending on the features and your budget.

Comparison of test automation tools between Selenium, Ranorex, UFT, Tosca
Comparison of test automation tools between Selenium, Ranorex, UFT, Tosca