WebDriver shows growing popularity for many years and at least for past 4 years it is number 1 player on the market of web test automation solutions. The growth hasn't been stopped yet. The WebDriver exposes open interface and it's server side API is documented in W3C Standard. Thus, a lot of people can implement their own back-end API and expand technology support. So, WebDriver can become more than another option among web test automation tools list. It may become (if not yet) the most wide spread test automation platform so that the term of UI test automation may be replaced with another term like Web-Driving. In this post I'll describe where the WebDriver solution "web-drives" us to and where are the areas of further growth.
What makes it so popular?
It became popular for many different reasons apart from support from different vendors. It's too little to become competitive solution on the market of test automation solutions. There are many other things which made WebDriver far better than many others on the same area. Major factors are:
- It's free. Well, maybe you'll bring some other advantages which look more prominent than price but I really doubt the WebDriver could gain at least half of it's popularity were it at competitive price to vendor tools. It doesn't have many things almost each vendor tool has. Even more, it's not really wise to compare WebDriver with black box solutions like UFT, TestComplete or similar as these are systems of different class. Nevertheless, the knowledge of WebDriver is more required in current test automation world than anything else and it's price was very helpful factor in it
- It's simple. Another thing which can beat many of competitors is definitely simplicity. Mainly you need to know 20-30 methods to be able to do almost everything with your application under test. The way to combine it is up to you but the core functionality is simple and it's too few of it.
- It's easily adjustable to user needs. Well, mainly you can use the programming language you like, your favourite IDE and any existing infrastructure the development teams have. And it is not just about making various ports on different programming languages (as it was done with Watir) but it is something which was initially included into design. Yes, client-server architecture initially gives us ability to have common server side and the only part which requires migration is the client code. Also, you don't really need any "bells and whistles" to combine your code into test suites, making some checkpoints and some other routine stuff. Existing test engines, build infrastructure already did that for us.
- It's portable. You can run your tests on different environments. Even more, you can pack your testing solution and provide as the binary or similar runnable resource which you can run wherever you want without any necessity to install any specialized software
Expanding WebDriver outside of web
Despite the WebDriver contains the word Web it is not necessarily limited with web technologies. The idea is that no matter the UI type we operate with we need to do some common actions to interact with each specific application and each specific control. Some of them are:
- Start application and adjust communication with it
- Detect the control by some identifier or combinations of it
- Verify elements presence
- Click/tap on the element
- Enter some text
- Retrieve some attribute value
- Handle popup messages (which should be standard for each particular technology)
Thus, we've got the TWIN framework for .NET which implements WebDriver interface but targeted to desktop applications. This framework doesn't seem to be developed for a while (I see the latest changes were made at October 2012) but the idea is still alive.
There is another WebDriver implementation for Windows Phone. Also, no updates since 2013 but still it's another WebDriver implementation for .NET based systems.
And it got new implementation in Winnium solution which combines at least 3 modules:
Android and iOS
Major mobile systems also didn't experience lack of attention. Thus, WebDriver had separate implementation for mobile browsers for both systems:Appium which combines both platforms and it's pretty intensively growing.
It is also good indicator of popularity when the engine is getting support from other vendor tools. E.g. TestComplete is targeted to support WebDriver starting from 10.5 version. Well, I'm not sure what are they trying to do with it, maybe there's going to be some benefit. The future shows how should it be but anyway there is such fact and it's worth attention.
Supported Technologies Market Share
All right, we now see that WebDriver goes outside of web and it means that it will eat some bigger portion of test automation market. In order to see the size of this portion we should simply identify market share for different technologies and figure out which market segment the WebDriver can be applied to. Mainly, we can highlight 3 major technology areas where WebDriver can now be applied to:
- Mobile (including mobile browsers)
Browsers Market Share Coverage
Browsers is the initial WebDriver area which nowadays covers not just desktop but also mobile browsers. Here is joint market share data for both desktop and mobile browsers:
Alternative data can be got from W3C Counter stats source:
Mobile Market Share Coverage
As for mobile market we may find such data:
|Period||Android||iOS||Windows Phone||BlackBerry OS||Others|
Desktop Market Share Coverage
For desktop software it's a bit more difficult to calculate more or less reasonable parameters to spot actual coverage as we have to list all major desktop GUI technologies and their popularity. Such information is hard to find. But at least the accessible market share can be defined by identifying market share of desktop operating systems:
Summarizing market share data
So, the joint market share where WebDriver can be applicable can be represented with the following table:
|Technology area||% Market Share Covered|
Where WebDriver can grow next?
However, the WebDriver-based solutions also need a lot development efforts. A lot of things are still not covered, a lot of "nice to have" things are missing. So, there's wide range of areas where to grow. Just some of them are:
- Technology expansion - as it was mentioned before there are some quite essential technology areas where WebDriver-based solutions aren't represented. So, if such technologies become more popular there would be some developers who will prepare some solution for testing it. WebDriver is good at that as we already have common interface for communicating between client and server part. Everything else is up to technical implementation
- More unification - currently all previously mentioned WebDriver-based solutions are just separate and independent projects which grow with different velocity. In the future it's good to see some unified solution which combines all of these implementations and it should be provided as a single box.
- Well-developed high-level API - the WebDriver interface is very core part of test automation framework. It provides major solutions but we still require to create some additional abstractions to represent different control types with major interface for interaction with them. Many times when I started the automation project I had to write such layer of abstractions. After some time I've came up with some king of common framework, very likely others did the same. But what if there would be some other unified higher level ported to different languages? Well, it's something worth thinking about as well as such solution can be the basis for the next item.
- More or less unified solution for page objects generation and UI elements definition - if you take a look at most of big vendor solutions like QTP, SilkTest, IBM Functional Tester and many others you will see they all have some forms for displaying, modelling UI objects hierarchy with the ability to store such objects map in some resource. That can be either dedicated repository or just another portion of code. Nevertheless, they all definitely have tools for visual modelling of all those page objects where we can select proper identifiers for elements, define which elements we need to be generated and which are not. What do we have for WebDriver-based tools right now? Well, I know Appium has inspector which can view objects hierarchy, also we shouldn't forget about Selenium IDE. What else? Almost nothing! So, we definitely need something more solid in this area as well. Maybe it should be some kind of plugins to different IDEs or it can be some dedicated UI tool based on some IDE (just like IBM Functional Tester was based on Eclipse or Android Studio is based on Intelij IDEA).
WebDriver is the most popular UI test automation framework for many years already and it went far beyond just web testing framework occupying wide range of modern technologies and eating some portion of market out from competitors. The approach itself has been proven useful and WebDriver still has huge potential to grow. It's not just technology coverage but also libraries expansion to higher level API, various helper tools and other things which a typical for big vendor solutions. I expect to see the same around WebDriver.