Q & A with the Selenium Committee

Selenium: State of the Union

This talk suggests a reframe in how we understand the business value of automated testing. One shift is to see automation as "checking" rather than "testing". Another is the shift from software delivery to service delivery, including fully embracing DevOps. The resulting approach could be called Checking as a Service or CheckOps, and forces us to rethink traditional automation priorities. In this talk, Bret will explain how change in approach has affected teams he's worked with and how you can use it to improve your ability to deliver valued services.

Hike is used by 100 Million users and many of our users have cheap smart phone (~ $120 USD) that can install no more than 3 mobile apps.

So the questions is: Should testing of app be limited to its functionality? At Hike, we believe "Performance is Queen!" For our users, if we misuse the critical resources such as Battery, CPU, Network and Memory, its a deal-breaker. Hence pref-testing is very important.

During the initial days of Hike, we were very reactive and only did (manual) perf testing, when our users reported issues.

Now, every Sprint (2 weeks) and every public release (monthly), we run our automated perf tests. We measure our app's performance using several app specific use-cases on 4 key areas:

• CPU,
• Memory,
• Battery and
• Network (data consumption.)

We also benchmark the following scenarios for app latency:

• App launch time upon Force Stop
• App launch time upon Force Kill
• App's busiest screen openning time
• Scrolling latency in different parts of the app
• Contact loading time in Compose screen

We still have a long way to go in terms of our pref-testing journey at Hike. But we feel, we've some key learnings, which would be worth while to share with the community. Join us, for a fast paced perf-testing session.

These days we find most of the apps are being developed across different platform, iOS, android, windows and to keep the user base which uses web, mobile web and websites. 

When apps are being developed for cross domains, most of the functionality provided by the app is very similar, varying thing is PLATFORM. 

 In rapid development cycle, where there are tools which allows you to write once and reuse across multiple platforms, makes development very faster. 
But at the same time, if we have different automation suite for different platforms, it becomes very difficult to keep a pace with ongoing functionality. 
This is the exact problem we faced, and the solution we came up with is "One Page to test them all! -A cross platform mobile automation framework! "

Page Object Model

Well, Page Object Model was again a natural fit for this framework. Most implementations of POM recommend different POMs for each platform. But we wanted to have a single Page Object Model for all the 3 platforms to ensure maximum code reuse and reduce overall time spent in adding new automation.
 

Single Page Object Model across platforms

This was complicated because we had native screens as well as webview screens and so it was not possible to use the same Page Object. To solve this, we introduced abstractions for the elements on the screen and encapsulated the respective native driver implementations.

This also allowed us to implement common automation tasks in one place for e.g waiting for new pages to load, so that this code is not repeated across multiple step definitions and platforms. This helped us move to thinking in higher domain level concepts than in terms of low level UI interactions.

So, in summary, we write our tests for one platform and run them for all with an abstraction layer in place.

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?

Analytics are an increasingly important capability of any large web site or application. When a user selects an option or clicks a button, dozens—if not hundreds—of behavior-defining “beacons” fire off into a black box of “big data” to be correlated with the usage patterns of thousands of other users. In the end, all these little data points form a constellation of information your organization will use to determine its course. But what if it doesn’t work? A misconfigured site option or an errant variable might seem insignificant, but if 10,000 users are firing 10,000 incorrect values concerning their click patterns, it suddenly becomes a problem for the QA department―a department which is often left out of conversations involving analytics.

Join Marcus Merrell to learn how analytics work, how to get involved early, and how to integrate analytics testing into the normal QA process, using Selenium and other open source tools, to prevent those misfires from slipping through.

Marathon is a open source test automation suite for Java Swing and Java/FX applications. Marathon provides Selenium/WebDriver bindings for executing test scripts agains Java application.

In this workshop we explore steps by which you can set up an environment for testing a Java/Swing application.

Automated visual testing is a major emerging trend in the dev / test community. In this talk you will learn what visual testing is and why it should be automated. We will take a deep dive into some of the technological challenges involved with visual test automation and show how modern tools address them. We will review available Selenium-based open-source and commercial visual testing tools, demo cutting edge technologies that enable running cross browser and cross device visual tests at large scale, and show how visual test automation fits in the development / deployment lifecycle.

If you don’t know what visual testing is, if you think that Sikuli is a visual test automation tool, if you are already automating your visual tests and want to learn more on what else is out there, if you are on your way to implement Continuous Deployment or just interested in seeing how cool image processing algorithms can be, this talk is for you!