An Automation Panel Part 3: Getting Started with Automation

On Monday, January 15, 2018, PQA’s Director of Quality, Mike Hrycyk, brought together a group of PQA testers to form an Automation Panel.

If you’re looking to try your hand at Automation, or if you are interested in learning what coding or scripting language should you know, which Automation tool should you learn, or where you should go for more Automation help, our Panelists will help you answer all these questions in Part 3: Getting Started with Automation. This is the third and final instalment of our Automation Panel roundtable.

Before reading this transcription, be sure to read Part 1: What is the Role of Automation in the Testing World? and Part 2: Record and Playback and a Tester’s Path to Automation.

We hope you’ve enjoyed learning about Automation as much as our testers have enjoyed sharing their experiences and expertise with you.

 

MEET OUR PANELISTS

Mike Hrycyk, Director of Quality: Currently the Director of Quality, Mike has been in the world of quality since he first did user acceptance testing 18 years ago. He has survived all of the different levels and a wide spectrum of technologies and environments to become the quality dynamo that he is today.

Nathaniel (Nat) Couture, VP of Professional Services: Nat has over 15 years of experience in leadership roles in the technology sector. He possesses a solid foundation of technical skills and capabilities in product development including embedded systems, software development and quality assurance.

John McLaughlin, Senior Automation Consultant: John is a Senior Automation Consultant with more than 12 years of experience in software testing and test Automation. Coming from a background in Computer Science, John has designed frameworks and automated testing strategies for a number of software projects while providing training on test Automation and its various toolsets.

Jim Peers, QA Practitioner: As a QA Practitioner, Jim comes with a background of more than 16 years of experience in software development and testing in multiple industry verticals. After working in the scientific research realm for a number of years, Jim moved into software development, holding roles as a tester, test architect, developer, team lead, project manager, and product manager.

Benoit (Ben) Poudrier, Senior Automation Specialist: Ben is an Automation Specialist who has performed manual, functional, automated and performance testing, in addition to building regression testing suites for several clients. While training many people on Ranorex Automation, he has also designed and implemented various Automation frameworks while working at PQA.

Jordan Coughlan, Automation Software Tester: Jordan is a recent graduate from the University of New Brunswick with a Bachelor’s degree in Computer Science. As a member of the Advanced Solutions Team, he has contributed to a variety of projects, taking on different roles as an Automation, performance, and security tester.

 

PART 3: GETTING STARTED WITH AUTOMATION

Mike: Some of the people who are reading this are definitely manual testers and they’re looking at Automation and are afraid. So, I’m going to start with a few questions based around that.

Which language should you know if you’re going to go into Automation?

Jim: Python. It’s really easy to learn, but the great thing about it is that once you’ve learned it, it can be quite powerful. You can drive testing suites through things like Django and that kind of framework, once you get quite adept at using Python. Python is a very good entry-level language and I would definitely recommend it for testers.

Mike: Correct me if I’m wrong, but I had understood that Python doesn’t really include objects in the same way that Java and C# do.

Jim: It actually does. Python became object-oriented a few years ago, so you can even create objects using Python.

John: The language that I hear the most, as being important and probably the one that I would recommend folks should know, is Java. Straight C# is good too, but I don’t think it’s as widely used as Java. I like Python too. I would use it for the process of Automation; to automate a task. Java is widely used for a lot of different things, so we can make use of the different libraries like TestNG to do a lot of the reporting, or the legwork. Python – you probably can find packages. Something that I would consider about Python is that, compared to C# or Java, it is relatively new to the object-oriented style. It almost feels like they pushed the object-oriented concept into Python after the fact, whereas a language like Java was built with objects in mind. I think something like that would be a language or a concept that would stand up over time versus Python. I think that Python is going to go through phases, even now, over time. The concept you learn today will not be the same as the concept you learn tomorrow. Java is reliable, widely used, and there’s lots of support out there.

Ben: I do agree. Over the years, working with a lot of different clients and a lot of different Automation tools, the one that comes up the most is probably Java. I primarily come from a C# and C++ background, and I find that, thankfully, Java is very similar to C# so it’s making the transition a little easier for me. I have not learned Python yet, but that is on my bucket list of languages to learn. I look forward to it because I think with certain languages you can cross the systems border, so that you can go to Windows Linux and to Mac OX. Whereas with Microsoft languages, it’s a little harder, but it can still be done.

Mike: What about starting with scripting languages? At a prior company where I worked, I had a group of one Automation guy and seven manual testers and we looked at bringing in Automation. I went to the seminar where the people did this thing, and we tried it. Within two or three months, I had implemented my team using Nightwatch. The way that we worked it was that the Automater provided mentorship where necessary. He produced functions that could be called that did the more complicated things. And then, I had my teams learning enough scripting that they could cobble together the Automation that they needed to do. They started with a knowledge point of about zero and a couple of them, within a month, were writing their own functions and writing scripts because that was a path for them. The others were still putting together regression scripts that worked. They were able to put together Automation that was of value, and so it became a path.

What do we think about that as an accessibility map for manual testers into the Automation world?

Nat: To me, whether it is scripts or full-blown programming language, you’re talking about coding proficiency of some sort. It’s about the ability of someone to comprehend how code is executed, how you translate, and an English description of a problem into a language of choice. It is programming. Even the concept of making a call and passing parameters into that function call is a concept that you’re going to learn. Whatever first language you learn, that concept applies. So, if you take Java or a scripting language, I think the idea is that those initial concepts will apply to most programming languages. And then it becomes, okay, here are the tools we’re going to use in our company; I’m going to become proficient in the programming language that it speaks, and then you become familiar with the specific syntax. I think what you want to teach is how the programming works, and the basic cornerstones of it. Then you can basically carry that forward, whether it’s a scripting language or a more complex programming language.

John: I agree with Nat, I think. You don’t really learn a specific language with Computer Science, you learn what programming is, what functions are, what logic is and how it works, and all that stuff. So, anyone on this Panel could go to any tool, or any language probably, and pick it up relatively quickly. Now, if you had a team, like you’re describing Mike, who understands roughly what a function is with regards to an input and an output, that would seem to me like a good place to start. For someone in testing, that sounds almost like a keyword-driven approach, so you have a library of keywords that you could string together. I can see running into a lot of headaches if we had a keyword-driven approach. The team works with functions; they’re essentially working with a whole bunch of black boxes that they don’t know what the internals do. The minute something goes wrong, the test Automater, or the team of test Automaters, will have that work dropped back down onto them. I can see it being a painful process at first. But over the long run, as the team develops their understanding of what a function is, of an input and output, and how that all works, I can see there being an accelerated path to becoming an Automater.

Mike: What’s the first Automation tool you should pick and learn?

John: I’d say it depends. If you’re going for one that’s going to be useable right now, Selenium is the popular one that always comes up. And if you’re going into Selenium, there are a number of languages you can pick: Java, C#, Python. Selenium with Java will get you the most bang for your buck. If you’re looking to ease into things, Python is a good starting point. Ruby is brought up as a good one to start with too, but to me, Ruby looks a little more complex than Python. That would be my recommended order; I would go from Python, to Selenium with Java.

Mike: So, would your recommendation be the same if we assume our starting point is someone who is a manual tester by day; whose boss only wants them to do manual testing; and who has talked to someone like me who is trying to coach them to get Automation into their life? I’ve said to more than one person that they should search for something to provide value. Find a little piece of a project in your domain at your workplace, on your own time, put together a little project that will be of some value, and just start using it. People will see the value and will build it up. This doesn’t negate the answer that John gave, but I’ll force Jim to talk here. Jim might recommend going after API testing as a starting point because you can show some value pretty quickly.

Jim: John was absolutely right about learning Python and Selenium. Selenium is very good for testers to learn, basically how to learn HTML and Expat and CSS and all those really valuable things we really need to understand when we’re testing. I don’t want to discredit any of that. At the API level, there are some very good tools. They’re all supported by some tutorial material and they’re kind of fun to use. SoapUI is a free tool. You can get a pro edition that does a lot more stuff. It’s a great start to learning how to do API testing. Postman as well, which is my API testing tool of choice. I’m using it currently on a project with a client. It’s well supported by videos, tutorials, and lots of how-to material. When you learn how to test in API, you sort of get into the guts of how an application works and you can do some very quick testing with it. It’s quite useful. It also does it in a data-driven way, in which you build up a data and have it run through iterations of those data to test all sorts of edge cases and things too. It’s quite fun to use and I would definitely recommend it.

John: An API path is a good point. When talking about the keyword library to learn concepts of functions and so on – API testing is the same thing. You’re testing functions inputs and outputs. Provided your team can recognize that that’s what is happening behind the scenes, it would be a good starting point for a new Automater to understand the concept of API testing, and then relate that back to functional style.

Mike: Indeed. I’ve even gone a step further than that. SoapUI, without the paid version, does not link into Automation as well, or at least it isn’t used to. But, I had one person who went through this path. He understood code better because, prior to jumping him into Nightwatch, I had given him SoapUI, told him to starting testing with it, and gave him a bunch of calls to make. A newbie looks at a call that is just a call that you’re going to put into a browser URL line, and run it. But then I told him that he needed to do something else and I asked him to adjust that call. He started using the tool SoapUI to help build the call for him, then he ran it and started to realize that he could modify it on his own, and it’s just faster. It’s an introduction to the idea that code isn’t so very scary; that code is something you can figure out.

Jim: Exactly. You can do exploratory API testing using a tool like that as well. You can mess around with your calls and see what happens – the same way you’d do exploratory testing at BUI.

Ben: Since we’re talking about API, I’m going to talk about UI. With UI Automation, there are things that people need to become a lot more familiar with. They need to know how a UI is coded, how the coding for HTML and whatnot works, and they need to really have a look at how that is made to get a better understanding of how to build yourself an upper X path or a CSS path. Those are the things that you’ll be using in most cases in order to Automate your UI. Building a proper X path could be the difference between waiting five seconds, or having to wait 30 seconds because you’ve put in too much extra search in your X path.

Mike: I also find that requiring Automaters to learn how to find their own X path, and to maintain those in their Automation, is a really good way to teach testers to be willing to go to developers and say, “Why can’t we have static? Why do we always have to have things that change?” But, that’s sort of a side topic.

Just one more question that someone requested I ask of the panel. She’s self-learning; she’s looking at Python and some other stuff, and one of the things that she’s discovered is that a lot of the content out there on the interweb is out-dated. She’s trying to get started and get her first Selenium install so it can load up Firefox, but a lot of the instructions out there are out-dated. This makes sense because we live in a technological world. Do you have any tools or tricks to help people to understand whether some tutorial or help they’ve found is ancient, or whether it is new and useful?

Ben: I would ask somebody that does Automation, or one of your peers that does that kind of work. If she knows somebody that does that type of work and they’re willing to help her out, that’s a possibility. I feel that if I have a set of skills and I can help out somebody else in the company, I would want to share those to help them learn new things.

Mike: Well, we know whose email I’m giving out!

John: One strategy that would be interesting to me is to understand how the out-dated way worked and then understand why the new way works, and then try to figure out why the new way exists in the first place. That would maybe help with the understanding of why programming changes are made, and why design changes are made. It will also help to learn how to debug and roll with the changes when they come – because they will come eventually. The earlier you get into it, the more it will help you down the line.

Mike: I think what you’re saying is absolutely true, John. I think with this person the problem was earlier in the step. It was installing Selenium properly and getting it to work. If I go and find instructions on how to go do something in Windows 7, but I am using Windows 10, you’d hope that the instructions would say that. Everyone in this chat is experienced enough to look at the Windows 7 instructions, and then figure out how to do it on Windows 10. There are definitely challenges in getting programs installed and working.

John: It all comes back to the object. When you’re doing anything on the computer, you’re just manipulating some combination of objects. So, if you look at the old way of doing something and realize what the object is that they’re changing, then you can easily, more often than not, relate that to current times. You can understand what objects you have available to you today and how you can make those perform the task that you are trying to get it to do using old knowledge.

Mike: Yeah, for sure.

Jim: I find that, if I’m running some Automation code, very often I find answers that I need, somewhere like Stack Overflow where I can ask a specific question and get a very specific answer with a bunch of opinions as well. But also sample code methods that I can use and adapt to my needs. I can’t say enough about Stack Overflow. I know that my developer friends use it pretty heavily. We’re all sort of, as developers, lazy people. It’s a quick way to get what you need.

Mike: I think there is one more point to drive home around that. I understand that when you’re new, it’s daunting and scary to go onto Stack Overflow for a couple of reasons. One of the big ones is that you might not even know how to ask your question in a way that doesn’t make you feel like you’re an idiot. Stack Overflow is a moderately nice community with a lot of people who really do want to give back, just like Ben does, and you can ask a question that makes you sound like a newbie. You might get someone who answers you who used to be a newbie six months ago and they’re happy because there’s now a question they can answer. They have a perspective that relates to you better; they can help you faster than if, say John or Nat, try to help you. Do reach out and use the community.

Nat: I think, in general, Automation is never going to get rid of manual testing, or the role that manual testers have on a project. Manual testers are providing a different viewpoint and so, what your traditional Automater brings to the table is a different skillset entirely. Marrying the two is really what gives you the outcome that you’re looking for. I don’t think it’s a case of you have one and therefore, you don’t need the other. Both are definitely required. And for those trying to learn Automation, using the online forums is helpful. Having access to folks like John and Ben within PQA, and other people who can share their knowledge and are happy to do so, is definitely a good thing as well. Sharing more of that, having webinars like this, and maybe even more technical sessions, will help people understand what it is that they’re trying to accomplish, and will get us where we’re going.

Mike: Thank you so much everyone.

Jim: I would echo what Nat just said in that manual testing is never going to lose its importance. The attitude behind testing, and the exploratory sense, are always going to be super important and testers and developers are now converging a little bit more to write more intelligent Automation – stuff that really tests the system. I see it as a great way forward.

Ben: I do believe that if you’re a manual tester, and you can undertake and use a little bit of Automation, you can then use that knowledge and that skillset to do your manual testing – maybe more easily and faster. It really supplements your work and it makes your life easier. I understand that not everybody has the technical mindset, especially with the coding aspect, but if you reach out to other testing communities online who have that knowledge, I’m sure that some will be more than happy to help.

Jordan: Automation isn’t so much about coding as it is about organizing. That’s an important distinction, I think. When you’re just starting Automation, you need to learn. You’re not doing strict development work; you spend a lot of time managing repositories and that sort of thing. That’s just something to keep in mind.

John: I think Jordan’s point is a really good one. That’s a huge part of it. I always chuckle when I hear people say Manual or Automater tester; I’ve probably said it myself over time, but both are just testers. Some have different skillsets. To think of a world where manual testing doesn’t exist, I don’t really see it. I think one needs the other, essentially to survive. I always get excited talking about this stuff, doing it, or planning it, because I see it as a big puzzle, or a big game. We have different tools available to us to play the game and to see what we can find. A happy side effect to that is that we help our teams out along the way. Going back to the beginning, I don’t see an automated or manual tester; we’re all testers with different skillsets, and I don’t see that changing anytime soon.