In this interview, STAREAST keynote speaker David Dang explains why the second wave of open source test automation tools are coming in at just the right time. He covers what they are, what they've learned from the first wave, and how to integrate them into your team.
Josiah Renaudin: Welcome back to another TechWell interview. Today I am joined by David Dang of Zenergy Technologies, who's a keynote speaker at STAREAST 2016. David, thank you very much for joining us today.
David Dang: Thank you for having me.
Josiah Renaudin: Absolutely. First, could you tell us just a bit about your experience in the industry?
David Dang: Sure. Not to run too long, I have about nineteen years of experience in test automation. I actually started out with a developer a little over twenty-one years ago and then jumped into test automation. Throughout the years, I've been mostly doing consulting work, teaching, and also do a lot of framework design and architecting. The biggest thing from an experience standpoint is trying to keep up with all the latest technology and how best to utilize test automation to get testing more efficient and more effective.
Josiah Renaudin: To better understand the complexities of your discussion, can you define the second wave of open source test automation tools that your keynote tackles? To follow up on that, what did we learn from the first wave that's going to make this second wave stronger?
David Dang: Those are very good questions. I would say, about eight or nine years ago, all the toolsets that were in the marketplace were mostly purchased toolsets. A lot of them are basically packaged together and sold on a license-base. About eight or nine years ago, there were people that basically said, “What can we do with the web being more popular? Is there a way for us to have open source tools that will let us automate a website?”
The first wave came about with a toolset like Selenium RC, which stands for remote control, fitness, a couple other toolset on the first wave. For the most part, the first wave was a really good intro into the open source world. However, the feature base and the support by the community was not there. A lot of those open source toolsets fell by the wayside.
About three or four years ago, maybe a little bit longer than that, the second wave comes along. It was really driven by Selenium WebDriver. A lot of people know it by Selenium WebDriver or Selenium 2.0. The reason the second wave came on much stronger, is first of all, a lot of the technology went from client and server base or mainframe base into more web base. With Selenium WebDriver, the underlying thing is to be able to automate browsers. With that, companies start realizing, wait a minute… we have an open source tool that supports most of our portfolio. Not only that, part of the second wave was driven by the need for doing tests faster because of the web. Companies released more often. Companies are going to be more agile. They need ways of driving that automation quicker. Part of that is also driven by developers really pushing for...are there tools that they can use to help with test automation?
With the second wave, you see a huge uptake by companies that are really big, Fortune500 companies, that realize that there are huge benefits in adopting the second wave. The open source ability to leverage both, not only the QA team but also the development team to do some test automation.
Josiah Renaudin: Whenever automation is brought up in my line of work, I feel like Selenium is always one of the first tools brought up. I moderate a lot of web seminars, and every time our discussion topic is Selenium, people come out in droves to just talk about it. Why do you personally feel that Selenium has taken such a prominent role in the second wave?
David Dang: The biggest part is, Selenium is actually a really nice, easy framework that you can adopt. What I mean by that, Selenium has a lot of features that basically simplify what the first wave is, which is Selenium RC. A lot of the underpinning of other toolsets are based on Selenium. For example, the underlining pinning of Appium is actually Selenium-based. You have other open source tools that are underpinned by Selenium.
With Selenium, because it's relatively easy to adapt or adopt, and also because it's just at the right place at the right time. The biggest thing with Selenium is, it supports so many different programming languages and so many different platforms. Companies, for example, that use C# said, “I don't want to use a tool that is only based on Java, my people don't know Java.” They can actually use Selenium framework with C#. The same with a Ruby user, with a Python user.
Having a framework that is almost program-language agnostic and platform agnostic, it helps from an adoption standpoint for a lot of companies being able to utilize the Selenium framework.
Josiah Renaudin: A lot of the abstract for your keynote talked about the timing of the second wave and how advantageous it can be. What about the state of software testing and current market trends make the second wave open source test tools so well-timed?
David Dang: It's like the perfect storm. The reason for that is, companies are moving more and more toward web-based. If you look back ten years ago, client server and mainframe for that part was still the predominary technical. As companies moved more and more to web-based, they realized that they need tools that will do parallel execution, multiple cross-browser testing. They need a toolset that really helped them focus more on the web and not worry about the client server base, the mainframe base. The primary focus is on the web and because big companies, Fortune500, Fortune1000 companies developed more and more on the web, and Selenium being Selenium, that’s what drove it here.
It's great timing for those companies to say, there is a toolset, a framework out there, that is free and will support what I need to do. The other aspect of this is also, because more and more companies are moving to agile, as QA and development team work more closely together...At the end of the day, Selenium is really just a framework and the coding is still on whatever ID that you want to do. That translates really well with development. Developers already know, for example, they already know Java. When you say, “I'm automating using Eclipse and Java,” they brighten up and say, “I can help.” In the past where you would buy packaged tools and development teams say, “I don't have time to learn that package. I don't have time to learn those tools and how they work.”
With web being bigger, with mobile being bigger, and companies transitioning into more of an agile development methodology—it's that perfect storm that really promotes Selenium and this second wave.
Josiah Renaudin: Every single team is different and they're going to face different challenges when incorporating these tools. For those who haven't really dabbled in open source tools in the past, what common challenges have you seen that they can expect when trying to bring these tools into their processes?
David Dang: Some companies go through what we call a technical shock. A lot of the packaged tools, don't get me wrong, there are places for package tools. Your technology portfolio is still heavy on client server, on mainframe, even packages like ERP or CRM, you’re still going to have to rely on the packaged tools that are out there to help you support those technologies. There are places for the packaged tool.
Companies that move from packaged tools into the open source world, what they typically have is, what I call, a technology shock. That technology shock is based on two things: Whoever is doing the automation is going to have to be even more technical than the person using packaged tools. The reason for that is, now you are really doing pure coding versus, before you might be able to do some recording playback. You might be able to adjust some of the script. Now you are actually doing coding, pure coding. From a technology standpoint, the automation specialist or automation engineer has to be a lot more technical. That's the first thing that a company realizes. They need to re-choose their resources to be a lot more technical.
The second aspect of it is, Selenium and other open source tools are really good. Some of them are really mature. Even as mature as it is, it's still not fully featured. What I mean by that is, let's say I want a report done in certain ways. I want a certain feature-base. That feature-base might or might not have been developed already. Open source relies on the community to create those feature-bases. If you are working with Python, for example, and you want to do something fancy, someone might not have created that for python yet. You might have to be the one to code that up, so called. There are some technological differences, or challenges, that you have to overcome. Even automating with WebDriver using Java, which is one of the more mature frameworks out there with Selenium, there are times where I'm like, “Wow, I want to do this, and no one has done that before. No one had contributed to that feature base before. I, or my team, have to go out there and actually create something like that.”
We try our best to contribute to the community. That's the reality of open source. You take something, hopefully you give something back.
Josiah Renaudin: You mentioned that there's a certain maturity to these tools out there. While they're not fully featured yet, they do have a certain sophistication. Let's say you're incorporating these tools into your testing team. Will testers have to learn a healthy number of new skills in order to properly take advantage of open source test automation tools? Will they have to go through a long learning process, during that technology shock stage you were mentioning, in order to properly use what's being instituted?
David Dang: It depend on the teams, and I work with multiple teams. Some teams, the transition is not too bad. They already come from a very technical background and are able to transition relatively ease. However, I have worked with teams where they are so used to using the package feature-base that to go out there and actually code up something from scratch, so called, it's a little bit more challenging. A perfect example I can give you is, if you go from a package to, let's say, Selenium web driver and you're using Java with Eclipse as the IDE. There is the aspect of learning Java, if you don't know Java already. There's the aspect of learning the IDE, Eclipse. Eclipse has so many features out there that we'll probably never use. You've got to figure out what you need to use and all that stuff. Then, of course, you have to learn about all the supporting framework and packages that you can utilize. For example, if I want to manage my tests, I need test NG. If I want to manage my repository, I need Maven. If I want to later on integrate it with Jenkins, for execution, I need Surefire.
All this stuff is not in a manual and say, do A, B, and C. It's kind of a learning process through asking questions and...Some companies transition it really smoothly, but a lot of them have to go through this technological shock to realize that “I can make it successful.” However, I do need to rethink my strategy on how best to put it together.
Josiah Renaudin: Of course, if possible, you do want to either shorten or avoid that period of technological shock. What are some of the key elements of the open source mindset that you plan on covering in your keynote that get people prepared to accept open source tools into their team?
David Dang: It's a great question. At the end of the day, it really comes down to three things. It comes down to people, process, and planning. No matter where we go, it comes back to that. From a planning perspective, plan on a big learning curve at the beginning. What I mean by that is, you can take Selenium training, you can take Java training, you can take all this stuff. That's additional time from a planning perspective on planning for the process. The other one is from a process standpoint. Even though it's free tools, you still need to plan for your automation from a process standpoint. What I mean by that is, it's still “a tool.” If you don't have the right automation process in place, and you give it to five people to automate, you will get five very different results.
From a process standpoint, you still have to plan out your framework. How you're going to approach automation. Where is the data stored? All that stuff has to be in place so that you will have the re-usability from test automation. Automation is not effective if you are doing it one time. Automation is effective if you can somehow reuse the asset that you built, that you can expand on later on, or reuse later on.
From a resource standpoint, we talked about this already, you really need to make sure that your resources are able to adapt to this more technical role. I have worked with people where they were really good working with the packaged tools, but when they move to open source, they're lost. Some of them might be only lost for a couple months, and then they got it. Some of them, they're lost for a long time. Some of them get it after a week or two. It's that open mindset of saying, “I have to somewhat unlearn some of this stuff and relearn some of this stuff.”
Josiah Renaudin: A lot of these different answers we've been talking about, a lot of this depends on the personality, the makeup of the team, who you're working with. I think I know the answer to this, but I still want to ask it. Are open source test automation tools the right choice for every software testing team, or is it really similar to something like agile, where it's dependent on the makeup of that team and what's being developed?
David Dang: Absolutely. It's really depending on a lot of things. First of all, it depends on your technology staff. If your technology staff is not heavily on browser base...open source is tough. If I need to automate on a client-server app, the chance of it working on an open source tool is actually really small. From that regard, you've got to look from that. The other thing is, the cost for you to transition. You hear the saying, "There's no such thing as a free ride." You pay money to buy a package tool. You're paying for licenses, you're paying for the tools. You're saving on some of the learning and some of the extra development that you have to do.
Even though Selenium, or open source, is free, there is somewhat of a bigger learning curve. Instead of paying for the tools, you're going to have to pay for the learning curve. You have to really decide if that's worth it. What are applications trying to automate? What is the benefit of automating that? You hear this a million times. One of the common mistakes is, we have open source tools, they’re free. Let's go automate as much as you can, but what is as much as you can? Of course, not 100 percent. We want to strive for 100 percent, but it's too expensive to automate 100 percent. What is that percentage that you want to target? That's another area. What we typically recommend is, if you are going to go down to open source, because right now Selenium is the buzz word. If you mention the word Selenium, you get everybody's heads perk up. Wow, Selenium, cool.
You really want to go through either an internal assessment, or at least a quick cost-benefit analysis to say, is it worth going down that road? The reason so many companies actually jump on this second wave is because it is worth it. Knowing it's worth it and knowing what it costs is really important for you to have a successful project.
Josiah Renaudin: To put a bit of a cherry on top of the interview, more than anything, what central message do you want to leave with your keynote audience at STAREAST 2016?
David Dang: Open source is awesome.
Josiah Renaudin: That's a good message.
David Dang: I've been doing automation for a long time. Open source really gets me excited for a lot of reasons. Software development, as a whole, is moving more and more toward open source. Not just test automation, but software development as a whole. I really like the idea of having your ideas being shared and building out features that everyone can use. I really like that idea. Another thing that I really like about open source is, the technology to support newer technology comes up.
It seems the communities are a lot more excited to support those new technology. Every month or so, we have a new version of Firefox. On a purchase tool-set wise, it might take them three months to say, we support this version now. I have seen where after a Firefox upgrade, three or four days later we have support for it. Then, of course, mobile. I do so much with mobile right now. Mobile is incredible. I just love having the open source world trying to solve that problem. That's a really tough nut to crack, with mobile automation. The open source world is trying really hard to solve that problem. I like that. I like that whole collaborative process, trying to solve an issue together. That's why the central theme is, open source is awesome, but there are little things that you have to consider.
Josiah Renaudin: Open source is awesome maybe should just be the new name of your keynote. I think it's right to the point, very direct, gets the message right across. David, thank you very much for all the insight. I appreciate you talking with me today. I am looking forward to hearing your full discussion at STAREAST 2016.
David Dang: No problem. Thank you for your time, man.
For more than seventeen years, David Dang has been a leader in the test automation industry. As VP of automated solutions for Greensboro, NC-based Zenergy Technologies, David spearheads the development of advanced frameworks that emphasize reusability and reduce maintenance efforts. He is an expert in all major commercial automation tools as well as open source tools such as Selenium and Jenkins. On the mobile front, David uses advanced concepts to design optimal frameworks using mobile automation toolsets including Perfecto and Appium. In addition to his high-level consulting engagements for Zenergy’s clients, David is in high demand as a presenter at major software quality assurance and testing conferences. Read more about David and Zenergy at zenergytechnologies.com.
