The whole area of automation testing for mobile devices is really coming into the spotlight in the testing industry. With a growth in clients requiring mobile testing from Sogeti, we are looking to expand our mobile and web testing lab, Sogeti Studio, and therefore it is imperative we fully understand mobile automation testing and all possibilities within the arena.

From an overall testing automation point of view, HP QTP (as it was known for many years) – now known as UFT (Unified Functional Testing) has generally been the staple automation tool within the testing industry (as most of you probably know). But in the current mobile testing space there are alternative choices of tools/APIs, especially as more customers look to open sourced solutions for mobile automation testing, such as Selenium.

Webinar – UFT or selenium:

On the subject of mobile automation testing an interesting webinar was very recently hosted by Sauce Labs. This Blog effectively summarises the highlights of the webinar, with input as to how Sogeti Studio is related. The webinar provided an objective comparison between the use of UFT (as a tool) and Selenium (as an API) for mobile test automation. The webinar did not really state whether one choice or the other is better; instead providing a more objective view of both:

It is important to firstly consider that Selenium is a web-based automation API (Application Programming Interface) and not a ‘tool’ as such; whereas UFT is classified a testing tool. Selenium can be consumed within one of the languages it supports, although there is no user interface as such.

With UFT, the tester effectively controls the tool to do the actions; whereas Selenium uses a language to communicate. A big plus for Selenium is that it is open source, and the relatively low cost has made it popular; hence usage of selenium by numerous companies has increased for web automation. UFT supports a huge number of technologies which made it the most popular tool for test automation for some years. However in very recent years the number of projects has grown hugely for mobile and web testing. This is why selenium has grown in popularity for mobile automation.

Operating Systems (OS) / Languages / Browsers supported:

Selenium can support numerous OS such as Linux, Mac OS X, Blackberry, plus Windows versions, whereas UFT is really Windows-based. In terms of languages, UFT is Visual Basic (VB) script only, but Selenium supports more languages such as Java, PHP, Python, Perl, and MS .Net. Of these, Java is perhaps the most often used with Selenium, which is why developments can tend to use java. As for browsers, which are obviously key for mobile testing, more are supported by Selenium, including Android, IE, Chrome, Safari, Firefox and Opera, while UFT apparently does not support Android. Also there is a view that Selenium might be better at dealing with patches/upgrades.

In terms of execution QTP/UFT was designed to test one application at a time on a single machine; whereas Selenium can run code on one machine, and test the application on a remote machine. Also Selenium is cloud ‘ready’, and can also allow multiple browsers on the same machine.

Set-Up and Licenses:

A downside of Selenium can be the initial set-up time; although for UFT, subsequent maintenance can take longer due to possible multiple machines. For Selenium users there are cloud testing providers available (i.e. Sogeti Studio); whereas your own lab is required for UFT.

As for cost, HP licenses can be expensive, whereas because Selenium is open source, it is 100% free. More mature frameworks can exist for Selenium; although the manpower cost of building frameworks can be a high cost factor.

Market Trends:

Use of UFT has dipped post-2012, with Selenium increasing in terms of job trends. HP has now introduced HP Mobile Center as a tool in response within the growing mobile automation sector. Users are also apparently doing more google searches for Selenium, with interest having increased in the last year or so.

Challenges with Selenium:

Even though some of the output here may point to Selenium advantageously, there are certain challenges with Selenium, such as;

–          There is no object repository to store object mappings

–          Some scripts which work in Firefox and Chrome may not work in IE

–          There are no object types in Selenium, only WebElement and Select

–          Tends to be a higher development effort/cost for initial few months

–          May not be suitable if the app to be tested is not web or mobile

–          May not be ideal if you do not love open source software

–          If you prefer GUI-based tools to allow you to create, manage and execute test cases then UFT may be better (ie ALM with everything managed in one place) but licences add significant costs).

More Selenium Features:

–          As the code will have effectively been tested then some QA Testing could go to development teams across projects. This may lead to a shift long-term towards developer testing followed by user responsiveness testing for mobile, with QA testing possibly disappearing on mobile projects?

–          There are lots of languages and more control over framework due to language choices.

–          Selenium can implement scalable testing using cloud/grid.

–          It has lots of frameworks for flexibility, including most of unit testing frameworks.

Overall the webinar was a very interesting insight into this subject and the information is very relevant in the mobile automation testing space.

In Sogeti Studio, we use selenium as the centrepiece of our unique SAF framework to promote multichannel testing for our test automation offering. Selenium gives us the capabilities to create a suite of tests to run across multiple browsers and platforms in parallel, which helps us minimise automation development time and can help to maximise test coverage. We are also looking to introduce HP Mobile Center soon, to give our clients full choice.





Posted in: Automation Testing, communication, HP, Quality Assurance      
Comments: 0
Tags: , , , , ,


To push forward Sogeti Studio, as well as the more typical Sogeti service offerings, it is important to maintain an understanding of test tools available in the market. This is not just from the perspective of Sogeti purchasing such tools, but we may be able to help a client make a selection from a range of options, or we may even have consultants at a client where there are new tools in place already. One such tool is from IBM, called Service Virtualisation (SV) – see links to useful YouTube videos for this tool at the foot of this blog.

In IBM’s own words, “the main aim of Service Virtualisation is to deliver types of testing (ie E2E functional, regression, load, integration) to address challenges of highly complex and integrated applications much EARLIER in the overall project lifecycle.” I am sure many of you can relate to client projects where you have worked with numerous integrated applications; the key selling point from IBM is that the tool can enable test teams to automate integrated testing much sooner, which can contribute towards the much talked about holy grail that is the ‘shift left’ concept.

IBM provides clear, written instructions on using the tool which effectively simulates virtual applications within an environment such that integrated testing can be executed, even if that actual application is unavailable due to development reasons. In addition, testers can create their own ‘partial’ environments as the tool creates stubs and drivers in place of actual environments. This is useful in environments which send ‘acks’ from one system to another on receipt – i.e. for high-volume financial businesses. The tool is used to provide access for software development and QA/testing teams to dependent system components that are needed to exercise an application under test (AUT), but are unavailable or difficult to access for development and testing purposes. With the behaviour of the dependent components “virtualised,” testing and development can proceed without accessing the actual live components.

Benefits of Service Virtualisation:

Key benefits of the tool can include:

– More time available to do development or testing work, or simply getting the same work done in less calendar time, so faster time to market for the application.

– Lower cost, often in the form of avoiding lab hardware and software expenditures on prerequisite systems required for the application, but out of scope for the development or testing activity.

– Higher quality, because typically the environment is stabilised, and so defects are caught much sooner in the software life cycle than they would be without Service Virtualisation (SV), where the team waits until the entire application assembly is available before beginning ordinary testing activities.

In order to move to an effective agile development process you truly need the connectivity to the interfaces that the new code will be interacting with. This could be real systems but that would require countless amounts of hardware and application software to support the vast number of agile development teams. SV addresses this constraint by allowing each development team, and potentially each developer, the ability to have their own view of the entire application stack with all interfaces represented.

Over the last decade, virtualisation has transformed the manner in which IT services are delivered, by providing a platform to reduce cost through consolidation, increase agility and deliver improved service levels. However, virtualisation does present new challenges to IT teams e.g. how to design and deliver the infrastructure to support this; how to secure and manage the virtual environment; how to ensure that issues are captured before they go into production or live environments etc.

Find out more about Sogeti Studio and it’s capabilities here.

Youtube links:

What is Service Virtualisation?

When to use Service Virtualisation?

Service Virtualisation – Return on Investment

Service Virtualisation – Increasing Team Velocity and Delivering Higher Quality Software



Posted in: IBM, Virtualisation      
Comments: 0
Tags: , ,


The area of accessibility testing (aka testing for functionality to suit users with certain disabilities) is something which is becoming increasingly important in our industry, especially with the move to digital strategies and displaying information across multiple devices and platforms. W3C standards for Web Content (hence the acronym) have introduced standards and guidelines to assist companies and development teams to deliver websites that cater for users with disabilities to make accessibility easier, or in some cases possible, on pcs or mobile devices.

Users who might benefit from W3C standards may have one or more of the following conditions: visual or hearing impairments, motor impairment, seizures, or cognitive disabilities such as dyslexia.

As much as some of you are probably well versed in this, and maybe even experts, there will be some of you thinking ‘well, so what?’. The thing is; an increasing number of organisations are delivering functionality into their websites to comply with W3C standards, therefore Sogeti, and our Studio, are concerned with an awareness of the types of functionality which could be delivered for testing and how to go about testing it effectively across various platforms, including mobile devices.

Now, we don’t want to lecture our clients on what sort of development they should be delivering with respect to accessibility; however, Sogeti believes working in partnership with our clients to raise awareness of W3C considerations will assist clients to build a solution that can be accessed by all – after all increasing your audience should lead to increased conversion rates on ecommerce platforms or simply widening the message that your company is trying to deliver to market.

In essence, the laws of the land which have pushed this are forward are; The Disability Discrimination Act 1995, Special Educational Needs and Disability Act 2001, and the Equality Act 2010.  The main organisations behind these standards are: the World Wide Web Consortium, which has produced the following interesting guidelines (; and the British Computer Society Disability Group:

In terms of mobile testing for the W3C standards, the guidelines apply across all platforms as they are designed to be broadly applicable to current and future technologies. Obviously, as testers, we are constrained in terms of what our clients deliver by way of accessibility functionality; that said we do have a part to play in terms of helping clients formulate requirements/deliverables if possible. 

Given that rendering of websites can differ across platforms, it is very important that when testing for accessibility on a client project you must consider mobile testing of the same functionality using various devices. Even if the accessibility standards are consistent across all devices, what the client delivers may not work the same across all platforms/devices. It is up to us as testers to consider mobile usage for testing these standards, and steer clients accordingly.

Hardware for accessibility (i.e. special keyboards/ rests/ mouse types) often accompanies PC testing, and may not apply to mobiles. However there are some software types that should be considered when planning mobile accessibility testing (i.e. speech recognition/ magnification). This short guide (here) document lists areas to consider for delivering accessibility testing, plus suggestions of tests from the W3C website which can be adapted or used as they are.

Why not get in touch, and see how Sogeti Studio can assist you with your Accessibility considerations. Email us today at:


Posted in: e-Commerce, Human Resources, mobile testing, Sogeti Studio      
Comments: 0
Tags: , , , ,