Automate Android , iOS, Windows UWP with Appium | Creating Desired Capabilities

Automating mobile apps

If you're interested in automating your web app in Mobile Safari on iOS or Chrome on Android, Appium can help you. Basically, you write a normal WebDriver test and use Appium as the Selenium server with a special set of desired capabilities.

Desired Capabilities are keys and values encoded in a JSON object, sent by Appium clients to the server when a new automation session is requested. They tell the Appium drivers all kinds of important things about how you want your test to work. Each Appium client builds capabilities in a way specific to the client's language, but at the end of the day, they are sent over to Appium as JSON objects.

Desired Capabilities can be scripted in the WebDriver test or set within the Appium Server GUI (via an Inspector Session)

Let’s consider an example of Desired Capabilities in Appium represented as a JSON object.

{
“platformName”: “Android”,
“platformVersion”: “11.0”,
“deviceName”: “Samsung A50”,
“automationName”: “Appium”,
“app”: “path for the app under test”
}

Using the above-mentioned Desired Capabilities, the user is instructing the drivers to start the test automation session for the app at the mentioned path on a Samsung A50 with Android version 11.0 using Appium.

In this video, we are going to create desired capabilities for Android, iOS, and Windows App. We are also going to see how to find the UDID of the iOS device and simulator. And how to find the bundle ID.

GraphQL Automation | Part 1 | What is GraphQL | Difference Between GraphQL and Rest API | Part 1

In Part 1 of the video we are going to discuss:

- What is GraphQL 

- Difference between GraphQL and Rest API 

- Advantage of GraphQL 

- How queries are fetched in GraphQL 

- Software Testing API Testing

 

A query language for your API

GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data. GraphQL provides a complete and understandable description of the data in your API, gives clients the power to ask for exactly what they need and nothing more, makes it easier to evolve APIs over time, and enables powerful developer tools.

What is GraphQL understanding this with a scenario. Difference Between GraphQL and Rest API

Migration Testing Scenario for Android and iOS

Migration Testing Scenario for Android and iOS

Migration testing is one of the important testings particularly for mobile applications where a single mistake can take 3 days to 7 days to fix, deploy, and roll the app again on production. If you have a large user base and real-time application like Flight booking or Hotel Booking we need to be cautious while doing the migration testing.

Why we do Migration testing?

Migration is being done on the new OS, tech stack, or DataBase.
Particularly I will be discussing the migration of mobile apps which may include all or none of the above situations.

Use Case of migration:

1. To give users better performance, you don't want your million flight booking or hotel booking consumer to navigate to your competitor's site.
2. Moving to the new tech stack from the obsolete one. Why would you like to drag the legacy technology when new technology can bring you peace of mind and ROI.
3. Cost reduction of the maintenance of the application.Which may include the second point.

When the migration testing is done :

1. Do you remember the blackberry devices, they use to have their own OS. Slowly they were not able to compete with the Android OS so before they finally moved to the Android OS they were allowing the android developers to port their Android Apk on blackberry os with the help of the wrapper library they wrote. Since the .apk file was wrapped for Blackberry and it was migrated on BB OS we need to do migration testing for the new OS.
2. Currently, the Native apps are being replaced by React Native apps. This involves changes of tech stack apart from maintaining the DB of the user in the react native app which can affect different areas depending on the functionality of the app, the common one being login functionality.
3. Migration testing of the new app over old app having new features and bug fixes, example the previous functionality allowed your user to login with Email. Now they have SSO like Google login and Facebook login. We need to verify that after these new features are implemented they are working fine on the new app once they are installed over the old app.

Test Cases:

1. Install the new application and verify the migration.
2. Install the old app over the new app and verify the migration.
3. Install the new app and then the old app over it (Reverse migration for risk management).
4. Login in the old app and install the new app.If authentication token are grasped automatically all user data should be preserved else if the user is log in again on the new app they after login user should see all the data.
5. UI testing of the migrated app. Remember how Blackberry once allowed to port the Android app on their BB OS when they were not using android apps.I found many issues in my Indigo app at that time.
6. Install the new app over the old app and play with it in flight mode i.e. internet is not connected with the app.
7. Sometimes apple stores information like login in the key chain in the mobile. Now when the user login into the new app with his credential the key chain also passes some information which can lead to a crash. A perfect example is two authentications generated for the app in the same device for the same app.
8. Verify the migration of old app over the new app for different OS versions and devices available