Are you tired of creating beautiful graphs that only serve as decoration? Do you want to take your data visualizations to the next level and turn them into a powerful decision-making tool? Don't settle for flashy concepts that have no practical use; learn how to combine beauty with brains and make your data actionable with effective data storytelling.

Join us to identify ways of turning your data into a cohesive strategy for the short and long term. Explore the five "Stages of the Spectrum" and learn how to exploit both internal and external ideas to drive decisions with data. You'll see firsthand the difference between impact and influence, and how to make sure your data has a real effect on your business.

American mathematician John Tukey once said, "The greatest value of a picture is when it forces us to notice what we never expected to see." Let us show you how to capitalize on those unexpected insights and turn them into a competitive advantage. You'll discover how to catch the right blend of art and science, as you go from concept to reality, making sure your ideas become a reality, not just fluff.

In this session, you'll gain the skills and knowledge to create visualizations that drive decision-making and business outcomes. Don't settle for pretty pictures without impact; join us to uncover how to blend creativity with analytical thinking, thus leveraging art and science to make your data work for you.

In today's IT industry there is need to test an important feature that needs to be understood by the business stakeholders and other non -technical team members who are part of application building

So from the mobile automation point of view Appium with Cucumber BDD (Behavior Driven Development) provides a way to write tests in plain language (Gherkin syntax) that can be easily understood by non-technical stakeholders. This helps ensure that everyone is on the same page about what needs to be tested, making it easier to write automated tests that accurately reflect the expected behavior of the application. Additionally, Cucumber provides a framework for organizing and running tests, making it easier to manage and maintain test suites over time.

Before the adoption of Behavior-Driven Development (BDD), many teams faced several challenges in their mobile application development and testing process, including:

Miscommunication between stakeholders: Requirements and expectations were often unclear, leading to misunderstandings and mismatched expectations between stakeholders such as developers, testers, and business stakeholders.

Lack of shared understanding: Without a common language for describing software behavior, it was difficult for all parties to have a shared understanding of what was being built.

Unclear acceptance criteria: Acceptance criteria for features were often implicit and not explicitly defined, leading to confusion and rework.

Unmaintainable test code: Traditional testing methods often resulted in large, complex, and unmaintainable test code, which made it difficult to understand and modify tests as the codebase evolved.

Ineffective testing: Traditional testing methods often focused on verifying implementation details rather than behavior, leading to tests that were brittle and prone to breaking with even minor code changes.

Appium with BDD addresses these challenges by providing a common language and framework for describing software behavior, improving collaboration between stakeholders, and promoting clear communication and understanding of acceptance criteria. BDD also encourages writing tests in a way that is scalable, maintainable, and reusable, which helps to ensure that tests continue to provide value over time.

You finished developing your brand new mobile application what next ? For any digital product to provide a universal experience, it must be fully functional anywhere and anytime. So, long before your app is ready to go live, you must make sure it works seamlessly across all devices, networks, operating systems, browsers, or any combination of these your users prefer.

You may think this sounds like an obvious step, but keep in mind that there are currently about 3.8 billion smartphones in the world. Your app must be compatible with most–or all–of them under various circumstances such as a low battery, different versions and updates, poor network connection, and screen resolutions, to name a few. The only fail-safe way to ensure that your app works under all of these variables is to test it continuously and thoroughly.

To try and tackle this issue, we want to look at continuous testing using device farms with CICD as helpful and efficient tools for implementing solid testing processes without breaking the bank.

Continuous testing using device farm and CI/CD tools for Appium can be achieved by following the following best practices:

Device coverage: It is easy to use and helps increase your platform testing coverage by offering a wide breadth of devices.

Test anywhere and anytime: It gives access to testing environments from any part of the world and any timezone, making it ideal for offshore development teams.

Device Compatibility: Test your application on multiple devices and OS versions to ensure compatibility and validate the compatibility with the device farm.

Parallel Testing: Run tests in parallel on multiple devices to reduce testing time and improve overall testing efficiency.

Test Data Management: Manage test data efficiently and ensure it's stored separately from the automation code.

Test Environment Configuration: Set up a testing environment that includes all necessary dependencies and configurations to run tests seamlessly on the device farm.

Continuous Integration and Deployment: Integrate your testing process with your CI/CD pipeline to automate the testing process and ensure tests are run on every build.

Version Control System: Use a version control system to manage the test automation code and track changes over time.

Automated Builds and Deployments: Automate the build and deployment process using CI/CD tools to reduce manual intervention and improve efficiency.

Test Results and Report Management: Store test results and reports in a centralized location and ensure they are accessible to all stakeholders.

Continuous Improvement: Continuously monitor and analyze test results, and improve test scripts and processes as needed to increase test coverage and reliability.

By using Appium with Device Farm and CICD tools, you can continuously test your application across a variety of real devices and operating systems, catching compatibility issues early and improving the overall quality of your application. This helps you deliver a seamless and universal user experience to your customers

In the old days, all of us, including myself, were primarily concerned with reducing the execution time of our automation script, right? This debate, however, is not about it. I recently developed a solution to reduce the development effort of automation test scripts to be generated while working on one of the problem statements. Isn't it odd?

The fundamental principle I employed to develop this was Java's reflective nature, as well as features like generics, java records, and so on. You're probably wondering how these new features can enable you to develop an automation solution that reduces both development and execution time?

In this session, we'll go through what these modern Java concepts are and how an inherent feature of a programming language allows us to develop a design pattern that can be utilized to reduce the development effort of an automation solution for Appium scripts. Throughout the talk, we will delve deeply into the problem statement, applicable traditional solutions with their benefits and drawbacks, designed solution with their benefits, and finally the concepts, tools, and libraries used, including data randomization.

Already excited? Let us all take part in this interactive session to learn about the brilliance of Java reflection.

Dear Testers,

Desktop app automation skill is often overshadowed by the buzz surrounding mobile and web-based testing, but it remains an essential skill for automation testers in 2023 and beyond. Despite the proliferation of mobile and web-based applications in recent years, desktop apps remain a critical aspect of the software landscape and cannot be ignored by testers and developers.

There are several industries that continue to heavily rely on desktop apps, including finance, healthcare, Space, Aeronautics,Digital Ocean and government. These industries often have strict regulatory requirements and data security concerns, making web-based solutions inadequate. In addition, many desktop apps are used for resource-intensive tasks, such as data analysis and visualization, which may require the processing power and offline capabilities of a desktop environment.

Some Popular Desktop Apps that we use everyday :

1. Adobe Softwares

2. Microsoft Windows Default Desktop Apps.

3. Microsoft Teams/Slack/Etc.

4. PC Games

5. And Many more...

Furthermore, many desktop apps generate significant revenue for their developers. According to a study by the Software and Information Industry Association, the global market for desktop apps was worth $76 billion in 2020 and is expected to continue growing in the coming years. As such, ensuring the quality and reliability of these apps through automation testing is crucial for the success of these businesses.

In summary, desktop app automation is still highly relevant and cannot be ignored in 2023 due to the continued reliance on desktop apps by certain industries and the significant revenue they generate. We believe that a session on this topic would be of great value to attendees of the testing conference.

Problem Statement :

                 We have an customer support (CS) application that is supported only on desktop browser whereas the client facing app can use desktop as well as mobile browsers. So It’s challenging to automate a use case where customer support (CS) completes a process on desktop but client accesses the link using a mobile device to complete the process since it includes two different browser entities – desktop & mobile.

Our Solution -

We achieved this user flow automation using Selenium’s Chrome DevTools Protocol where we overrode the desktop mode and simulated a mobile mode in a single user flow. Additionally, we integrated this flow in our Behaviour driven development (BDD) framework & also achieved parallel execution of our automated tests for quicker test completion.

Flutter is a new cutting-edge open source technology which is highly beneficial for organisations looking to reduce the time for product development and release products faster to the market. Its biggest advantage is that it provides the same code base for both Android and iOS. 

Testing Apps developed on Flutter requires specialised skills, especially automation. There are 3 different types of testing done on Flutter Apps:

• Golden Tests
• Widget Tests
• Integration Tests

All these tests require working closer with the Flutter technology and Dart Programming language. In this interactive talk I would like to go through some of the concepts around these Flutter Tests. 

The Golden Tests entail testing snapshots which match a baseline image with the current image from the latest build. This provides quick feedback about what has been changed in the latest upcoming releases and also provides a note of any image distortions/changes. Every field (Buttons, Icons, Text fields etc) in Flutter is termed as a Widget, so any test that examines these fields is termed as Widget Tests. These tests primarily verify anything and everything that is done by these Widgets; for example, placing/action on the Widget. 

The Integration Tests, as the name suggests, enable testing the integration of Widgets and their functionalities. All these types of tests are scripted within the same repository as the project and use the same programming language of Dart and Flutter Technology. This enables us to work more closely with the Developers and create better quality products. Testing of apps developed on Flutter needs different skill sets, with respect to our approach towards it. Typically, in the Flutter terminology, the Flutter Integration Tests are generally considered as the UI End-End Tests. These tests can be written in dart programming language and combined with the Developer’s code and pipeline. This helps us to run the tests, every time the development pipeline runs, providing the feedback early and in time. Also, as we very well know, quick feedback is directly related to the cost associated with the product, hence this method reduces the overall costs of the project/product. 

The Widget Tests on the other hand provide us with a very unique way of testing all the widgets available in an app. Quite often, while running our UI Tests, we sometimes unknowingly skip some of the Widgets on the screen This could be because that particular widget is not needed for our tests. Invariably, a lot of times, this particular widget could lead to a bug later in the cycle. These types of Widget Tests could help us in testing every single Widget on the screen beforehand and enable us in identifying potential bugs much early in the product’s development and release cycle.

Primarily there are 2 different Ways to Test an App developed in Flutter:

1. Appium's Flutter Driver: This is very much similar to using the Appium driver and interacting with the elements like we do for any other Apps. Thanks to the great team of Appium contributors for supporting the element identifications and other necessary changes on the Appium framework. It works seamlessly just like any other app, apart from having to handle the element identification issues, which sometimes had to give the longer XPATH's. But once again, thanks to the team, there are some really good updates made helping the Automation of Flutter Apps
2. Flutter's Native Integration Test package: Flutter community has started providing an additional 'integration_test' package. This package would be used to perform the Integration Tests depicted in the above section. This enables us to be more closer to the Developer's code, use the same DART language and tailor the code(automation and/or development) as per our needs.
3. Maestro/Patrol: This is a package by the Flutter community, but it has few limitations. we shall go over them completely.

We will go through more details in the session about the differences between these techniques and present our observations.

In today's fast-paced business world, companies are constantly vying for a larger share of the market. One key aspect that can set you apart from the competition is having a quality engineering team that works seamlessly with development and business teams to ensure that your products are user-friendly and easy to navigate. But what if you could take it one step further? Imagine having the ability to gain in-depth insights into how your customers are truly using your products. By understanding which features are most commonly accessed and which devices are being used, you can make sure that you're focusing on the areas that truly matter to your end-users. Additionally, by analyzing feedback from social media and app stores, you can pinpoint pain points and address them accordingly. This is where production feedback analysis comes into play. It gives you the valuable insights you need to refine your testing strategy and ultimately create products that truly meet the needs of your customers.

Thanks to Appium and its related technologies, it becomes more and more popular
to practice E2E test automation on mobile apps. On the other hand, it is well 
known that it's often difficult to investigate and debug a failure of Appium 
tests. It is because Appium tests place at the top of test automation pyramid. 
In other words, there are many resources required to run E2E tests which makes 
investigation difficult.
Although there are some techniques like capturing screenshots and recording a 
video to investigate Appium tests, one thing Appium experts most often depend 
on Appium server log, the one overwhelming, massive amount of strings.
In this session, I'll demonstrate how Appium server log helps you understand 
the cause of your test failure. Plus, through exploring Appium server log in 
this session helps you grasp
1. The structure of Appium project
2. Technology stack on which Appium depends
3. How Appium automates mobile devices

With the advent of digital economy, mobile applications play a crucial role in bringing the business and end users together. Be it banking, insurance, healthcare or manufacturing domain millions of mobile apps were developed so far and the industry is expected to grow further.  While test automation is the backbone of Agile, most of the mobile test automation strategy revolves around functional test automation. As per Gartner market review Mobile testing services are different from traditional application with additional complexity, such as testing of multiplatform, networks, multiple operating systems and different devices. With all these complexities its imperative to uncover application crashes early in the Mobile app development life cycle. Frequent app crashes on end user devices will lead to negative reviews & ratings, uninstalls, interrupted or lost transaction, as well as losing brand image. In this session, we will share our learnings on Monkey testing use cases, key drivers, commercial or open source tools options, key benefits and the custom solution that we developed. Lets execute our first monkey tests on Mobile Native apps. No or limited script development required when applying this custom solution on any iOS and Android native apps.

Since Appium conference 2021, Appium 2.0 has become more standard version to automate mobile apps compared to Appium 1.X. Other than long term contribution to Appium project brought by Appium team, there are some factors which accelerate the shift to 2.X like
- Appium 1.X has been deprecated since the 1st of January 2022
- Appium 1.X does not support Xcode 14.0 (i.e. difficult to test with iOS 16.0)
- Newer appium-flutter-driver only supports Appium 2.X
However, what about migrating large scale, prolonged, legacy tests? We, as a provider of test automation service, run 30000 of tests per day. We've run more than 11 millions tests so far. We've developed Appium tests over 5 years.
In this session, we'll deliver how we've migrated to Appium 2.X from the legacy technology stack like wd (a deprecated javascript client for Selenium/Appium), json wire protocol and touch actions. We'll also describe key practices and techniques to try to best to preserve the backward compatibility for the running tests.

In today's fast-paced technology landscape, frequent release cycles and shorter release testing time are becoming increasingly important for organizations looking to stay competitive. With the rise of agile and DevOps methodologies, there is a growing demand for fast product launching and the ability to quickly adapt to changing market needs.

To meet these demands, organizations are turning to end-to-end automation, which enables them to seamlessly integrate testing and deployment workflows and reduce the time and effort required for manual testing.

In this presentation we will see by leveraging Appium,  MS Azure, and BrowserStack, how organizations can build and execute automated tests for their mobile applications, ensuring consistent performance and functionality across different devices and platforms.

The topics covered in this presentation are significant as they provide attendees with the knowledge and tools necessary to achieve these goals. With an automation framework that supports both Android and iOS platforms(same test code), attendees can easily build and execute automated tests for their mobile applications, saving time and effort on manual testing. By integrating BrowserStack, they can execute tests on a variety of real devices, ensuring that their application works seamlessly on all supported platforms and can measure the performance as well using multiple devices.

One of the important topic covered in this presentation is the automation of Facial Recognition testing with Appium. With the growing popularity of facial recognition technology in mobile applications, it is essential for organizations to ensure that their applications are working as expected, and more importantly some of the applications won’t let their user access the application without facial recognition, so there it becomes mandatory to automate it to bypass the authentication, and dealing with actual camera application with appium is not a good idea, therefore in this topic we will discuss how can we overcome this.

The use of DevOps pipelines enables organizations to achieve end-to-end automation, seamlessly integrating testing and deployment workflows. Here we will see how MS Azure can be integrated with webdriver.io and the integration of BrowserStack extension provides visibility into test results which allows for quick identification and resolution of any issues, alongside there will be also detailed mocha-awesome HTML report with failure screenshots leveraged.

Overall, these topics are essential for organizations looking to streamline their testing and deployment workflows, achieve faster release cycles, and launch products more quickly and efficiently!

Thank you.

Debugging is always challenging on mobile devices sometimes; it is not successful; We spend hours and hours to have our test script working; to mitigate this problem, one of the Solutions I come up with is how we can quickly run tests through API's. From this Idea, we started Building solutions for Debugging through Rest -Assured-Apis using Postman.

Automate everything! That’s the most suitable description of DevOps culture. The culture quickly created job positions with the same name. Position, mostly focused on broadly defined automation, leading to fast product delivery. And the division was pretty simple: DevOps = Process automation, QA = Test automation. But is it the right approach? What about the (still more and more) popular “(Dev)TestOps” term?

Classical testers are now also very often responsible for the set-up and maintenance of the major part of the Continuous Integration or Continuous Delivery environment (especially the test automation part). The main problem from the business perspective is, like always, time! E.g. many start-ups and companies in a phase of early, dynamic growth cannot afford to waste too much time on test automation. How do you speed up the delivery process in that case? How do you quickly generate a valuable increment?

I’ll show you how to improve and speed up the testing and delivery process, using clever automation, in 3 steps:

1. Automation supporting manual regression testing activities
— One-Click test environment setup
— Preparing fully readable and executable test cycles and test cases
— Ensuring that an unchanged component is not double-checked or unnecessarily tested

2. Automation maintaining project workflow, transitions, and statuses
— Recognizing when an issue is QA ready vs. when it is dev ready
— Avoiding (very!) common misunderstandings regarding testable issues
— Assuring that functionalities have been released without reading documentation and changelogs

3. Automation enhancing bug catching and reporting during testing or normal application usage
— Comprehensive incorporation of all crashes with the bugs reporting system
— Immediate notification based on priority and severity threshold level
— Automatic preparation and update of reported bugs, including necessary statistics

Now part of the CNCF landscape, Keploy is an open-source no-code E2E Testing Platform that generates test cases and data mocks from real user traffic.

Application testing is one of the biggest barriers to achieving truly Continuous Deployments because it's use-case specific. Developers often avoid writing test cases because it's time-consuming. In this session, we'll talk about how we could capture test cases from traffic data, how all infrastructure can be mocked automatically and how application writes could be safely replayed in CD pipelines (Jenkins, Spinnaker etc).  

In this session, we'll talk about how all infrastructure can be mocked automatically and how application writes could be safely replayed. We'll walk through examples of how keploy can work alongside existing testing frameworks and capture test cases quickly and mock infrastructure without needing to write Unit API test cases. We'll also cover how these test

The core contributors to Keploy will provide an overview of its features and capabilities, and how it is used at scale covering use cases across microservices across various programming languages

- Auto Generating Test case files and Data Mocks without writing test cases 
- Auto Generating Data Mocks and Stubs without writing code
- Converting Real User Traffic to Test Cases and selecting the best of those.

Are you a frustrated developer, business analyst, or project manager who feels like they know enough? However, the success you thought you would have is out of reach. You see others who make better strides but why? Is it a skills gap? 

Come learn how to set yourself apart as a project manager or developer and learn the skills of influence and collaboration. Learn from Tom’s struggles as a developer, project manager, and manager. Instead of focusing on technical skills, he had to look elsewhere. 

In “Humans are Hard, Code is Easy” we share the 3 Core Soft skills. 

• Communication - Communicate and listen with effectiveness
• Relationships - Build strong relationships by understanding other people’s interest
• Influence - Foster connection and generate influence

Attend this interactive engagement. Bring your willingness to learn and share your insights. From career ups and downs, we can glean transferable skills. There are other more important items where developers might focus on code and project managers on plans. 

Don’t miss this exciting time, register now!

When I began automating the Voice over Internet Protocol (VoIP) call for my organization, the biggest challenge was figuring out how to validate the voice flow between two endpoint. To address this issue, I utilized Twilio's API to receive the VoIP call on an Android app and then validated the transcript using the Levenshtein distance algorithm.

Traditionally, QA is considered to be the same as Quality Assurance which is the process of Testing a developed product. This leads to an increase in the number of release cycles because we tend to Test the product using our Test cases (Automated & Manual).

The role of a Quality Advocate in the Agile world is more to do with the overall responsibility of the Product’s quality. A Quality Advocate ensures that the team is building the product right by undertaking the various actions, early on in the development cycle. An eg. of this is making sure that the acceptance criteria are clearly defined, doing Test coverage at Unit/Integration level, etc.

This new definition of QA could help increase collaboration, reduce the traditional Dev vs QA issues, and ensure that the End product is of the highest quality.

This will be more based on an interactive session than a talk where I would like to keep the audience engaged with Questions and discussions.

When it comes to mobile testing, Appium has been a market leader and the most popular of all tools. But still, unless you are ready to pay hefty amounts to cloud-testing providers who do all the heavy-lifting themselves, getting started with Appium is not always very easy, especially for a beginner. With such a long and tedious setup process and so many drivers to deal with, along with having to set up all the Android SDK requirements while testing on Android, can be discouraging and drive people away.

When we first started to add Appium support in Nightwatch.js, we were faced with similar problems. And even the simpler task of testing websites on mobile browsers took us many days to figure out. That’s when we decided to build a tool named Mobile Helper, which can help you set up everything required to get started with testing your websites or mobile apps with Nightwatch.js in just a matter of a few minutes. Combine this with Nightwatch.js’s init tool and all you need is a single command to set up and run your first test on mobile device, real or emulator.

Join me in this talk as I show you how easy it is to get started with testing your websites or mobile applications, be it on Android or iOS, using Nightwatch.js; and how you can utilize the easy and powerful syntax Nightwatch.js offers to author your tests and debug them during failures using Nightwatch.js's Debug mode.

Appium is a popular tool for testing mobile applications, but it is not always necessary or optimal for testing websites on mobile browsers. In fact, using webdrivers directly can be faster and simpler than using Appium, which also relies on webdrivers under-the-hood.

In this talk, I will show you how you can test websites on mobile browsers without Appium, using Nightwatch.js, a Node.js based end-to-end testing framework. I will also introduce Mobile Helper, a tool I created that sets up everything needed to get started with running your tests on mobile browsers locally, be it on Android or iOS. With these, you will be able to go from nothing to running your first web test on a real device/emulator in a matter of a few minutes.