95: It's Automation, Not Automagic with Jim Hazen • Test Guild

Managers and engineers can often get lulled into thinking automation is easy. After all, how hard can automation be? You record yourself interacting with the application, then play it back. Done. But how many of us have been burned by that type of thinking? I know I have. It’s up to us as automation engineers to educate the people around us about automation best practices and techniques if we are to have a prayer of surviving in this fast-paced, Agile DevOps world.

In this episode Jim Hazen, a veteran of the software testing trenches, shares with us his years of experience in succeeding with test automation. Discover what it takes to implement automation and set realistic expectations for your teams, keeping in mind that it’s automation, not automagic!

About Jim Hazen

Jim Hazen is a veteran of the software testing trenches, and has over twenty five years of experience testing applications on the PC and Web platforms. Jim has been involved with the startup of testing groups at multiple companies and has done consulting work for the last 15 years. He has helped clients implement tools for functional automation, performance testing and test management. He has worked with clientele management to achieve efficiency gains and financial benefits associated to testing.

Quotes & Insights from this Test Talk

You need basic concepts of programming, which is logic structure, how to write functions, and if you can, methods, that are reusable. Again, taking the problem and breaking it down, so being able to build libraries of common code, either for interacting with the application or specific things you need to do within the application … understanding datatypes and logic structures and how to put that stuff together so you have a functioning program. As you can see, we write testware to drive the testing of software. Just those basic concepts … You don’t have to be a high-end Java or C# guy, but just some good solid skills. Then, for the type of applications you’re working with, specifically I deal with a lot of things at the higher level, such as the GUI side and the services side.
Before you even write a line of code, you’re doing the front end social work and getting things straightened up so that when you do come along later on and say, hey look, here’s how we’re going to do this, they’re more receptive to it. You’re not saying, “Well, so-and-so said this on this article,” or, “The tool vendor sales guy said this,” and it’s like you get into that situation, it’s tough to get them to turn around and basically wake up and realize that’s not the reality of the situation. It’s going in and, like I said, doing the front end social work to find out what you have in front of you, who you need to talk to, and what problems you need to fix right from the beginning.
A good analogy to to think about the Test Pyramid is think of the earth itself. You have a core there. everything is built on top of it. The core itself is a certain size, and then you have the next layer up, which is, again, a percentage of the size of the thing, and then on the outside you have this thin layer going around the whole thing. It’s building out from the center. That’s kind of what I’m trying to put on it. I’m not trying to create something new, but just give people a different way of thinking about it.
I would say definitely the mobile is taking off because now we’re seeing a real increase in speed of everything going to a mobile platform. The applications are becoming more sophisticated. The interfaces are more sophisticated. It’s not like it was 10 years ago with your cellphone, where you have a text-based interface on there. Now you have full GUI type things on the interface on that LCD screen on your cell phone. Just like I experienced years ago with going from DOS-based applications over to the Windows and OS/2 world, it’s a big jump. There’s a lot of other factors you need to take into account in how you work with it.
Performance testing within an Agile environment, you need to be involved early on. you need to sit down and talk to people and say, okay, what are you trying to get this application to do? What are the service level agreements you need to meet? Is this something as far as transactional load? Is this something as far as the UI must respond within a specific period of time? It’s a lot of the same things, but again, you have to shift it to the standpoint of how can we get in earlier on. Instead of trying to do the big, huge performance test, you break it down into smaller pieces and work with it and then build it up.
I just want to help people try and avoid the potholes and make the same mistakes I did. As I said earlier, there’s a lot of pressure to get things done. Don’t reinvent the wheel. If you find something that works and you could manipulate it, do what you want, go for it. Keep moving forward. There’s a lot of stuff out there. You just have to learn to find what you need and put it together and get it do it.

[tweet_box design=”box_3″] It’s #Automation, Not Automagic~Jim Hazen

[/tweet_box]

Resources

Connect with Jim

LinkedIn: jim-hazen

May I Ask You For a Favor?

Thanks again for listening to the show. If it has helped you in any way, shape or form, please share it using the social media buttons you see on the page.

Additionally, reviews for the podcast on iTunes are extremely helpful and greatly appreciated! They do matter in the rankings of the show and I read each and every one of them.

Test Talks is sponsored by the fantastic folks at Sauce Labs. Try it for free today!