Jim Evans has over 20 years of experience in the computer industry, including 15 years in software testing and expertise in automated software testing. He has developed in-house frameworks for test automation and contributed to open-source testing tools, most notably Selenium, the most widely used open-source web automation tool.
In case you missed this interactive session, Jim and our host Manoj Kumar talk about how Jim began his journey with Selenium, his experience as an open source and standards advocate (including his current open source project at Salesforce), and the future of Selenium.
Here’s the video link of the entire session:
Jim begins the session by reminiscing about the day before cloud infrastructure and how he got started with Open Source. As one of the QA leads, he spent a great deal of time performing an automated test suite for the windows based client application. The web was just starting to get going, and one of the features that their dev team added was the ability to perform things via a website that would connect to the server, making them want to do web automation. At the time, they were a dot net shop. They were using C# for everything, so they started looking around and thinking about their opportunities or what libraries they had available to enable them to automate the browser.
As he started looking around, he came across a project called WebDriver, which was merging with Selenium. After getting an API system that he liked and a cross-browser project, he began his journey of spending months on bindings and committing to Open Source.
As Manoj and Jim discussed his journey in the tech world, Manoj also asked some fascinating questions:
Jim introduced the UI Test Automation Model, aka UTAM. As he explained, Salesforce leverages a lot of UI automated tests written primarily with Selenium and Java because many of the Salesforce applications on the server side are written in Java. They have an in-house page object framework, but Salesforce is not just an application. It’s also an application or a development platform, and it’s an incredibly customizable platform. The customers make their customizations even to reskin the whole app completely. Therefore, in that sense, they will want to do testing if they’re doing development on the platform. One of the challenges with Salesforce as an application is that it can be pretty complex from a UI-based automation standpoint.
This is where UTAM came into play. After doing some market research, Jim realized that developers use different languages. So, Salesforce decided to Open Source or make available a set of page objects that would allow their customers to use the page object pattern to write and run tests against a salesforce application without having to do all the locating of elements and so on. This led to creating a grammar by which they could declaratively describe the shape of a page object and the shape of its API and created a pair of compilers that would take the JSON description and generate the source code for the page object itself.
It is an Open Source and is available to access on GitHub.
Jim quoted an old saying, “With enough eyes, all bugs are shallow”.
Through this, he tried to elaborate on if in a team there are a lot of people looking at the code base, there will surely be someone who would figure out how to resolve any issue. With projects working correctly, they tend to be more stable.
Open source could lead to innovation in the sense that if there is a need for a feature in an open source project, people can try to build the solution by easily accessing the code base. This not only gives space for creation but also becomes economically beneficial.
Moving on, Manoj also put up a question asked by the attendees as an extension to his previous question:
Jim suggested scrolling through Twitter and following people in the software industry. Other than that, Slack channels and Selenium IRC channels could be a great place to start.
Finally, Manoj dived into the question:
This is where Jim talked about being given the two best professional opportunities:
Practice: As a developer, learning by doing has helped him immensely, and he has grown in his career.
People: During his journey, he talks about meeting many highly skilled and intelligent people who have helped him learn so much.
Talking personally, he talks about how some of those developers ended up becoming his great friends and helped him build great relationships.
Jim also highlighted some of the challenges of Open Source. He talks about how not having great support could lead to experiencing burnout. And it can also lead to challenges for communities working together on building libraries without any financial benefits.
In the end, Jim shared his perspective on what Selenium could look like a few years later. He emphasized that the Selenium project has always had strength because it’s based on standard web technologies. That means that a lot of the heavy lifting for how selenium does things with browsers is written into the browser itself. It is because browser vendors built the browser, so they know how to automate it better than anybody. Selenium projects assist people by providing a better way to integrate with this mechanism.
In recent years, the community has seen a proliferation of other test automation projects that aren’t tied to the WebDriver protocol. Therefore, the only way Selenium can compete with these tools in the future is by adopting a bi-directional protocol as its primary mechanism for communicating with a browser.
Before ending the session, a few questions were asked by the attendees. Here are some of them:
What security checks should companies do before using an open source product?
Jim: Not being a security expert, but one of the things that can be done is an audit of the source. And if you or your company can do that, that could be a way to avoid security concerns. Another alternative could be interacting with the development teams.
How can QAs contribute to open source apart from being a developer?
Jim: Helping out with testing because Open Source projects rarely have enough. Another way could be to contribute test cases to the open source development as they don’t have enough test coverage. Having new unit test integrations as part of the regular development process could be fantastic.