Channels ▼

Community Voices

Dr. Dobb's Bloggers

Five Questions With Jason Blue Barile

May 26, 2008

Jason Blue Barile has been testing at Microsoft for some ten years now, working on products such as Internet Explorer and the Windows shell. Before that he lived the college life at Vanderbilt University, where he Research Assisted at the Intelligent Robotics Lab and worked on projects such as a theremin-playing robot. These days Jason is Test Manager for Microsoft Visual Studio Team Foundation Server down South in North Carolina. I wonder if he's working on a testing robot....

Here is what Jason has to say:


JBB: I've always been a tester at heart. I recall buying a book with 100 text-based games in BASIC when I was in 7th grade and spending hours on my Apple IIe debugging problems with code for a Star Trek game in the book. I recall being extremely satisfied each time I found a bug and marveling at how such a great book could be published with buggy source code. In high school, I ran a bulletin board system (BBS) and spent a lot of time working together with other sysops debugging problems with customizations to the software. In college, my professors were pretty hard core about our homework assignments working correctly, so my friend Carl and I would spend time adhoc testing each other's assignments before turning them in. I didn't have any formal training in software testing until I joined Microsoft, however. My first assignment was testing the APIs for ActiveDesktop in IE4.

I honestly never considered a career in software testing until my interview with Microsoft. I went into the interview hoping to become a developer, but the interviewer suggested testing given my passion for quality. Once she explained what Software Design Engineers in Test (SDETs at Microsoft) did all day, I was hooked in an instant!


JBB: You don't have to fix all the bugs :). When I started my testing career, I naively thought my developers would have to fix any and all bugs I turned up. I quickly learned a lot about prioritization, customer-focused testing, how to consider risk of regression when fixing bugs, etc.

DDJ: What is the most interesting bug you have seen?

JBB: Canned answer alert: they're all interesting! During Windows XP development, we had a bug where we had written some Accessibility code for the Shell. When the Shell was in right-to-left mode (e.g. for Arabic Windows), we forgot to flip the logic in the accessibility model. So when our test automation would ask the "close button" on a window frame where it was and then sent a click to those coordinates to close the window, the click would end up opening the frame's system menu instead. It was interesting to me from the perspective that most customers would never be exposed to this bug, but a subset of people using Accessibility tools on RTL builds might be completely blocked by it. So you shouldn't always just test for "most" customers.

DDJ: How would you describe your testing philosophy?

JBB: "Test Early / Test Often / Test Enough But Not Too Much" – Create a quality process that catches errors as early as possible, preferably before checkin, but also be realistic about the cost/benefit of testing at various stages. Find that sweet spot between not testing enough and testing too much (easier said than done!).


JBB: I have a tough time choosing between debugging skills and communication skills, but if I have to pick one, I would go with the latter. Being able to explain software defects and their impact to the customer in simple terms is critical. Effectively summarizing the steps to reproduce the bug in as few words as possible can often make the difference between a bug being fixed or not – or at least being fixed correctly or not.

Debugging is a close second here. The more you know about the software you're testing and the failure paths of the code, the better. You'll be more effective in testing around bugs to look for related problems, and you'll also earn the respect of the developers you're working with. Respect helps build better professional relationships which leads to more and more effective communication with your team members, etc.


JBB: I can't think of anything off the top of my head. Perhaps "finding every bug" fits here. New testers (myself included, as I mentioned above) think you have to find every bug, no matter how obscure. What's really important is finding the bugs your customers will care about & making sure those get fixed first.


JBB: How to fit into an Agile world for many testers. How to increase efficiency and effectiveness.


JBB: Why aren't more people interested in software testing as a career? I think people just don't understand how much fun software testing can be. There is a common misconception in the industry that testers can't be as technical as developers, aren't as creative, or are somehow "second class citizens". I know lots of people who used to be developers and got bored with constantly working on the same feature area for years on end. As a tester, you get exposure to new features and technologies all the time. You get a great breadth and depth of understanding of your product, and you're the one fighting for the customer (remind me who pays the bills again?). It's such a critical role in the software development process that it just doesn't make any sense to me why testers would ever feel like they're not important.

DDJ: Is there anything else you would like to say?

JBB: Thanks for this opportunity to share! I hope these interviews help inspire folks to consider software testing as their new career path!


Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags


<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags


<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

