Seamless Migration to Selenium: Why is it so critical?

During 1970s – 1980s, Open Source got commercialized and there were volumes written on its adoption into mainstream. The Open Source Initiative (OSI) came into existence in 1998, which boosted the overall initiative and efforts.

It has been stated that almost 98% of enterprise-level companies have adopted Open Source to address various software related issues and leverage other compelling benefits related to use and ease of adoption.

What takes it further in the value chain? It is the fact that today acclaimed government bodies with critical operations are adopting Open Source software to run and operate their virtual platforms. For instance, the US Department of Homeland Security relies on Open Source to help detect bugs (Ref: Wikipedia).

Why this Interview?

In our discussions with clients, mainly during the initial stages, we observed that most leaders in large enterprises who showed specific interest in migrating to Selenium, however, have already made substantial investments in commercial tool stacks.

In this interview, we have surfaced some key aspects related to Open Source adoption and to a great extent focused our discussion on Selenium, which has proved to be a tool of choice for testers, developers and enterprises globally.

Rajesh Sarangapani, AVP, Global Delivery, Cigniti Technologies, heads the Technology CoEs at Cigniti and with his 17 years of experience has been instrumental in helping clients implement processes that enable them to enhance application’s performance by design rather than as an afterthought. Rajesh continues to interact with Fortune enterprises, assisting them in building a comprehensive Migration strategy to Open Source solutions like Selenium.
He also holds a couple of patents to his name in the testing space and is a prominent speaker at various conferences, events and webinars on Software testing. In this interview, we discuss with him on some impending issues and concerns related to the topic.

By migrating to Open Source solutions such as Selenium, don’t you think clients are moving away from their decade long proven and tested commercial solutions and in a way taking a risk?

RS: We have been speaking and advising our clients on various fronts related to adoption of Open Source. During our interactions over the last quarter, it did not seem that this transformation that our clients are considering and undertaking is a knee-jerk reaction to some of the mergers/acquisitions and consolidations happening in the marketplace.

There has been a silent and conscious adoption of these tools in some shape or form within the teams. The client teams have been investing time and efforts to assess on 2 fronts:

The best-suited areas for adoption

Non-critical aspects of testing that can be automated via these tools to bring in cost efficiencies

I would say, over the years there have been multiple factors ranging from maturity of open source, community adoption, skilled workforce that has increased the adoption of Open Source amongst enterprises.

Hence, the client’s decision to move away from proven commercial solutions is what I would say is a “silent” revolution, which has now reached a tipping point and it is expected to only increase further due to various external and internal factors affecting each enterprise.

You constantly interact with clients for various reasons. What are the major problems/concerns that they talk about with reference to adoption of Open Source?

RS: Reference to Open Source testing tools, Selenium adoption is definitely growing in popularity and many enterprises are looking at it for reasons that go beyond its cost-effectiveness. Concerns are mainly related to integration and migration.

To sum it up, these are some prominent concerns/issues related to adoption of an Open Source tool:

When we choose Selenium/any other tool for migration, scripts don’t replay as expected. So our teams have to provide workarounds or alternative paths to solve related issues.

Test scripts are not in sync with the application under test functionality, so we have to get the scripts updated to reflect the latest functional changes.

Weak design patterns adopted lead to brittle scripts post migration. Eventually, we have to re-architect the framework to ensure that the scripts are reliable and ensure the application’s overall robustness.

I understand that you have been actively working with clients over the last quarter, helping them with test asset migration solutions. Can you help us understand some of their common drivers behind these initiatives?

RS: Reference to Selenium Migration, we have been closely working with clients and implementing our resources to make the migration smooth and quick. For instance, Cigniti’s proprietary framework Migrate2Selenium helps clients migrate from any platform to Selenium. So, we try and understand their concern in detail and then work on the solution/platform.

From our interactions, these are the key drivers for considering Migration to Open Source.

New development methodology: Clients have been transforming their delivery methodology from Waterfall to Agile or DevOps and this transformation is making them seek solutions that can question their status quo of the Automation strategy right from the tools, processes, and people/skills involved.

Total Cost of ownership: The total cost of ownership to develop and sustain an automation initiative is a critical component to create a business case for test automation. One of the major cost-drivers is tool licenses and maintenance fee that need to be budgeted in the overall expenses. By adopting Open Source solutions this factor would be completely eliminated, thereby the value proposition from cost efficiencies standpoint looks really promising.

How does your Migration tool (Migrate2Selenium) work?

RS: Our migration solution is a tool independent platform. This is a 3 step technical approach:

Step 2: The assets need to be refactored to make them compliant to the target platform. One of the common issues is variable declarations that need to be aligned to the target platform, programming constructs, as we move from a loosely typed to a strongly typed language.

Step 3: We execute the scripts on the application and take sign-off from the client after it meets the acceptance criteria.

What is the value proposition for clients?

Our migration solution delivers an average cost saving of 50% and productivity gain close to 50%. The major thing that we ensure is that the clients can continue to run their business as usual with minimal oversight and time to support the migration journey.

We offer a modernised test suite for migration, where based on the inputs from clients, we help them jumpstart the target platform with test automation framework, which can be leveraged for future scripts as well.

Do you think a pilot run is required before signing in for an entire Migration process?

Of course, clients should experience a pilot run before going in full-fledged and investing. They should pick-up few scripts, which are representative in terms of complexity and functional coverage distribution. If successful, it can be repeated for other test suites that they might have. This helps build confidence for further work on larger migration projects.

What has been the business objective for Migration? Cost saving on license or flexibility for web applications?

Some of the clients that we are engaging with and speaking to at the moment are in the license cost savings range of $100K to $800K per annum, which is massive. In addition, it allows clients to get flexible and expand their test coverage by harnessing on premise or Cloud options for browser/device compatibility tests.

What has been the size, industry/sector of the clients who have leveraged Migrate2Selenium?

We have worked with clients mainly from Communications, Media and High Tech industry with an employee size of 1000 – 5000 and a turnover of about a $1Billion. We have also worked with Fortune 2000 companies in the BFSI sector with a turnover ranging from $500 mn to $2Bn.

In terms of costs, what should be the expected ROI?

We have adopted multiple pricing models ranging from price per script approach to completely fixed price contract. The contract type is completely customizable and is based on the complexity, volume and our assessment of how latest is the current test asset that we are migrating to.

We have seen in the past engagements that if the client teams stop maintaining the test suite refactoring, the test assets from the latest version of the application under test would require additional effort to bridge the gap. In terms of ROI, we typically offer almost 50% reduction in costs and efforts.

How does Migrate2Selenium work for Commercial Off-the-Shelf products?

Cigniti’s Migration platform/architecture is capable of migrating to multiple Commercial Off-the-Shelf tools. The current release supports migration from UFT/QTP and SmartBear TestComplete assets to LeanFT and Selenium assets respectively.

As part of the roadmap for the next quarter and increasing demand from our clients, we also plan to build IBM Rational Functional tester support. Migrate2Selenium is a version independent Accelerator that can migrate any version of test assets from QTP/UFT to Selenium.

In terms of languages, there was a distinction between C# and Java and other languages, provided through plugins. I did not quite understand this distinction: could you elaborate?

Selenium tests assets can be developed in multiple languages for example, Java/C#. Our platform has the ability to migrate to language of your choice that you need to build your test assets on (for example, C#/ Java).

Assuming clients have developed their own frameworks, does Migrate2Selenium also handle testing frameworks, including objects and libraries?

Yes, we are framework independent, not tied to any specific design approach. We collect all the dependencies (for example, object repository or utilities written in VB Scripts) and migrate the dependencies as well to the latest test tool platform.

Considering the entire process is automated, where is human intervention required?

Human intervention is primarily required for the post migration phase. During this phase of refactoring, the engineer would go through the report from the migration team and find a list of To-Do’s. The To-do’s are primarily a list of actions to ensure the script is correctly ported to the target platform.

The To-do’s are grouped under Warning and Errors. Some examples of warnings are basically the type of variables being declared (by default we make it a generic Object). The inability to automate this process is more to do with the construct of QTP/UFT (VB Script), which is a loosely typed language. This script when ported to strongly typed language needs an appropriate variable. Even this aspect can be taken care of by the tool if the script developers would adopt variable naming conventions to signify the variable types, for example, str for string, Int for Integer etc.

Coming to the next set of human intervention requirements, there could be situations where there is no corresponding function in Selenium and the migration tool would mark them as errors.

In a recent project, where we were involved in the Migration, the client had used un-documented UFT functions that are not very commonly used. But still these required migration by either creating a custom function or mapping it to a corresponding function. In a worst case scenario, we provide a set of libraries that are available in open source so that the migration is successful and seamless.

For what kind of applications (in terms of functionality) has this IP been used?

Cigniti’s Test Automation platform has been leveraged by over 100+ clients. The current Migrate2Selenium platform post upgrade is utilized for about 5 clients and we have 25 more in the pipeline.

With our extensive experience in Selenium Testing, we are excited to invite you for our first TweetChat on the engaging topic Migrate to Selenium. Join the buzz and get all your queries and knowledge on the deck with our experts!