Before the Code First Steps to Automation with Jim Hazen

Five, four, three, two, one.

Drop that.

Welcome to the Test Guild Automation Podcast. We're all getting together to learn more about software testing and automation with your host, Joe Calantonio.

Hey, it's Joe. And welcome to another episode of the Test Guild Automation Podcast. Today we'll be talking with Jim Hazen, all about his new book before the Code, First Steps to Automation and Testing, as well as his upcoming Automation Guild conference session on modeling methods for automation in testing. Jim is a veteran of the software testing trenches and has over 25 years plus of experience testing all kinds of applications. Jim has been involved with the startup of testing groups and multiple companies and has done consultant work for the last 15 plus years. He has helped numerous clients implement tools for functional automation, performance testing and test management. He has also helped thousands of other testers around the world, sharing his knowledge at conferences and in test discussions on various social networks like LinkedIn. You don't want to miss this episode. Check it out and if you haven't already, you definitely want to Register for the 4th Annual Online Conference Automation Guild, an online conference dedicated 100% to helping you succeed with creating end to end full stack automation awesomeness. As I mentioned, Jim will be there with the session Modeling Methods for Automation and Testing where you're going to discover how you can use models to build as a collaborative process between your test developers, users and analysts and tell the different types of models how you can make sure that everyone's on the same page before you actually start creating automation. So you're creating the most effective automation possible. So this really should help your team shift left. This is just one of over 20 sessions that you cannot miss in 2020. Accelerate your automation efforts in the new year. Check it out, head over to GuildConferences.com and register today.

The Test Guild Automation Podcast is sponsored by the fantastic folks at Sauce Labs. Their cloud based test platform helps ensure your favorite mobile apps and websites work flawlessly on every browser, operating system and device. Get a free trial, visit testguild.com forward/source labs and click on the exclusive sponsor section to try it for free for 14 days. Check it out.

Hey Jim, welcome back to the Guild.

Thanks Joe. Good to be back.

Awesome. So last time we spoke it was in episode 94, which I can't believe it's almost four years ago. I think. So what have you been up to since then? I think that was 2016 quite a bit.

Been busy with work and also working on the book and getting it out.

Nice. So Jim, why did you write this book? I Always ask people that take time to write a book because it's not the easiest thing to do. So why now? Why this book?

I saw a gap in the materials out there. A lot of it was the technical books that were talking about the tools specifically and implementation methods. And I think there was a lot of missing information as far as what we really need to do beforehand, do first before we even touch a line of code.

As you mentioned, I've been doing this type of work for a long time and I've been working with automation tools for.

A number of years. So I've learned lessons good and bad. And one of the things I always try and do is design things up front. So I act more as a software developer trying to design the code in the system before I even build it because there's such a high rate of failure of implementations of automation. And I think a lot of it is due to people not doing that front end work. And that's why I wrote the book, to try and bring that forward and let people know here's some things you need to consider before you even start writing your code.

Awesome. I really like about the book is like you said, it starts off from the very beginning before you even start writing code. So that's why I think you named the book really well. And the very first chapter starts off with don't put the cart before the horse issue in automation. Can you just explain that a little bit?

Yeah, well, that goes back to the whole premise of the book is we all tend to just grab a tool and dive in and don't have a plan and any designs of what we're doing, we just grab it and start automating. I mean, that's the first hard lesson I learned years ago is I was working on a project, got a hold of a tool, I just started going for it and within a few months I found that my code was unmaintainable, it was very brittle and I really wasn't testing the things I needed to test correctly. So I had to backtrack and start thinking more what am I doing? Why am I doing it? You know, how am I going to do it, you know, answering those types of questions and that's, you know, I've done through the book is trying to answer those questions.

You did mention just now that a lot of automation did fail in your experience. I see that a lot as well. How do you plan to not fail with the automation testing efforts?

It comes down to where, you know, you're asking these questions, but you're also Talking to other people so you can get their feedback from different groups, so you can get an understanding of what's important to them and where you need to focus nowadays with tools and just automation in general.

Due to.

The automation pyramid, Test automation pyramid, we're looking at different layers of the technology stack that we're going to try and hook tools into and work with. So it causes us to have to use different types of tools, methodologies and the skill sets that go with it. So you know that, that's that piece of it and.

You know, it's.

It'S trying to look at the thing holistically as a whole big picture instead of just from the UI level, which is the classic approach.

It's getting people to do some thinking beforehand and say, do I really need to do this at the UI level or is this better at the API level? Or am I just trying to find out if a SQL trigger got fired off or not? Can I just do a SQL call and put that in the automation code, which is a lot faster?

Absolutely. You actually have a whole chapter, I believe, on the testing pyramid. What do folks need to know about the testing pyramid before they start? Automation is a tester responsible for all the unit test, all the integration tests and all the UI tests. Are they just like, where do they fit into that automation pyramid? What do they need to know about it?

The tester, if they've got the ability, yeah, they can go up and down the stack the pyramid if they want to. But predominantly when Mike Cohen was trying to do with the pyramid and why the base of the at the unit test level so wide is that he's asking the developers to go write their own unit tests to prove out the reliability and stability of the code before we even see it. As a tester, you know, it's, it's what I call trying to eliminate the stupid bugs and, you know, provide two testers better code and better software so that when they're testing it, they're testing it more for the business aspects, the user aspects. When you do performance testing, is it performant and working correctly under load? So try to eliminate a lot of that. Because at the unit test level, a lot of people don't realize is that when you write a unit test, you're writing one to one to the code. And that's, in my opinion, that's why the base is so wide, is that you're going to naturally have more granular tests, but you're going to have more of them. And as you go higher up, they become more and more complex and you don't need as many to do the same type of testing or get the coverage that you may need.

So for a person, you know, a tester.

We need to have programming skills, we have to have knowledge of that. So we're kind of a hybrid between a regular test person and a software developer. Therefore we could sit in that middle layer of the API services testing and the UI level. But also too, we can get down into some of the lower levels, not exactly the code, but within different parts of the system to do our work.

So Jim, also in chapter two, you've been doing automation for a while as I have as well. Just curious to know, are there some myths around automation that you still hear about today?

Yeah, I still hear people saying, well, let's just do 100% automation, we'll automate everything. Or.

Look, just go start automating and we'll figure out the test later. Or someone will come in and say, well, you can do this as a part time job. And those are things I highlight. There is, you know, some of the myths that have been around. Some of the newer ones I've heard is codeless tools. And I'm not slamming codeless tools. I mean they are pretty good, they do have a lot of good functionality. Just the way some things are sold and marketed that I have a concern with because it can set false expectations with people outside of our area.

You mentioned codeless and I've been hearing more and more about Codeless now, but it's like a little different than was when I was hearing about it in the early now, in the late 90s, early 2000s. Do you see any improvement in the COLA solutions or these new ides that are coming in that, you know, use. Let's just call it AI or machine learning for the sake of argument. What are your thoughts around that?

Yes, I have. In the last five to seven years, since I started hearing about codeless and scriptless tools, they've improved a lot. And part of this is due to the machine learning and AI capabilities.

There's a tool out there right now. I don't want to name it, but when I saw it at a conference last fall, the demonstration of it, my jaw dropped. I was like, this is incredible. And when the way they explained that it worked and how it would build up its own knowledge base of how to interact with the system and then when you rerun things, it uses that so it has learned and then you can tune it to say, well, yeah, you really want to concentrate on this or just Ignore this and move on. So the capability of that tool to just go in and.

Do its work after it's gone a few rounds and learned and then to continue doing that, I mean, that was really impressive.

I guess this goes into also educating management. Back in the day people would just say, okay, automation is going to replace manual testers. And now I'm hearing AI is going to replace automated testers. So what are some things we need to do in order to educate management to give them realistic expectations? So when they do go to a conference and they see a session like you saw, they don't come out thinking, oh, this is easy, I'll get an AI tool now. And I don't want like fire everyone and not worry about anything.

That's a good question. And my answer to that is like anything within testing, you've got to go and talk to them and find out what their perceptions are, what their expectations are. And then based on that, you can make changes in that thinking to help keep you from getting painted into a corner, so to speak.

It's always, everybody's always looking for a way to replace manual human labor and you really can't. I mean, these tools are used by us to help us become more efficient, not to replace us really. I mean, even in other areas of industries, automation is there for efficiency. There's still a human behind the keyboard helping to do the work. So you can't totally get rid of a human. I mean, just to make a Terminator reference if that ever happens. Skynet's alive and we all need to run for the hills.

So Jim, I guess after you educate management, I think a lot of companies fall short of this and you have a whole chapter on it, and that's with training. How critical is training for your team automation success?

I think it's extremely critical because you want to have people that are on the same page as far as how the tool is being used, how to write the code, how to maintain it, and then have them go out and work with other groups to cross train them. The other problem with grabbing a tool and just going forward is people don't get proper training is some of these tools have a lot of functionality deep inside of them and at times we just barely scratch the surface. You know, we're just told go forth and automate and we go and do the best we can. So both self training and if the companies are willing to pay for formal training, it does help a lot.

You know, I used to see this all the time, especially for some reason with qtp I would see a framework and they would have someone developed like a framework on top of it. And I'm like, they have this built into to the tool. It's like they never took the time to look and see what the tool offered before going on and creating code to do what's already there. So I always thought that was kind of funny.

Yeah, I agree with that. I have to admit in my consulting work I'm brought in to get something going fast. So I've got canned pieces of code that I bring in to support what I'm doing and then I pull it together for the client. But there's pros and cons to that. The pro is, yeah, I've already got existing code, I can bring it in, I can jump start them. The con is some of those people don't have the in depth knowledge in that code that I do. And speaking of having to implement a different tool, if I come in and say, well look, you know, you did this in tool A, we need you to do it in tool D, then I have to translate. And I'm in a rush to learn as much as I can. I mean, a lot of the tools, they work the same way. It's just questions of syntaxes and functions and the way it handles at the UI level, the objects that it's working with. But again, it's, it's always a rush and.

We, we can miss some of the deeper functionality that it really gives us the power to do our work a lot better. And that just happens over time. But.

How to get around that? I mean, the one thing I can say is when you've got some downtime, start digging in deeper. I mean, the reference information out on the Internet is incredible. Now it's just sifting through some of it and really getting what you need.

Awesome. So Jim, you also have a chapter talking about basic automation development skills that you need and you have two axioms that use SMART and search. I think this would help. A lot of people could just go over really quick, maybe what SMART means or search means.

SMART stands for standalone, which means the scripts are able to run by themselves and you minimize your dependencies. M is for modular and maintainable. The code needs to be modular in its design and easy to maintain. Because one of the biggest problems we have with automation is maintainability. People just throw code together and then later on when it breaks, it's hard to fix it appropriate. This goes to focusing on what you really need to automate first and not trying to get too fancy with your automation and not trying to automate everything. I mean, automate, what is your highest priority, what's your highest risk areas? Reusable, build for reusability, keep it compact and focused. So break it down into layers of extract of abstraction so that you can plug and play what you need. And then the T is for testable and traceable. I mean, you need to be able to test your own code and trace through it so you can see how it's acting. And if you do have problems that you can get in there and quickly work on it.

The search axiom I learned from a couple of guys years ago at a presentation, at a conference, and I've taken it to heart because it leads into the standalone factor that when you create a test, you want it to be able to set up or start an initial base state of the system and then it executes. So you need the logic and data needed to run the test itself and then analyze. So as it's going along, you may need to do validations of certain things, handle error conditions if they pop up, reporting. So as the thing progresses, it's reporting its progress and what it's doing. That's really important because if you do find a defect, you can trace it down to seeing, okay, it got to this point, this is where it failed. So what was it doing before? Because that's one of the toughest things to do is from automation, write a bug report. So you have to know what the test did and what data was working with at that time, so you can translate that into a defect report and then at the end, cleanup. So if you've changed any data or you have temporary files, things like that, clean them up, get them out of there, and then the finally is to go home or return to a base state so that the next test can run. And that leads into being able to run tests independently. So you don't have dependencies between tests and you can also run them in parallel so you don't have to worry about one test failing and another can't run. Or you can break down the stack of tests to execute and distribute it across multiple machines. So again, start at a base state, end in a base state.

What I love about these axioms is that like you said, and I think at the beginning of the book, this can apply to any framework. So these are completely agnostic. And I think it's really helpful because a lot of times people think, well, it's a different tool. So I have to do a whole new type of learning where if you get the foundations in Place, it sounds like almost regardless of what tool, as long as you stay with those foundations, you should be okay.

Yes. And that's one of the purposes of the book is to be tool agnostic and technology agnostic, because this is about the process and methodologies that we can use to help in our work building out the automation.

You have a whole chapter on this. What did you mean by testability and how does that affect automation?

I think it's very germane to what's going on today because there are such rapid advances in technology. The toolkits that developers can get a hold of and the ides that they're using, I mean, they can build a form very quickly and then strap some code into the back of and get it running. And then when they go in and change it, the underlying dynamics of that page may change, which could be an object's ID number, it could be its name, because these tools will do that. When you work with a UI level, and this is why a lot of UI testing is fragile, is that developers and go chain, go and change things. We've already built it to go talk to it in a certain way and now it's broken. So by working with developers and say, hey, look, can you put in static name values? Can you put in static ID values and not let the ID tool or toolkit just go and generate on the fly also too, you can start talking about, well, hey, I need to be able to get into this thing and get this type of access to it, so the developer can build that in for you. That that is the testability which leads to automatability. I've worked with applications where certain objects are closed, which means I can't call their methods and properties.

And that makes it very difficult to do things at the UI level. I mean, even at the API level, if they don't have those APIs open and defined well, and they're the same from, you know, build to build and release to release, then it makes your maintenance of your automation go up. And that's what we want to try and do, is minimize the amount of maintenance work. Because.

Automation, as I said, it is a form of software development unto itself. And there are certain rules that we need to apply to it so that we have a fighting chance to keep things running and get benefit out of it.

Absolutely. So, Jim, the book's been on, I believe almost six months now. I can't believe how fast time has flown. Have you gotten any feedback on maybe someone's favorite chapter or what most people found really helpful?

Yeah, I mean it's been about six, nine months. I released the book and I've got a couple of things back from people that have reviewed it. I have had some people post things on LinkedIn saying that they like the, the format of the book and the information, but nothing really in detail. I mean, I am trying to do.

A revision like every quarter or you know, a few months to add in because there's some things that I couldn't put in the book right in the beginning because either I didn't know about them or it was details I didn't think need to be in it at that time. And sometimes people come back and say, hey look, I would like a little more information on this. So I expand on that. But it's been pretty good feedback. I mean a lot of people have liked it in that it's helped them start thinking beforehand, even writing a line of code.

Awesome. I think that's critical. Before they start writing a line of code. People need to go out get this book. Jim, where can they get the book?

It's currently out on LeanPub. It's an electronic book. I'm not using Amazon or some of the others where it's a hard copy like that because I am doing these revisions on a pretty frequent basis. Hopefully here in the next year I'll go to possibly a hard copy book when I do the full second version of the book.

Nice, Jim. I'd like to switch gears really quick. You are going to be one of our expert speakers at this year's Automation Guild. And, and you're doing a session on modeling methods for Automation in Testing. Can you just give folks a little sneak peek on what your session is going to be all about?

Yes, there's actually a chapter in the book that talks a little bit about different modeling techniques. And this presentation.

Both kind of drove that chapter. But also the information in the presentation is from that and expanding more the the things we work with in software, and this is part of this front end work is we need to have some type of model to look at so we can say, oh okay, here's this path through the system that I need to consider. So modeling allows us to look at it from the standpoint of the functionality, data, potentially the system performance and things like that. It can also help us decide what type of tools we may need to use to plug in and drive that part of the testing or the overall testing. So these are different techniques, both traditional and modern that I've seen and some that I've used in my work to say, hey look, here's how I'm going to design this stuff up front, then build it and then implement it.

So I think this session is really going to benefit a lot of people. So I highly encourage folks to head on over to GuildConferences.com forward/automation and register today. So Jim, another critical chapter in your book that I found, what I think is really helpful for folks is self learning and being older. I'm older, being older in the industry, I find I have to do a lot of learning. So any tips on self learning or what you went over in that chapter?

Yeah, in that chapter talking about self learning and mastery of our, of our craft and everything like that is.

There'S always new technology so we've got to keep up. And for someone like me who's been doing this for a long period of time, there's things I can, I can add out there, but there's people that have new views and ideas about how to do this work. So it's out there, you just got to go find it. And that overall helps us improve our overall skill sets and helps us help our companies for better testing and things like that. The thing that I've always liked about my career in software is it's a never ending process of learning. There's always something new to learn and some areas you specialize in, others you don't, you know, really deeply focus on. But you've got to stay on top of things otherwise you will get left behind. And this goes for your own personal career, but also you know, your work life because companies are looking for people with the latest skills. So if you can keep on top of things, it makes yourself more marketable and can keep yourself employed.

And it also makes you a lot better automation person.

Okay Jim, before we go now, this interview has been full of actual automation advice. But is there one piece of actual advice you would give to someone to help them with their automation and testing efforts and let us know the best way to find or contact you.

Okay. One thing I really want to emphasize to people is you've got to make sure you do put the cart, the horse back before the cart and prioritize what you're doing with your work. Plan it out so that you can give yourself a fighting chance for success. And that's really important because if you can get things done right the first time, it makes a lot of the work easier later on.

And I can be contacted through LinkedIn. My profile is out there. Just do a search for Jim Hazen and then my contact information is there and I do have a gmail account which you can post up there if you want to real quickly. A lot of people have trouble with it, but it's calcalpdivermail.com I used to live in California and dive a lot so that's how I came up with my email account.

Thank you Jim for your Automation awesomeness. The links to everything of value we covered in this episode. Head over to testguild.com a lake automation287 and while you're there, make sure to click on the Try for Free Today link under the Exclusive Sponsor section to learn all about Source Labs awesome products and services. And as I mentioned, if you haven't already, make sure to register for Automation Guild. Head on over to automationguild.com register today and accelerate your automation efforts in the new year. So that's it for this episode of the Test Guild Automation Podcast. I'm Joe and my mission is to help you succeed with creating end to end full stack Automation awesomeness. As always, test everything and keep the good. Cheers.

Thanks for listening to the Test Guild Automation Podcast. Head on over to testguild. Com for full show notes, amazing blog articles and online testing conferences. Make sure to subscribe to join the Guild and continue your testing journey. This has been a Joe Calantonio production.