Appium is an open-source tool for automating native, mobile web, and hybrid applications on iOS mobile, Android mobile, and Windows desktop platforms. It is "cross-platform" and allows you to write tests against multiple platforms (iOS, Android, Windows), using the same API. This enables code reuse between iOS, Android, and Windows test suites.

This workshop will help you get started with Appium by covering key concepts like:

• Client/Server Architecture
• Session
• Desired Capabilities
• Appium Server
• Appium Clients
• Appium Desktop

Think of this as a one-day crash course in Appium. The course will be prepared in NodeJS but there will be help for those who want to get started in Java.

- Are you struggling to convince your dev team to adapt right Test Pyramid? And are able to evaluate the reasoning behind not doing it?

- Are you new to unit testing? TDD looks like a buzz word?

- Does it look like only for developers? If yes then we must meet, I have very interesting queries for you. One of them: Have you considered the value addition it has when a tester knows Unit Testing as well?

- Do you feel like you know the syntax, but would like to understand new idioms and where to use them?

- Want to learn and make the career doing full-time test automation called SDET?

Instead of just covering the syntax, we will introduce most of the UnitTests using nose/TestNg as we build code together.

• You are new to GIT or using GIT but it scares... you often find it time-consuming or confusing when code conflicts happen while using Git especially when you commit a binary file Example: your TestData Excel sheet, test mobile app | apk.
• Want to avoid the pains of investing huge time resolving the conflicts or thinking over like "oh! I committed to a wrong branch, how can I bring these commits in another?"
• Don't like to enjoy remembering the GIT commands?

This workshop aims to get you quickly started (hands-on) with Git concepts from the scratch and then jump into the tips and tricks to prevent/resolve conflicts quicker way and how to make best out of it. We will start from basics and keep moving to the advanced level with real hands-on examples.

And all that we learn, we are going to remember easily. How? come, join and experience the easy GIT.

Dont’s

Will also work on few frequent typical mistakes which usually we do & tips on how to avoid them and save a lot of time.

Problem Statement

Do you have a lot of automated Tests and so the lot many tests reports to analyse before taking call for release?

Plot: Any huge impacting micro-service based product/project for which enormous tests have been already automated and your continuous deployment process requires all of those tests in "PASSED" state. Due to high traffic most of the day, releases are deployed at non peak hours. Imagine decided deployment time in production is 5 AM. (The feature and regression testing is done already but there are always some small last minute changes, so it’s better to have a double check on the frozen code to release)

At 1 am: Final automated sanity checks start executing  

At 3 am: Get the results, release engineer/ devOps gets notified of the state of the release, she/he looks at CI board and see several green and red builds. He/She now 1 by 1 opens all red builds, clicks on individual reports, console, screenshots....  more red builds- more time to analyse it...

At 4.30 am: After gathering report on which test failed for what reason & who should be looking at them, she/he calls up respective owners to look out and state the reasons & take a call on the release

At 5 am: The service owner says "let’s revert my feature to previous version and take the release live"

Release Engineer again starts searching for files/mails where the last stable version is stored, spending more time again. It’s 6 AM now, she/ he deploys last stable service versions, runs the failed tests -> integration tests ...

it already 9 AM, wooosh!, time runs really fast. Can't release now, peak traffic time.............

Do you share the same pain?

Before giving a +1 for the release, it becomes essential for the QA folks to provide proper feedback as quickly as possible. At the same time assessing n number of reports becomes an additional tedious task. So definitely there should be 1 dashboard which nicely displays the status with transparency and anyone should be able to tell whether release is good to go and if not, then why not. RSA which I have created on top of open-sourced technologies is a small effort towards achieving the same. Will take you through a live demo and discuss on how you can use it to meet your needs.

A typical conversation on a release day:

 Everyone on team running around with questions like how was it merged without review? why wasn't it caught earlier in the automated tests? is it not test covered? And the blame game starts which turns pleasant office premises into a really chaotic one as all starts behaving like Shakuni the bad critic ..............

Does this conversation sounds familiar to you?

yes, in fast paced organisations like us it is a burning problem. And we really wanted a monitoring system in the test phase itself that too using the same tools we use regularly and hence not costing us anything extra. This brings Agility within the teams by having everything & everyone on a single platform and help everyone feel what’s there in the black box.

Points needed to ensure:

1. Prevent direct push to the branches we want to protect
2. No commits to go inside without tech/product review
3. A common transparent place to quickly go through all commit links/description with timestamp to quickly know which can be the culprit commits
4. Alerts to respective team members for any suspicious activity done by anyone
5. Personalised alerts to the committer for reminding to follow the release process
6. As the team size grows, assisting each one in the team on release process & progress is really a repetitive task and an unnecessary dependency

In this talk, we will discuss about unleashing the power of Github & Slack to create a interesting code monitoring and talking bot which keeps everyone in a team updated on a single platform.

This workshop will feature getting started with automating Android & iOS native apps and Mobile web using Appium with java.

We will learn :

    - how to capture elements for all these 3 categories (Mobile Web, android, iOS)

    - how to create tests

    - how to give them a form of framework to have reporting/screenshots etc. benefits

    - how to setup to run all of them in parallel to save time of testing

Problem Statement

Expected Result: Mobile is taking over the world and wow! my product works awesomely everywhere.

Actual Result:  OMG! it breaks on iOS 6 :-( 

Holy Jesus! did we also test on firefox version 30.0 on Windows machine ?? 

Having an application on all major platforms(Desktop Web, Mobile Web, Mobile Native apps etc.) brings a daunting requirement of verifying every single feature before giving a +1 for release and so it becomes essential for the QA folk to test and provide proper feedback as quickly as possible, which immediately takes the complete reliance only on manual testing out of the question and pushes for the need for automated testing with scalable automation framework embracing any product need in the future.

We surely have 5 points to be answered before we think about such solution :

1. Do we have a single test code which can test the product everywhere with a simple mechanism to trigger and manage them?
2. Where is the plan to reduce Time To market having so many tests running before each code push?
3. Do we have 1 click solution to monitor all the test results in one go to assert the state of ThumbsUp for release?
4. Is continuos integration in place?
5. How can I integrate all of the above 4 points using the same beautiful tool Selenium along with other aligned open-source projects like Appium, Shell and Jenkins?