OpenTest: McDonald’s debut into open-source software

Global Technology is reaping the benefits from and leaving its mark on the Open Test user community.

by Adrian Theodorescu, Senior Software Development Manager

Six years ago, my boss’s boss asked me to work with our Global Quality Assurance department to define a functional test automation strategy for McDonald’s. At the time, we had several teams doing test automation using different toolsets and approaches with varying degrees of success, but it had become clear to us that there was plenty of room for improvement.

After interviewing our test automation teams and reviewing many mainstream commercial and open-source tools in the industry, we determined that each one of those tools had at least one critical limitation:

• No cross platform support.
• Not covering all areas of interest (web, mobile, APIs, cloud, database, etc.).
• Requiring advanced programming skills and difficult to use by less experienced testers.
• No support for distributed testing (running tests across multiple machines and networks).
• Not playing well with source control systems.
• Mostly focused on image-based testing, etc.

From the relatively wide selection of open source and commercial test automation solutions available at the time, none of them was really hitting the mark for us.

A difficult choice
At this point, we were contemplating the prospect of continuing to leverage a mix of open source and commercial tools and accepting the reality of a fragmented test automation landscape. That did not feel right at all, and after extensive deliberation we decided to go a different way. We would create a new tool that avoided the limitations we could not live with and included all the features we cared most about. This would be a tool that we could freely enhance and extend over time. It was not going to be an easy journey but, given the alternatives, we deemed it was the responsible thing to do.

Creating something better, together
Fast forward two years later, OpenTest had incorporated most of the features we had planned for: keyword-based testing, data-driven testing, support for web, mobile and API testing, a scripting engine, distributed test execution and many others.

Our internal user base had grown organically to hundreds of users on four continents, which signaled to us that our initial vision for a unified test automation platform had finally come true! It was a humbling and exciting experience to watch people we had never met or worked with sharing their insights about OpenTest on internal forums, answering questions and producing documents to help their teams.

This made us wonder: What would happen if we open sourced the code and made the tool available to the whole test automation community?

Why go open source?
A legitimate question many business-oriented people ask themselves is why would someone open source a codebase built with their own sweat, tears and capital? The rewards might not be obvious, but they can be significant, nonetheless. Some benefits that come to mind are:

• Enabling external and diverse contributions to the codebase
• Getting community bug reports and support
• Accelerating novel ideas
• Increasing brand awareness and attracting engineering talent

At McDonald’s, our supplier base and global teams evolve very rapidly. As such, the open sourcing for us led to another significant benefit by reducing the unnecessary friction involved in getting the software onto people’s machines. No more approvals required and no more dependencies on other teams for the actual binaries and updates. Everything you need to get started — installers, documentation, community forums, etc. — is freely available online for anybody to make use of right away.

One outcome that we did not anticipate was creating a sense of community around OpenTest, with all the good things that came from it. Contributing to open-source projects is less stressful and generates better quality code because developers know their effort will help the larger user community and not just improve some business metrics.

The challenges of open source
Releasing OpenTest as open-source software was not as simple as publishing the source code. There were many other factors involved, from legal aspects to the practical challenges of providing our users with everything they needed to succeed:

• Choosing a suitable license. The license terms must give your users the confidence that it is safe to invest their time and effort in adopting your solution but also protect you from legal exposure in the future.
• Good quality documentation. Having to put in a lot of hard work just to discover the core features of your solution negates the benefits of using the software in the first place.
• Patching and enhancements. A codebase is a living, breathing thing, and you need to be ready to provide security patches and bug fixes for your users as well as adding support for common use cases that you did not anticipate, at the very least.
• User support. Every now and then, your users will inevitably reach a dead end of some sort. When the user community cannot assist, it’s the responsibility of the maintainers to step up and save the day.
• Miscellaneous: Providing a straightforward and secure installation process, reviewing dependencies and making sure to comply with their licensing terms, providing contributing guidelines and coding standards, etc.

Conclusion
Open sourcing our functional test automation tool brought with it lots of benefits, allowing McDonald’s testers to move faster and collaborate better. This experience taught us that open sourcing should not only be looked at as a display of altruism but also as a strategic business decision.

To learn more about OpenTest or take it for a spin, visit getopentest.org.