123: Building Testing Efficiency Awesomeness with Melissa Tondi
with Melissa Tondi
founder · Denver Mobile and Quality (DMAQ) and
About this episode
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.
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
- Twitter:@melissatondi
- Blog:Melissa-Tondi.com
- Company:Disrupt-Testing.com
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!
Keep listening
Related episodes

Automation Testing Podcast · Ep. 609
Why Your AI Tests Pass When Your Features Fail with Donovan Brady
with Donovan Brady
Why Your AI Tests Pass When Your Features Fail? Donovan Brady of Leapwork shows how to make
Oct 27

Automation Testing Podcast · Ep. 608
Scary Test Automation POCs Made Easy: Halloween Special With Paul Grossman
with Paul Grossman
Running a proof of concept on test automation tools can feel like a horror movie. Vendors promise
Oct 20

Automation Testing Podcast · Ep. 607
Locust and Azure Load Testing: Create and Debug Load Tests with AI with Lars Holmberg and Abhinav Premsekhar
with Lars Holmberg and Abhinav Premsekhar
Performance testing has never been easier to start, or more important to get right. As teams ship
Oct 6

Automation Testing Podcast · Ep. 606
AI Agents Passed the Tests. Real Devices Didn’t. with Nick Metcalfe
with Nick Metcalfe
Cloud device farms make it easy to get started with real device testing. But what happens when
Sep 29