266: Automation Journey and TestNG with Rex Jones II

Hit it.

Welcome to the Test Talks podcast, the place to go to geek out on software testing. And now your host whose mission is to help you succeed with test automation, Joe Colantonio.

Hey, it's Joe. And welcome to another episode of what's gonna be the Test Guild Automation Podcast. In this episode we'll be test talking with Rex Jones about his automation testing journey. Rex shares some hacks that he's found that's helped him with his testing career as well as his thoughts on the Java testing framework Testng. You don't want to miss this episode. Check it out. And if you could do me a big favor, I'm starting to plan the fourth annual Automation Guild online conference. An online conference dedicated 100% to helping you succeed with creating automation Awesomeness. It's the largest automation testing conference online in the world and I want to know what you are struggling with. So if you can head over to GuildConferences.com and fill out the survey, it should take you less than a minute. It would be a big help. This is what I call an attendee led event and basically you get to decide what topics and what speakers you want to see. Need your help? Guild conferences.com so if you haven't filled it out already, if you can head on over, I'd really appreciate it and thank you for your automation awesomeness.

Test Talks is sponsored by the fantastic folks at Sauce Labs, the cloud based automated testing platform that eliminates the need to maintain your own selenium grid and test infrastructure. Try it for free today. Visit testtalks.com and click on the sign up now link under the homepage sponsor section.

Hey Rex, welcome to the show.

Thanks Joe. Good talking to you.

Awesome. It's great to have you on the show. I wanted to have you on the show for a while, so today I thought we'd talk about testng your books. You've written a few books on automation as well as automation testing in general. But before we get into it, I think you have a pretty cool story of how you actually got into automation. That's pretty motivational. So can you just tell us a little bit more about Rex? How did you get into Q qa? How did you get into automation? What's your story? What's your backstory with it?

Yes. Well, I graduated from DeVry with Bachelor's in Computer Science and my first job in QA was interesting because before the job I never heard of qa, had no idea what QA was and the strategy for the company I worked for. They start you out as QA to get you familiar with the application, then start your app with development tasks. My background is development, but at that time I was new to the industry of it, and I would see the developers come to work, work eight hours, go back home and work some more. And I was new, like I said, and I was not used to working that many hours. So when it came time for my evaluation, the manager said, hey, Rex, how's it going? I told him, it's going good. And he said, are you ready for development task? And I told him, know what? This QA job I like qa. Can I stay a little bit longer? And once I committed to qa, that's when I became more interested in qa. I started going to seminars, webinars, local user group meetings, and that's when I came across Paul Grisafi meeting. And at that moment when I committed to qa, I started learning so much about QA that I never turned back from qa. Now, if we have more time, I can share my story. How I got into automation, how I was scared of automation. And that fear also led me to learning automation. And also, more importantly, I landed my first job in automation without an interview. And I think that story may help people who are beginners in automation.

I guess the first question before we get into that is, you know, you want to be a developer originally, so what made you be drawn to qa? Like, what made you also say, well, wait a minute, this is actually where I want to be? What was the actual thing that made it ring for you?

It's funny, Joe, because it's different from how I work now, but when I saw developers working so many hours in qa, that kind of made me not want to get into development, not realizing as time went on, I worked those same hours myself. So when my evaluation came, I really wanted to stall time. But that's what led me to get into qa. Because reading the books, watching videos I saw, it was so much more to QA than what I was doing on my job. So the extra education I got outside of my job led me to love in qa. And now I'm still here in QA automation.

Is that one of the reasons why you started writing some books? Like, I'm curious to know how you got into automation then at that point, because you have a few books on Amazon on getting started with automation and Java and Selenium. So what made you then make the leap from QA and say, okay, Also there's this automation piece to testing that.

I can learn more about what led me to get into automation. I was sitting with a developer at my job and he pushed a button and I saw the same steps I was doing, mainly executing without no one doing anything. And I said, what is this you doing? What is this? He said, this is qtp. And I asked him what is qtp? And he said, it's Quick Test Professional. I looked it up and that's when I came across a user group called DFWMUG Dallas Fort Worth Mercury User Group I attended, which is now also DFW qaa. And that's when I saw Paul Grisopi giving a meeting and I became so excited with automation. But here's the problem. I was around other QA people who were telling me things like automation is hard. You don't want to do automation because Programming, programming, programming. Although I had development background, I let the words sink into my mind and I started thinking. It really was hard. But on one of my projects they was thinking about hiring somebody for automation job who was at our company for opportunity. And when they tried to put her or thought about putting her on an automation project. Joe. She had no automation experience, but they were still considering putting her on an automation project. And that made me scared because I like to be prepared for whatever situation I come into. When I saw that happen, I started practicing automation, reading books, watching videos to make sure I was prepared for any automation opportunity. And that led me to writing books eventually because when I was reading about automation, I came across a book. Joe. The book was very small, it had misspelled words and to myself I said, I can do this now. This was years after I had experience, but I was still reading about automation, qtp. And that led me to write my first book about qtp. And from that point on I continue writing books because I love to share knowledge.

That's awesome. And for some reason the QTP gets a bad rap. But I know a lot of people that turn out to be really good automation engineers usually start off, they started off with QTP and then they expanded into open source tools. So what made you change from QTP or do you still use QTP or did you go strictly to Selenium at that point?

It's been years since I used qtp, but I changed from QTP to Selenium because it was open source and it was so popular at that time. So from that point I started using Selenium and I wasn't sure which language to use. So I did research and I realized from my research that Java was The most popular language. So I started learning Java and Selenium.

I think you mentioned you were able to get a job without without an interview with automation is how did that come about?

Yes, yes, you're right. Well that happened at one of my companies I was at as a consultant on the project and when people come in, that was new. I had no problem just delivering knowledge transfers. And one particular time some automation people came in and I was sharing knowledge with them and it would come back from time to time and ask questions. And one time they came back, they saw me writing some scripts for QTP and they had no idea I had new QTP and I was executing my scripts and they said, hey, you know qtp? I said, yeah, sure, I know it. Well, about two months later they were looking for a QTP person to come in and I understand their manager, she said she liked me, but I had no experience. But Joe, what happened? About three months later we had a reorg in my company and on the reorg I saw my name under the automation team group and it did not interview me. It was all because they saw me writing my own QTP scripts and they hired me for that position without an interview. Now I believe that story will help people because some people, they may not get a job without an interview. But for people who worry about how can they get a job without experience, I recommend starting where you at. Start writing your own scripts on your own, during lunchtime, before work, whenever you can. Keep on practicing and get that experience. And then once you are good enough or effective, start searching for jobs in automation at your company. If not, maybe you can try going somewhere else. So I recommend starting where you are.

Right, that's a great point. I don't know why more people don't do it though. 20 years ago when I started, I started a job as a QA person and I noticed they had software called Loadrunner and Windrunner but no one was doing anything with it. So I just started playing with it and all of a sudden I became the automation guy that did all the automation work, you know, but I didn't really intend for that to happen. I just took the initiative. So do you know why sometimes people may be, especially now with all these open source tools, why there would be someone that may want to expand their tool set or their skills, but they don't take that next step.

I think some people don't take the next step because of fear. Some people and some people not sure because what I came across with people at my job and other places like User groups, they're concerned that if I learn this tool, whatever it is, who would hire me with no experience. So by them not knowing how they would get hired without experience, it prevents some people from even taking that first step of trying to learn it. And some people, when they finally learn the tool or whatever the case may be, they're trying to learn. If they don't keep on practicing, if they don't use it, they lose it and they know they have lost some of the information, so they stop trying.

That's a good point. Once again, I didn't have a college degree and just because I had those skills at that time that were highly desirable, I was able to get jobs fairly easily. So yeah, it's a good point that you make.

And like I said, that was my story also because I was excited about automation. I wanted to learn it. But when I got around other people who were scared of it, it started making me nervous of learning. But I had to, I had to learn it because I knew it was the next step in our industry.

So once again, back in the day people were kind of nervous about automation, but now it seems like kind of the norm. Do you still see that with people, people nervous about automation or not thinking it's part of testing or they don't consider it, you know, a necessary skill?

Yes, I still come across people who think automation is not as important. It's not important. They still think it's nervous. Some people, I do. And some people are still scared of it because the I believe Joe, the program import makes people nervous. The program import, it frightens a lot of people from even taking that next step of trying to learn automation. But yes, it still happens. But also what happens a lot of times in companies, people who are manual testers are getting training on automation, begin training because people at the job know automation and they train people without experience. The problem with a lot of places, the people who get that experience, once the training is over, they don't have the opportunity to keep practicing because of work schedules. They may not go home and continue practicing and learning. But yes, it happens. But I believe manual testing, will it be around forever, but automation is the future.

Yeah, absolutely. I mean testing will always be around. Automation would be a piece of it for sure. And it's not just I use it, not even just for testing, I use it for all kinds of different activities. So I definitely agree with you. Have you seen a more push then for automation as we go towards DevOps now is the buzzword?

Yes, I see a handy push towards Automation also from people who are not testers, people just in the company when they hear about DevOps. We have developers talking to test managers about automation. Automation because they know it helps with continuing integration and continuous development. Deployment, Absolutely.

So Rex, you said a lot of times people are afraid and I know you have some books, I think you have absolute beginner Java for Selenium. But is there any concepts you've noticed that fundamentally people struggle with and if once they get over that, that hurdle, they seem to really accelerate their learning?

No, I think it's the beginning concepts people struggle with because sometimes what I've noticed, people who are trainers, sometimes it's difficult to go back to the bottom stages of programming with variables, operators. And what I've seen a lot of times when I've been a part of training systems, I'm thinking about one, one of the most recent wars, the trainer. Want to start with the, with the catchy topics, frameworks because people love. They like hearing about frameworks and what I was trying to explain. Let's start with the beginning steps of variables, operators, data types and Joe, we didn't do that. We started with frameworks and a lot of people who was interested became not interested because they were confused on what was going on.

It's almost like the curse of knowledge. A lot of times people that have just a little bit think, oh, everyone knows that. But that is critical. Like you said the basics, right?

Know what you said, the exact words that I said to the trainer. I said, we don't want out. I said we don't want to have the curse of knowledge because we know variables. But people starting out, they don't know these beginning concepts. Let's start at the beginning. But since we had a group of people who knew automation, did not know automation, it was difficult from his point of view and I understand what he was saying. It was difficult to start at the beginning because we had so many people. He felt like starting at the beginning will make the people with experience boy forward and not want to continue learning what we had to offer. So I understand it. But there were people who was super confused.

So Rex, I think what's curious though is you did choose Java and I understand why because it is the most popular. If you Google it, you'll find an answer. But for people that are beginning automation, do you usually suggest they start with Java or do you think it matters? Do you think it'd be easier to learn like Python or JavaScript?

That's tough because I may be biased with that because I love Java But I know Python is also a good language to start with because it's more friendlier for people who's beginning into automation. So a lot of people, what I hear nowadays, JavaScript, Python is real good for people who start to learn automation. In fact, when I looked up the, the programming languages, Java was number one. And I believe Python was climbing the ladder very fast.

Absolutely. I guess you can't go wrong as long as you get your job done. But you know, for me, I just love Python. It's just so easy and elegant and Java, I use Java every day, but, you know, we all have what we like, you know.

Oh, okay. So you use Java with Lil. Python.

Yeah, yeah.

Okay. Now there have been people inboxing me, direct messaging me.

Yeah.

Asking me do I have any videos and material on Python.

A lot of people, yeah, it seems like a hot topic. I've spoken to a lot of people that really are into Python. I guess it's like you said, you know, you love Java, someone loves Python, you all get our jobs done. But just, it's just interesting how we all have our own, our own interests, you know?

Yes, yes.

So along those lines, Rex, I think another thing, you know, moving over from QTP to Selenium, I think for people have been a hurdle. And I know sometimes people complain that Junit really wasn't built for automation testing. And I noticed you started writing a lot of material, you have a new training out on Testng. So could you just tell me a little bit? What, what is Testng? Why we choose that over junit? Why you prefer it over junit? If you do just a little bit more like at a high level. What is Testng?

I guess the first question, Testng is a test framework for Java and it's very similar to junit. In fact, it was influenced by Junit. The catch, it added more features for testing for people who are automation engineers. Junit is a unit testing framework. But Testng, which is test next generation, is for automation engineers who want to go beyond unit testing and do regression acceptance and functional testing.

Cool. So any places when someone wouldn't use Testng, like if they are using Java already, is it just a simple install and it can get up and running without impacting anyone else?

Exactly. It's a simple installation. Whatever IDE they're using for Eclipse, Intellij and NetBeans, they can install it and start using it. So if anyone is familiar with junit, they can easily learn Testng.

Now you said it was made for testing, Obviously it's called Testng So are there any features specifically that you think makes it really strong compared to Junit for automation?

Wow. I believe the soft asserts the data driven testing and dependency testing separates testng from the other frameworks and that's one reason why it was created. And I believe his name is Cedric and Hani Honey. They were the writers of the book that I purchased. It was a flaw. Well, I don't want to say flaw, but maybe it was something that was missing from Junit that made them want to go and create testng because they notice it's more to testing than just unit testing.

What is dependency testing then? How does testng help with dependency testing?

It helps with dependency testing for methods that depend on other methods. Such as if you want to integrate signing out and signing into an application, you can make the sign out method depend on the sign in method. So if the sign in method fails, the sign out method will get skipped. What happens a lot of times when a method depends on another method? If the previous method fails, you may create a cascade of failures behind that and that leads to misleading test results. So for example, if I have a method to open Chrome browser, if open Chrome fails, the remaining test methods should get skipped. But what happens if you do not have a dependency method? It will fail the remaining test methods, which is not correct. So when you depend on it, it will automatically skip the remaining steps because they were not executed.

Nice. So does it help also produce better reports then when that happens so someone can look at it and get a better idea what happened during that test run?

Absolutely. I believe it very good for test results because it's accurate. If I have a test result to have 7 failures but the first method failed, why did the other 6 methods fail but it did not fail, they were never executed.

Okay, so if you have a lot of tests, it seems like it would really help you pinpoint quicker what it is rather than getting stuck in a maze of all other things that aren't really relevant to what happened.

Yes. So that's one feature that's real good. And I mentioned in the course that I did for Test Automation University, that is a section in the book that I read, I believe it's dependent code, something like that, where there are some developers, the testing community, they are strongly opposed to dependencies because they feel like if you have a method that depends on another method, it makes it hard to execute that method in isolation. And it's funny because when I created that course for Test Automation University, about a week or two later, one of my former developer Friends co workers sent me a message asking me about a similar situation. The problem, they use C Sharp. So that was the catch. He used C Sharp and testng is not available for C Sharp.

So besides that feature, which sounds like a huge time saver is. You mentioned data driving test. How does it help you?

Data drive test there's an annotation called data provider and data provider is responsible for containing the data sets, the data that you want to send to a test strip. Once you use the data provider annotation, you can connect it to the test method using data attributes that provider attribute. And once it connects, you can execute the same test script with different data sets, also with different data types.

And I think you also mentioned that assertions, does it help anything with assertions? I know you know we have ham crest matchers that really helpful but does testng add any extra assertions that can help people when they're doing automation?

Yes, I believe the fault asserts helps a whole lot. With test engine for example, we may have a test method that have different verifications but with the hard assert once one verification fails, it will bypass the remaining test verifications in that test method. But with a soft assert it will fail. The verification is supposed to fail, but continue executing the remaining verifications in that test method, which also leads to a more accurate report.

So it just sounds like similar with the method that if it fails, it's able, like you said, just to keep track better of when something fails, what really failed rather than, you know, going down a maze. So that's exactly nice.

Exactly. Because we may have many, we may have a few verifications in one test method, but if the first one fails with the hard assert, how do we know if the remaining verifications failed or passed? Because with a hard assert that hard assert will fail like it's supposed to. Then we'll bypass the remaining ones in that test method and go to the next. But a soft assert will keep on executing and give you a more accurate report. Now just by hearing that, some people may think okay, I should use a soft assert all the time. Well, that's not the case either because a hard assert is good and a soft assert is good. And I use this example in the course if someone have a situation where the browser does not open, that's a good time to use a hard assert because there's no reason to continue executing your test if you cannot open the browser. So in that case a hard assert is beneficial. In other cases like the one we just mentioned, a soft assert is best to use all Right.

So yeah, that's gonna be my question. I'm like, that doesn't sound like it's always the best practice. But yeah, like if I'm testing an application that requires a patient and I don't have a patient, then it should be hard assertion. But if I do have a patient and has like five fields and one of them is off, but the other three are still valid, then it probably makes sense to do a soft assert because I want to make sure you know what other fields are. Maybe be messed up, not just stop on the first one that doesn't work.

Exactly.

Nice.

That's a perfect example.

So, Rex, also, I know a lot of people struggle with the running test in parallel. I don't know, does testng help with anything? Like we're running the test actually in parallel, or is that not one of the features?

Yes, they do have a feature for running tests in parallel. They call it multi threading. You can also set how many tests you want to run in parallel. So that's another feature that separates testng from other frameworks. The parallel testing.

Very cool. So Rex, if someone wanted to get started with testng, is it like you said, it's just a matter of just a simple install and then they just start using the testng annotations and up and running. There they go.

Exactly. Yes, you can install it into your ide. You can also use a build tool like maven. So there are different ways to install testng, but once they install testng, it will operate very similar to junit.

So if someone is just using junit, do you always recommend that they use testng?

Well, I rec. Yes, I recommend testng, but test junit or any other test framework will work because I believe testng is more powerful and more equipped for people in the automation test field or test industry.

Okay, Rex, before we go, is there one piece of actionable advice you can give someone to help improve their test ng or automation testing efforts in general? And let us know the best way to find or contact you.

Yes, my advice for people in the automation field to continue their education, whether you're a beginner or a seasoned veteran, continue education. Automation Guild is a good place to start. And also Test Automation University has a plenty of courses that you can learn for free. And the best way to contact me is through my email. Rex Jones. Rex Jonesestforsuccess.org that's R E X dot J O N E S at T-E-S dash T the number 4s u c C-E-S dash S S dot org and through LinkedIn at Rex Jones II thank.

You Rex for your automation awesomeness. For links to everything of value we covered in this episode, head on over to testtalks.com 266 and while you're there, make sure to click on that. Sign up for a free trial link under the Exclusive Sponsor section to learn all about Sauce Labs awesome products and services. And as I mentioned, I need your help to help make Automation Guild 2020 a big success. I need to know what you are struggling with with automation so I can find speakers to cover those topics that you want to know about. So just head on over to guild conferences.com fill out that survey. I really would appreciate it. So that's it for this episode of what's going to be the Test Guild Automation Podcast. I'm Joe and my mission is to help you succeed with creating automation awesomeness. As always, test everything and keep the good. Cheers.

Thanks for listening to the Test Talks podcast. Head on over to triple W.TestTalks.com for full show notes, amazing blog articles and other automation awesomeness.