[Bj's Reply] Hi Sherry, I also occasionally wonder if I am making any sort of positive impact, and I look around me and realize that yes the industry and discipline is changing in some very cool and exciting ways. Not necessarily because of me, but it is changing in ways that I believe in and promote. But, of course, change takes time and as I have gotten older I have become much more patient and as long as I see positive change I think I’ll hang around.

Software will always be plagued by bugs, but when it is constantly reinfected by the same type of bug then we should find different solutions to prevent the problem. One of the cool things out of MSR recently has been PEX. (see http://research.microsoft.com/en-us/projects/pex/). Now we just have to figure out how to get devs to use it!

Also, leaders in the industry need to help change the perception of testing. Thinking about testing as a destructive activity is destructive to the discipline. Managers don’t see ‘breaking’ the product as adding value. They do understand they want to identify issues before release, but if we are constantly trapped in a break & fix mindset then the business is not growing. Software testers should find ways to add value to the product lifecycle such as driving quality upstream and partnering with devs to prevent low level issues from creeping into the product. That frees up our time to really think about the end-2-end stuff.

Ok enough of this lesson about things you nether wanted to know.

[Bj's Reply] Hi May, this was just tongue-in-cheek. Actually, whether the right slanting style is oblique or italic depends on the font selected. For example, the Lucida Console font style is oblique, but the Arial font style is italic. These styles are properties of the fonts, but I am not sure that most Notepad users (I use notepad a lot still) really care about the difference though.

But, I appreciate you pointing this out.

[Bj's Reply] I would respectfully suggest that a view of testing as destructive is antiquated and certainly quite limited in scope of the discipline. Boris Beizer suggested ‘the primary objective of testing is defect prevention, and the secondary objective is defect detection.’ If we can find bugs earlier in the cycle then we should! Driving quality upstream was a goal of testing more than 2 decades ago and it is a goal of agile testing/development today.

I agree that testing at the system level is important and is required to evaluate how all the pieces play together. But, if I can find these types of issues sooner in the development process that frees up my time to focus on other scenarios at the system level, significantly improves overall code quality, and may even prevent latent issues that may not be exposed via system testing.

[Bj's Reply] Hi Lixiong, just because we don’t see it doesn’t mean it isn’t there.

I also wonder if the PEX tool from Microsoft Research (or something like AgitarOne on Java) should be added to developers’ “unit test arsenal” to detect and explore boundary cases in unit tests.

[Bj's Reply] Hi Mark, Yes, I suspect that many unit tests are focused on “happy path.” In my opinion we should all be thinking about defect prevention and driving quality upstream. If I can find these types of bugs earlier in the process without significant overhead in my unit or component levels of testing then we know the overall cost of correcting the error is less.

Also, to paraphrase A. Hunt and D. Thomas, ‘developers don’t get paid to write buggy code.’ I think most devs (at least the ones I know) try their best to check-in high ‘quality,’ defect free code. (Of course there are ‘hacks’ who might be satisfied writing crap code and chucking it over the wall in hopes the some poor schmuck ‘tester’ will whack out their bugs.)

Also, you’re quite right; PEX is a very useful tool for .NET developers to include in our unit testing that might preclude these types of issues.

Isn’t “9999″ significant? That looks like some sort of boundary to me.

I’m imagining a developer, intent on a 4-digit limit…

[Bj's Reply] Hi Joe, if we add 0×1 hex to 0×9999 the value is 0x999A still 4 (hex) values. (I will be glad to get back to Redmond to take a look at what is actually going on here.)