Channels ▼
RSS

Tools

An Interview with James Whittaker


James Whittaker is, I dare say, one of the celebrities of the testing world. He was long a professor of computer science at the Florida Institute of Technology, where he became well-known for his efforts to find ways to make testing a teachable skill. He and his research group there created innovative testing technologies and tools, including the popular runtime fault injection tool Holodeck, and became highly skilled at breaking software security. James founded Security Innovation to productize his work, but recently he has left both that company and teaching to join Microsoft as a Security Architect, where he is working to integrate testing into the Security Development Lifecycle (SDL).

James wrote How To Break Software - one of my favorite books on testing, co-wrote How To Break Software Security (also very good) with Hugh Thompson, and co-wrote How To Break Web Software (haven't read it yet) with Mike Andrews. James' talks at Microsoft are always standing room only; this interview will give you a taste of why.

DDJ: What was your first introduction to testing? What did that leave you thinking about the act and/or concept of testing?

JW: I was in graduate school in a software engineering group studying high assurance software engineering methodologies (cleanroom to be specific) and the bloody dev group met at 7:30 on Saturday mornings! I missed the first three meetings (dude, in grad school the nerd act doesn't happen that early on a weekend) so the professor put me in charge of the independent test team (which I discovered was just me). So that left me with the idea that testers get more sleep than devs but that we need it because we are woefully outnumbered.

And that perception remains, sans the sleep part.

DDJ: What has most surprised you as you have learned about testing/in your experiences with' testing?

JW: The sheer number of people *passionate* about testing, particularly at Microsoft. It gives me a great deal of confidence in the future knowing that such skill and talent is being applied to the hardest problem the discipline has to offerwhich is quality.

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

JW: The most interesting bug is always the latest bug. Just today everyone in our group was surprised at an Inbox with thousands of recall status messages. Someone sent a mail from an alias of 1275 members, then recalled it. The recall then sent success/failure notices to EVERYONE on the alias. That's 1275 x 1275 (about 1.6 million) emails! How's that for exploiting a design flaw!

DDJ: How would you describe your testing philosophy?

JW: Eyes open, brain on, test! Or the longer explanation covered in How to Break Software. Thanks for the chance to plug one of my books!

DDJ: What do you see as the biggest challenge for testers/the test discipline for the next five years?

JW: There are a number of trends that testers are going to have to grapple with. The first is that software is getting better. The result of this is that bugs are going to become harder and harder to find and the weaker testers will be relegated to Darwinian insignificance. Keeping sharp, building skills and maintaining a cutting edge testing knowledge has never been more important.

The second is that software process is finally taking over. For years processes haven't much affected the way software is built (which doesn't say much for legacy processes). But here at Microsoft the SDL is revolutionizing the way software is constructed. Testers have to figure out their role in this process. We have to be there, working, at project initiation and play a key role in every single phase of the lifecycle. Testing is not a task for the latter stages of the ship cycle. Testers who realize this and customize their work accordingly will rise in prominence within their product group and be able to influence the growth of the SDL rather than be steamrolled by it.

[See my Table Of Contents post for more details about this interview series.]


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<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

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 

Video