Feeling hungry? Have you ever binged on tacos? Do you remember how the first one tasted and thought it couldn’t get much better? But by the time you got to your third and fourth you may have started to tire of the tacos. (You’ll have to listen to this show to find out how this analogy translates to testing!) In this episode, Gregory Schmidt serves up some testing tamales in the form of optimum marginal utility as applied to test value that will help you take your testing “YUM” factor all the way to 100.
About Gregory Schmidt
Gregory got a Bachelor of Arts in Economics and History, so he naturally went straight to IT to work on the Y2K problem for a small bank. He left IT when the small bank got bought by a big bank. Throughout the journey since then, he has served subpoenas, coached cheerleading, gotten a teaching license, and worked small comedy circuits.
He returned to IT in 2011 to work for a large bank. Since then, he has been working to automate and right-size a regression suite of 2800 test cases down to 500 while continuing his Agile journey.
Quotes & Insights from this Test Talk
- The reason we talk about ten tacos is because you can actually get negative marginal return. I want you to picture, by the time you to get to your eighth, ninth, or tenth taco, you could actually start to feel a little sick. If you are Wells Fargo, and you want to make sure that your Canadian business customer can log in from an OFAC country, or Office of Foreign Affairs, someone we're not allowed to do banking business with, it might take quite a bit of work to get that one test completed to the point that maybe you should just let them call the call center. If you have three testers working on this, here's an easy number, $50 an hour, and it takes them three hours to get the data ready, prepare it, run the test. You now have a $450 test. A phone call to the call center for this one user might cost you $4. If you have a million of these users, that's $40 million. Then it pays to do a $450 test.
- Automated tests do tend to make your stomach better, to follow that analogy. You would be highly surprised at the companies that do not yet automate. I'm always surprised when I found out what people do and what struggles they find in trying to complete a test suite. That is the one part of it. The second part is I want to empower quality analysts, quality engineers, QS, quality services, whatever the word will be, I want to empower them to take not a hard line stance but the ability to look at the manager or someone who is maybe not fully aware of what goes into this and say, “This isn't worth it.” I don't know how many times you ever heard the expression, “Just test it all.”
- We have to find ways to make people not so much part of their own tribe. There's not a QE tribe. There's not a developer tribe. There's not a test lead, dev lead, product owner, Scrum master tribe. I have had something like five different Scrum masters in the last three years, five or six, and that's going to be a big key to it. If your Scrum master and your product owner are true champions of what you're putting together, then I think that's the big start
- Now, what we use is almost entirely API's, and our UI, or our HTML, whatever you want to call it, our JavaScript, that's all secondary to it. The majority of our testing are these API's. Those have very small tests to them, but, more to the point, we have a governing body. We can't just write up an API, throw it out there, and say it's got to be like this. It goes under a critical and intense review, about four guys, whose only job is to make sure that your API's are documented
- I'll tell you what drives me, and it's going to sound highly arrogant. I want everyone to preserve their right to indignation. I want you to think about that. When you preserve your right to indignation, you are unassailable. Everyone's tests are different, but, if you take the time and energy to work on your craft- Like, if you look at this as a job between medical school or until you do the next thing or until you write the next app that orders pizzas when your brain gets hungry, that's fine, but if you're going to accept quality engineering, quality services as a craft that involves, you want to make sure that you are educated and that you preserve your right to indignation. You never want someone to say, “I feel like you could have done this better. You could have done this differently. You could have followed better practices,” so educate yourself. Find out what's good. Go to local meet-ups. If there's not a local QE meet-up in your area, I encourage you to start one, because there's plenty out there for the Java community, for the JavaScript community, for the Python, Pearl, SAP. You can't throw a rock on a Tuesday night without finding somebody meeting once a month. Go out and try to find one for QE. It's not easy. Do yourself this favor. Find other people like you. Talk about what works, what doesn't. Subscribe to podcasts. Subscribe to TestTalks.
Resources
- Gregory's STPCON session see him live!
Connect with Gregory Schmidt
- Twitter:@krymdog
- LinkedIn: Gregory Schmidt
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!
