Tester Tested interviews Braidy Tester

Braidy Tester has been interviewing great testers for Dr Dobb's Journal. I think I should say, I was just lucky to have been interviewed by a great tester like Michael Hunter.

Michael Hunter blog is widely read in India too. In fact, it is one of my friend who told me that my interview has appeared in Michael's DDJ blog and I blogged about it: Braidy Tester interviews Tester Tested .

You might want to check http://thebraidytester.com to know more about him, his bio, his articles and presentations.

Michael Hunter is an Expert Tester and Test Architect for top secret projects of Microsoft. Lucky Microsoft!

I thought why not I interview the interviewer - [ Hunter hunted :) ] So, here it goes...

PS: What does "Braidy Tester" mean to you?

MH: “The Braidy Tester” is my personal brand. I often braid my beard (as you can see on my MSDN blog [http://blogs.msdn.com/micahel]). When I was preparing to start that blog I spent some time contemplating what to call it. I wanted something snazzier than “One More Microsoft Tester Blogger”. Eventually I decided that weren't that many testers who braid their beards, so I settled on "The Braidy Tester".

PS: How has your experience of interviewing great testers been, so far?

MH:It is a lot of fun! I enjoy hearing other people's views on testing. I especially enjoy hearing about their favorite bugs!

PS: If you chose to answer one question from your own interview, what would that be? and what would be it's answer?

MH: I'll pick "What do you think is the most important thing for a tester to know? To do? For developers to know and do about testing?" I think the most important thing for a tester - or a developer - or anyone - to know is that they will never know everything and so there will always be something more for them to learn. The most important thing for them to do is to go learn it! Learn about testing, development, design, art, music, geography, calculus, how people learn, whatever. I find that everything I learn about has something to teach me about testing.

PS: How do you test the code you write? ( after all the great testing experience)

MH: I am a big fan of unit tests and Test Driven Design. I am way more confident in my code when I have TDD'd unit tests backing it up! I also think about testing while I am developing - what tests will be interesting (and will my code survive them), how can I make my code more testable. I look at my code through white box, grey box, and black box glasses. I run through the checklists and mnemonics I've developed and acquired. Then I give my code to other testers and learn what I missed!

PS: There is a lot of confusion over terminologies and definitions in testing, in my opinion. If you feel the same, how do you handle the confusion when you speak or communicate with a tester whose definitions and terminologies appear to be different from yours?

MH: This can definitely block productive conversations. The first - and often the most difficult - step is to realize a conflict in definitions exists. Once you are aware of that you can make the conflict explicit: "It seems to me we don't all mean the same thing when we say 'dogfoodable'." Then you can proceed to form a common definition.

PS: What thoughts run through your mind when you find a bug in a product you bought.

MH: First I say "Hey look! A bug!" And show it off if it's cool enough. Then I wonder how the company missed it. Then I ask "What would have to be true in order for this company to ship this bug?" That last question is the most interesting I think.

PS: What has been the heights of you enjoying testing?

MH: I enjoy finding bugs. Especially the ones which take time and skill and effort to track down. Showing bugs to developers is fun too. My biggest thrills, however, come when I help prevent bugs from occurring in the first place!

PS: There is always something to learn from everyone and everything around for testers. Do you have an experience that you learned something from a kid?

MH: I find watching children interesting because they are so inquisitive. The younger they are the fewer assumptions they seem to make. When I talk about testing I suggest learning to think like a two-year-old: develop the ability youngsters have to come up with an endless stream of questions about everything. Poke at everything in many different ways and you will almost certainly find a case your developer didn't expect!

PS: Tell us about a ( or a set of ) question that you have been asking yourself and how you found answers to them?

MH: When someone else finds a bug in my area I ask why I missed it. When someone finds a bug in my code I ask what I can do to not make that mistake again. A lot of what I am looking at right now is how I interact with other people. Why did I react so angrily to that person? Why am I happy to help this person and not this other one? The more I understand about how and why I interact with people the way I do, the more I can change my interactions to be more effective.

As for finding answers, partly I formulate theories and test them out. What if I deliberately pause two seconds before I respond or react to something? What if I focus on what the other person is saying rather than deciding what I am going to say in response? I find journaling to be helpful as well. Writing things down helps me figure things out, about bugs I am chasing down, about code I am designing or writing, and about myself.

_ end of the interview _

He started this interview with a word, "Fun" and I am not surprised at all. He enjoys testing and thinking about testing so much. His blog is a addictive for passionate testers. After reading, "Making developers cry since 1995", would you ever want to miss this guy's writing?

Thanks a lot Michael Hunter!

-- Pradeep Soundararajan - pradeep.srajan@gmail.com - +91-98451-76817

"Pradeep's first language is not English--his first language appears to be testing." -- Michael Bolton