Tech Talks With Michael "Fritz" Fritzius: Making Way To Optimal Test Environment With Automation

Though Quality Assurance is nothing new to the tech industry, the concept has significantly evolved over time. However, there are so many organizations out there that are still reluctant to adopt the change in legacy practices. Whether it is adopting advanced solutions like automation or change in methodologies like Agile or DevOps, the inability to adapt to the change is not only ruining the user experience but also making the industry fall behind.  

At BugRaptors, we have spent quite a lot of time determining and executing the change that was necessary for us as well as our clients to sustain the digital wave. Besides, we believe encouraging interactions within the QA industry is significantly important to take the idea of innovation to the industry as well as the testers community.  

With that thought in mind, we run tech talks with industry experts, influencers, as well as seasoned professionals from the QA industry who could add more value to the QA enthusiasts through our medium. Also, these interactions helps us all to allow changing dynamics flow into our existing ecosystem.  

This time, our in-house expert Sandeep Vashisth, VP, Quality Assurance, BugRaptors himself had a conversation with the very dynamic and very informed, Michael Fritzius. Michael is presently operating Arch DevOps along with automation, DevOps, and of course all things Quality Assurance. He is also a public speaker, author, and coach who is effectively managing all the roles including his Multiprenuership.  

During the interview, Sandeep and Michael interacted on everything surrounding test automation and the concept of creating an optimal test environment with detailed insights on test automation tools. Also, Michael openly shared his experiences and knowledge while reflecting on suggestions and advice that can help testers community.  

Let’s now begin with the interview quickly.  

Sandeep: How did you start your journey? Can you tell us about your professional experience and expertise? 

Michael: Honestly, I fell into it. M uch of my career hasn’t been fully directed, and I often joke with people that I have less of a “career” and more of a “careen”. Originally, I wanted to become a software developer and went to school for it. I was a dev for about 3 years, programming microprocessors (“embedded developer”) and the next job I had after that brought me into the QA sector.  

There was still a lot of software development involved, but it was to the goal of automating testing practices. It took a couple years but I finally realized: holy moly I’m a tester. And from there it was a wild time of learning new testing methods, understanding what makes for a good bug, what a good test case is made of, and everything else that’s involved in testing.  

Sandeep: What do you think about changing QA practices? 

Michael: I think change is good, as long as it’s not “change for the sake of change.” As technology changes, the QA practices that used to be able to efficiently find bugs need to change too. But also, we can’t just change stuff because we need to appear like we’re on the cutting edge. The right kind of change isn’t founded in a fear-based mindset, but a calm, calculated approach to identify what needs to change, and why, and coupled with a fearlessness that comes from being willing to step outside the accepted norms to try something new.  

Sandeep: What are the requirements for successful automation?  

Michael: It should be simple, easy for most people to understand, check for one particular thing, be easy to maintain, and not repeat any part of any other test that’s already been done. The goal is to gain as much information about the system under test as quickly as possible. And actually, that means you can get away with a LOT less automation than most companies write.  

Sandeep: How do you choose a tool/framework for automated testing? 

Michael: I’ve seen too many companies get hung up on the fear of picking the wrong thing. If they go with an off-the-shelf tool, there’s always the chance that it might solve 100% of their automation challenges now, but either the product they’re making (or the tool itself) changes so that there’s less of the tool that works with what’s being tested.  

Also, for a really complex tool, that tool itself becomes a focus, which takes time and attention away from the software actually being tested. Many tools out there do a ton more than any one company really needs (because the tool provider is trying to serve multiple companies). So, learning the tool completely means learning about all the different ways it can be used, and then knowing what’s applicable and what’s not. People have to have a lot more info in their brains to know how best to use the tool, and it increases the learning curve.  

Also, there’s always a growing demand from QA folks to learn automation, so anything that allows them to do that is great. They’re able to level up their abilities, be more valuable to the company (since they know how to find bugs already, they can automate those skills), along with, frankly, making themselves more valuable if they ever decide to leave the company.  

Because of these reasons, I almost always go with the same combination of technology:  

• Cucumber 

• Ruby 

• Watir 

• Savon, Rest-client, and some kind of database library 

1. Cucumber makes writing tests much more understandable for people. It’s written in English so that anyone on the team (probably anyone in the company) can understand what’s being tested. It enables project managers, business analysts, developers, testers, and anyone else, be able to weigh in on what’s being tested, and make suggestions in case something is missing.  
2. Ruby is my go-to language for test automation. I’ve been coding for… wow, nearly two decades? Hope I’m not making myself sound old lol. But i’ve written test automation in almost every mainstream language, including C, C++, C#, Java, Python, Perl, Bash, Groovy and Ruby. Ruby is by far the easiest language to pick up and has a lot smaller learning curve.  
3. Watir is for interacting with the web browser for browser-based tests. It’s established and mature, not requiring many updates these days, and is fully designed to work with Ruby (that’s what the “R” at the end stands for). It’s good enough that ports have been made to .Net (Watin) and Java (Watij) which make for hilarious-sounding words that piggyback on the reputation Watir has enjoyed for more than a decade.  
4. For everything else, I choose established libraries that know how to interface with SOAP services, REST services, and whatever kind of database connection is being used in the application. 

With this stack, there really isn’t a ton of new automation code that needs to be written once the foundation is in place. For web-based testing for example, there would need to be a piece of code that knows how to click any kind of button, one to enter text into any kind of text field, select an option from any kind of dropdown, and a piece of code for any other kind of element that’s on the site.  

From there, tests are written making liberal use of regular expressions (down in the part where the code actually lives), so that more of the focus can be up higher in the English part of building tests. Many times, full frameworks can be built with less than 1000 lines of code, and maintenance is a lot simpler.  

Sandeep: Is automated testing making manual testing obsolete? 

Michael: No, but I understand why people continue to think that. Most of the time, people think that QA is following a repeated set of steps to see if the same output happens, and that’s probably how most QA people get their start. That part absolutely can be automated. The part that can’t be is the interpersonal part where QA people work with other people on the team to establish good tests, and help make people aware of problems at the requirements stage before the first line of code is written.  

But too, the reason why people outside of QA think that automation makes manual testing obsolete is because people don’t fully understand what goes into testing. And that part is on us–we need to do a better job of communicating what we’re doing so it doesn’t seem like black magic to colleagues.  

Sandeep: How can organizations create a stable and optimal test environment? 

Michael:Start first by defining what “stable” and “optimal” means for the organization. Does that mean 100% uptime? Does it mean that it can handle the load from multiple testers hitting the system at the same time? Does it mean that you always have the correct information in the database prior to running tests?  

1. Answering “Yes” to any of those questions means that the next step is to ask: ok, how do we achieve that?  

2. How do we make sure we have 100% uptime? (what hardware or software requirements would need to be there?)  

3. How do we ensure that we can handle, say, 20 instances creating 100 requests per second?  

4. How do we create or maintain the same data set so that we can have a known baseline before testing?  

Sandeep: Are you writing any books these days? 

Michael: Working on a few, but they’re outside of the QA space oddly enough! I completed a book which is up at https://archdevops.com called “Awesome Culture, Awesome Software” and is free for download.  

Other books that I’m working on are about these topics:  

• Managing your Email Inbox 

• Time Management Without Going Insane 

• Relationship Building Techniques 

• (Just added) Public Speaking Isn’t Scary 

Sandeep: What advice would you give to aspiring testers who look forward to speaking at events or conferences?   

Michael: Do it! Speaking isn’t nearly as scary as it seems. Actually, maybe I should write a short book on this topic.  

If you’re interested in speaking though, what’s helped me is this:  

• If you find a group to speak to, you’re speaking to people who have segmented themselves into this group or event, because they want to learn things about that space. It’s not just a random group of people.  

• Also, going in feeling like you have a message to share and that you want to build a relationship with people, it feels much more like you’re in control (because you are) and can deliver a powerful message that makes them think.  

• Finally, be sure to have a clear call to action. Once they’ve heard the talk, what’s the next step? What do you want them to do next? And what do you want to get out of it? Clients? New job? Emails?  

Don’t be afraid to be a little goofy. The goal is to deliver a memorable talk and get people to pay attention and think. And haha, I just remembered: I gave a talk called “Prune Your Tests!” about how it’s important to go through your test suite and get rid of tests that aren’t actually adding value. For that talk I dressed up like a gardener, straw hat and everything lol. People remembered that talk!  

Public speaking is actually something I help with, particularly people in QA. I’m happy to share more tips if they’re reading this and want to reach out.  

Sandeep: Where can people learn more about you? 

Michael: I’m on LinkedIn although not nearly as much as before. Been branching out in some different areas.  

My LinkedIn profile is https://linkedin.com/in/fritzops 

Website for Arch DevOps is https://archdevops.com  

My wife and I have a company we started called Exactly Zero, and you can find out what we’re up to at https://exactlyzero.com  

Also, I’ve taken my automation, podcasting and design skills to spin up a service called podcastify.me which can be found at https://podcastify.me  

And you can always reach me at fritz@archdevops.com – love meeting new people and sharing wherever someone is on their QA journey.  
For more such interesting updates and interviews, stay connected with BugRaptors.  

If you have any queries related to automation testing services or need help with your next test automation project, feel free to reach our team through info@bugraptors.com