123: Building Testing Efficiency Awesomeness with Melissa Tondi • Test Guild

Sure — you might be working really hard, doing everything that is needed for testing your software, but is what you’re doing really the most efficient way to test? In this episode Melissa Tondi, head of SQE at ShopatHome.com (and one of the best-known thought leaders in the quality engineering space) breaks down the testing process and helps us identify areas that traditionally cause the highest number of inefficiencies within test teams. So listen in and hear what it takes to build a world-class testing organization.

About Melissa Tondi

Melissa Tondi has spent most of her career working within testing teams- concentrating on functional, performance, security, and mobile testing techniques. In her current roles, she is the founder of Denver Mobile and Quality (DMAQ) and, as Head of SQE at ShopatHome.com, she is assisting teams to continuously improve the design, build, test, and delivery of quality software. Throughout her career in the software test and quality engineering fields she has focused on organizing testing teams around three major tenets—efficiency, innovation, and culture. Melissa’s previous roles have included Vice President of Professional Services for a Mobile-focused startup, Director of Software Quality Engineering in the world’s leading education company; QA consultant for health care, finance, and software-as-a-service industries; and president of the Software Quality Association of Denver

Quotes & Insights from this Test Talk

What I’ve been doing over the last several years is really focusing on the day-to-day operations that an individual tester would take on how they approach their strategy and then eventual test execution. Then really fine tuning things that were either redundant or duplicated somewhere to the left or somewhere to the right of us and then really came up with a plan and a good model to be able to quickly assess those inefficiencies, and then more importantly, quickly execute a plan in order to remove and hopefully, completely eliminate those efficiencies from our overall testing approach.
I think one of the areas that software testers tend to shy away from is understanding and looking at unit tests or understanding what an individual developer might be doing on his or her end to test their work before letting it loose on the testing team. One of those areas is unit test. Usually, one of the first questions that I ask either if I’m joining a new team or if we’re building a new team is what the unit test approach is and where those results are and if they’re easily able to be both accessed by anyone or everyone on the team and how readable are those tests so that we can start looking at what has already been done from a dev standpoint and see if there’s anything that we can again make more efficient from our testing standpoint.
I think one statement that I’ve kind of … this is one of our tag lines for teams that I’ve been on is that anyone in IT or software engineering should always be early adopters of technology and it includes the software testing team. In a lot of ways if we are not adopting early on new and emerging technology to include tools like automation or performance or data tools, I think that’s an opportunity that is missed and will eventually be a stopping point or certainly a hindrance to more professional career development from a software tester.
In a lot of ways you would consider that me contributing to the community but I’m also receiving because I’m actually learning as I’m delivering it and something where I may have presented on 10, 12 times I still learn every single time I present that because I’m hearing feedback from others so I absolutely agree with you. One of the best ways to learn something is to teach it or to present it.
I think that by adopting that as technologists we should be early adopters of technology and always having that mindset. I think there’s a natural balance that is struck between how much technical expertise do I need and how much product expertise do I need. I really do believe that it’s close to a 50-50 split to be honest with you and maybe in some cases it’s a 40-60 or 60-40 depending on which way.
Again, going off of my statement of being early adopters of tools and technology. I mean I think we should always be looking at continuous improvement. If we improve ourselves on a personal basis, that will naturally allow us to be a model for others and hopefully, improve our overall SDLC, whatever flavor of SDLC or whatever method we’re taking from a company standpoint. I’d say always look at ways if you find yourself repeating a task whether it’s adding data manually or testing the same type of scenario over and over and over again. Take a few seconds and ask yourself is this something that can be automated. Don’t let that be the end all but really say, and if it can be automated, where will I spend my time assuming that that will save me time in the long run. Maybe that is you have more exploratory testing sessions or you focus on a particular area that you have time and time again not been able to really focus on that you really want to.Really, not just saying can it be automated but taking it to the next step and saying and once it is automated what will I do with that newfound time?

Resources

Connect with Melissa Tondi

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!