Mel's Take-Aways: TestTalks Episode 100: Gerald Weinberg

"Adapt to what is rather than what it should be."

 - Gerald Weinberg


I listen to Test Talks by Joe Colantonio when I have some free time and need some inspiration. I think Joe has a great interview style that is easy to follow and conversational. These podcasts are not fluff pieces though. If you find yourself taking notes and stopping to re-listen to a segment, I wouldn't be surprised. I end up doing that just about every time.

The 100th episode isn't the most recent one, but it's where I left off from the last time I stopped by the page to give a podcast a listen. There were so many take-aways from Joe's conversation with Gerald that I felt I needed to write a blog post, and create a new section in my blog for just that.

Take-Away #1:
Stop looking for secrets to testing or developing or really anything. Get rid of things that are wasting time. Learn to love things you find boring about your job, find a way to love the boring things, then find an excuse to do it. 

This was the first 10 minutes of the podcast and this hit home for me in the most striking of ways. I find writing code, boring. There, I've said it, it's been my dirty secret for like, ever. However, fixing code, reading code, testing the guts of code or how the services that use code interact, that's the best mind candy I have ever had. I love testing. I love problem-solving. I am not exactly the most thrilled when I have to write code. (Admittedly, I don't do it that often.) It's a different kind of problem solving/making that I've sorta distanced myself from. And, that has created a weakness I'm working to address, not only because my ever-changing profession is pushing in that direction, but I am pushing myself as well, to adapt and move out of comfort zones and learn.

Take-Away #2:
Who's risks are you concerned about? Which risks take priority over others?

When you look at testing from this perspective, you can make a mind-map of risks (generic or otherwise) and really get to the point of these questions. You can not test everything. It's an impossible thing to do. But if you do your best, and your best includes a priority of risks for what you are testing then you can mitigate risk. If you are not testing with prioritized risks, you are not really testing.

Take-Away #3: 
"Name Magic." Calling it a leg, doesn't make it a leg.

Weinberg then goes on to mention that you can automate tests, but it doesn't automate testing. Colantonio then mentions a phrase from Richard Bradshaw to Weinberg which is: "Automation IN testing" (I capped and underlined the word on purpose for emphasis.) We should all be wary of buzz words and magic phrases that seem to promise more than they offer. Weinberg's reaction to Bradshaw's phrase is neat. Part of his response was: "A tiny change can make an enormous difference." 

Making a difference.
Colantonio asks about the "One piece of advice to improve their testing efforts" and I think Weinberg responded with the best response I've ever heard to that question. "The one thing you need to do to become a better tester is to discover the one thing they need to do to become a better tester." He tells a story about a body builder and then gives an examples in testing. Basically Wienberg points to finding and working on the weak points in your testing skills. "If you find yourself saying you don't need that skill, that's probably the one you need to work on."

The podcast was full of great things to think about and I only mentioned three that stuck out as things I've valued, but had never heard them stated in such a clear manner. Or if I had, it didn't make a huge impression the first couple of times. If you listen, I'm sure you'll find your own.

Thanks to Joe Colantonio  and Gerald Weinberg for a great interview. Check out the episode yourself at "Test Talks".

Comments

  1. Maaret PyhäjärviJuly 5, 2016 at 12:32 PM

    Mel,thanks for sharing this. I came back to this post because today is #30daysoftesting day to comment and I started feeling quilty I did not comment when I first came here.

    I read your blog post and then listened to the same podcast. Very much similar things moved me as yours.

    The first piece you mention is golden: do stuff you love. Jerry delivered that message with such ease and sometimes I wonder how things that sound that simple can be so hard.

    ReplyDelete

Post a Comment

Most Read Posts

Ready, Tester One? *GO!*

"I handed my passport to the immigration officer, and he looked at it and looked at me and said, 'What are you?'" - Grace Hopper (60 Minutes Interview) The Grace Hopper quote above always makes me think about my job as a tester. Companies that develop software know they need testers, but they generally have hard time figuring out what testers are and what skills they need in the role. There have many discussions about how testers can be more technical and at some point, coding comes up in the conversation. My response on twitter contained a few things on a list I have, which I created for a client, so they could have a checklist of skills. This checklist was a guideline to determine the skill level of the tester applicant. This is by no means a complete list and I would be open to additions to the list. Feel free to add those to the comments or tweet them to me. For clarity, I took the list of skills I had and broke them into levels. I like games and I lik...
Read more

Learning From Failure: The Tricky iOS Environment

"You build on failure. You use it as a stepping stone. Close the door on the past. You don't try to forget the mistakes, but you don't dwell on it. You don't let it have any of your energy, or any of your time, or any of your space."  - Johnny Cash There are times when our work, as a team, as testers on a team can give us insight into how we can improve things for the overall success of the product. Often those things are issues or defects which can present themselves at the most inconvenient times, in the most inconsistent ways. When we can learn from them and improve things for everyone on the team, the team benefits. When the team owns the defects and the testing strategy, not only the testers, then customers benefit as well. I was working remotely verifying a release and only had simulators and emulators to work with as I was testing mobile builds. Often folks mistrust builds which only use emulated software and not real devices for fairly good reasons...
Read more

Postman In The Pipeline: Newman Delivers

Image
  It's not me, it's the songs.  I'm just the postman,  I deliver the songs....  - Bob Dylan Recently, I've had the chance to work on a project with some other awesome folks which has involved creating a BFF - A back end for front end service. This allows the app to access several API and aggregate calls into something the app can use, or lets the app send information to the BFF for several APIs to receive. Part of the code coverage for the BFF was creating some simple tests with Postman around the business logic and interactions. Learning About Postman I did lots of reading. Lots of reading how others has done things (Danny Danton - big props for being a super help!). Eventually, I came down to a small set of tests which could give us some accuracy about our BFF pipeline and the APIs we were accessing with it. Postman has a couple of options for this, global variables, environmental variables, and plain variables. One of the first problems I came acros...
Read more