Progressive Web App (PWA) is the new kid on the block. PWAs have:

• the capabilities of a native app, like interacting with the phone’s hardware, 
• the reach of web applications, like easy to access the content through search engines or without downloading a native app
• the ease of developing a normal website with HTML, CSS, and JavaScript

This is why PWAs are often seen as an easier alternative to native applications. But are they, especially when we talk about automating PWAs?

During this presentation, we will discuss why PWAs are seen as an alternative for native apps, dive into their pros and cons, and explore if they are easier to test than native apps.

When developing mobile applications, organizations have different apps to choose from; mobile web, native, or hybrid. While web apps are just websites accessed via the internet on mobile browsers like Chrome or Safari, native applications are developed for specific platforms, such as Android or iOS. Hybrid apps are different because they possess elements from both native apps and web apps..

When automating web applications, Selenium commands are used. Nine out of ten times the same automation script can be used for mobile web applications as our desktop web applications. With native apps however, we need to look deeper into the differences between Android and iOS apps before we can use Appium commands. 

But how should you automate hybrid apps? Can or do you need to choose one of the two automation strategies or is there also a hybrid approach for automating hybrid apps?

That’s what we are going to look at during this workshop. We will be looking into

• how to detect a hybrid application for Android and iOS, 

• how to automate a webview

• how to switch between webviews

• how to use the full potential of automating hybrid apps

During this workshop, we will be using a demo Hybrid app. You can use this app post the workshop to explore more opportunities and practice your new skillset.By the end of this workshop, you will have written your (first) hybrid cross-platform automation script for Android and iOS hybrid mobile applications.

Mobile applications are becoming more and more important in our daily lives. From ordering clothes to grocery shopping, the services available via an app are increasing rapidly and users expect a seamless experience. This means that the automation focus is shifting more towards mobile devices. 

But did you know that there is a huge difference between interacting with a desktop browser and a mobile app? And that difference is just a few tiny hand motions! Because with desktop browser automation we mainly focus on using our mouse, but on devices, we use our fingers to execute all different kinds of gestures, like swipe, scroll, pinch/zoom, and many more. Did you also know that automating mobile gestures is one of the most overlooked features in mobile automation?The most common reason for this could be that we don’t know how to do it, or because it might just be too difficult. 

During this presentation, we will focus on how to mimic mobile gestures with Appium for Android and iOS. With a sample app we will explore and understand different gestures including how to scroll, swipe, and pinch/zoom and then create cross-platform and cross-device gestures. By the end of this presentation, you’ll learn how to improve the user experience of your mobile applications by adding gestures to your automation scripts.

Nowadays a lot of people are using JavaScript based automation frameworks, and why not? They are the closest language to what your developers are using and it's easy to use. You just

• Install NodeJS on your local machine

• npm install this-module

• npm install that-module,

• script a test-case

• npm run test

And you're done, easy peasy, isn’t it? But when you look at your project you see something called

• node_modules

• package.json

• package-lock.json

And you hear your developers talk about

• ES6, ES7
• TypeScript
• Polyfills
• NodeJS LTS, 8, 9, 10, 11, 12, 13 (and counting)
• Promises, asynchronous behavior
• ...

And you are like……………...

If you recognize yourself in this then this presentation might be useful for you, because during this presentation I will cover NodeJS, the biggest dependency of your dependencies dependency.

Participate in this workshop to learn how to put together the concepts of a wdio and typescript in a mocha framework that is scalable, robust, easy to read. We will be sharing our real-time experience of how we migrated our testing approach, design and framework when our application was migrating from javascript to a typescript architecture.

You will leave with your very own example automation framework that demonstrates advanced principles of wdio using typescript automation design. We will integrate with allure reporting.

Reference:

https://github.com/varunatester/sel-workshop

Key takeaways:

1. A robust and scalable framework with the advanced principle for ui testing.
2. A selection of design patterns for the designing framework.
3. Concepts in designing your ui automation such as modeling data within your application and componentizing page objects.
4. A framework which is responsive for web applications.

Setting up a release strategy and configuring a pipeline for your web-application can be done in a few hours, even your biggest pal Google can help you with that. But what if you need to do this for a React Native app? Will Google still be your pal?

Based on our experience we can tell you that Google will not give you all the answers. We needed to do a trial and error research and we finally came up with a solid release strategy and a reliable pipeline that builds and tests our React Native app on every pull-request that is created in our codebase.

During this session we wish to explain the trial and error path that we took Tele2 to build has taken from building an on-premises solution with:

• Mac Mini
• Jenkins
• Stash
• Fastlane

Later, we reached a fully cloud supported solution with:

• GitHub
• CircleCI
• App Center
• Sauce Labs

We all know that Appium can do (almost) everything what you tell it to do, but in the end we always ask it to do the same thing. We ask Appium to automate our happy and or our error flow. The result can give us the confirmation that the user can still buy a product, or verify if his bank account still has a positive balance.

But what if we need to know more than that - what if we also need to verify the layout of our app? The answer would be easy, as there are plenty of open-source or paid solutions that can help you with that. However, almost all of these solutions focus on web/hybrid apps, not on native iOS and or Android apps.

I faced this challenge when I was automating a React Native app for my customer. There was no image comparison tool that could do what I wanted it to do, so I rolled up my sleeves and started building my own. In this talk we’ll be walking down the path I’ve been taking and I’ll explain:

• Why I used ResembleJS as my core visual comparison solution
• The things I’ve learned about Appium in the process (pro tips!)
• The differences between iOS and Android and how I managed to solve this in one cross-platform solution
• The pros and cons of my solution

At the moment React Native is becoming bigger and bigger. To proof the quality of the app we have some awesome automation tools that can support us with that. But still, a tool is only as good as the person using it!

In my previous talk, see links, I've already explained why we needed to select Appium to automate our React Native app. In this session we will look at the decisions we have taken and how I, as the QA engineer of our team, got the opportunity to implement code changes to improve the quality of the app and ease the way we automate our app with Appium. Which resulted in making each other shine!