Today, I have half a dozen magazine articles under my belt, 300 pages of a (400 page) testing book, contributed a chapter in Beautiful Testing, and a foreword to JW’s latest (and have more secret projects on the horizon).

I started my blog here because it was an easy place to start a blog. For a bunch of reasons I won’t list today (some of which I’m sure will emerge in the coming months), this is the final post of my notes and rants blog.

Bye.

But I’m not done blogging. My new blog is here. Sorry – you’ll have to update your RSS reader to point to the new feed location too.

As far as I know, the content here will remain. I took the liberty of migrating a few of my more popular posts to the new location, but if you have personal favorites from my past, just let me know in the comment section and I’ll transfer them.

Slides are available here.

In the meantime, I strongly encourage you to check out http://testing.stackexchange.com. The cool kids among my readers will know that stackexchange is based on the stackoverflow.com site (and that I love, love, love stackoverflow).

But my love probably isn’t enough to convince you, so I’ll give you two good reasons why I think it’s so cool.

1. First of all, unlike “forum” sites where you have to figure out which forum to ask your question in (or which one to look for answers in), stackexchange discussions are flat – but are sortable in an infinite number of ways through the tags attached to the discussions. For example, over on stackoverflow, this link gives me every post about quality AND testing.

2. Points and badges are cool. Why do world of warcraft players grind on zombies for 6 hours straight? Because they want to get the cool purple hat! As you participate more on stackoverflow/stackexhange, you get points and badges. The badges are purely for bragging rights, but as you earn points, you get more privileges on the site (for the gamers in the crowd, think of it as leveling up).

Check it out – answer a question, or ask a question today.

I’m excited to see that the Chinese version of HWTSAM is out (and soon to be followed by a Korean translation).

You can find information here:

http://www.china-pub.com/196002

and on Amazon.

We’re working with independent analyst firm, voke, to conduct a market study on virtual lab management.  If you have a few minutes, tell them what you think about virtual lab management: https://www.surveymk.com//s.aspx?sm=LbWaKloP4hT1PNBIcx834w_3d_3d. All of the data captured is confidential, and information about receiving a complimentary copy of the report based on the survey is available at the end of the survey.

This has been a public service announcement – help out if you can.

I did have fun though, so at least one person in the room had a great time. My slides (which are nothing like the slides I submitted) are here if you’d like to take a look.

One of the other authors of hwtsam will also be at STAR. Ken Johnston is giving a tutorial and a talk. If you can’t tell from Ken’s writing, he can get a bit excited. So excited in fact, that he’s practically bubbling over at the opportunity to be part of a book signing on Thursday at 10:45am. Of course, I know better about these sorts of things, and don’t really expect anyone to actually show up to have a book they just paid retail price for devalued from potential ebay profits with some scribbling from a couple of writing hacks from a big software company.

But I have a special deal for readers of the blog who find their way to the land of Mickey Mouse this week. If you can track me down any time (outside of my talk Wednesday afternoon) and introduce yourself, you can have one of the two unblemished copies I threw into the vacant space in my bag this morning. Better yet, I promise not to sign it just in case you want to sell it for profit and get a better deal. If you’d like to increase your odds by handing me a beer (preferably cold and full), your odds will increase. Depending on Disney-net access, I’ll update the post when the book is gone.

The other book goes to the best question during my talk. Winner is karentobo - thanks for the support Karen.

Many bugs aren’t worth fixing. “What kind of tester are you”, I can hear you shout, “Testers are the champions of quality for the customer!” I’ll repeat myself again (redundantly if I need to …) Many bugs aren’t worth fixing. I’ll tell you why. To fix most bugs, you need to change code. Changing code requires both resources (time), and it introduces risk. It sucks, but it’s true. Sometimes, the risk and investment just aren’t worth it, so bugs don’t get fixed.

The decision to fix or not to fix isn’t (or shouldn’t be) entirely hunch based. I like using the concept of user pain to help make this decision. There are 3 key factors I consider to determine user pain. These are:

1. Severity – what’s the impact of the bug – does it crash the program? Does the customer lose data? Or is it less severe? Is there an easy workaround? Is it just a cosmetic issue?
2. Frequency – how often will users hit this issue? Is it part of the main flow of the program, or is the issue hidden in an obscure feature. Minor issues in mainline scenarios may need to be fixed, but ugly stuff in an obscure feature may slide.
3. Customers Impacted – if you’ve done your work up front, you have an idea of who your customers are, and an idea of how many users are in (or how many you would like to be in) each of your customer segments. From there, you need to determine if the issue will be hit by every user, or just a subset. If you have the ability to track how customers are using your product you can get more accurate data here.

From here, make up a formula. Assign a value scale to each of the above and apply some math – you can do straight addition, multiplication, or add weights based on your application and market. For our purposes, let’s just add and use a 10 pt scale for each bug :}.

Bug #1, for example, is a crashing bug (10pts) in a mainline scenario (10pts) impacting 80% of the customer segment (8pts). At 28pts on the user pain scale, I bet we’re going to fix this one.

Bug #2 is an alignment issue (2pts) in secondary window (2pts) in an area used by a few “legacy” users (2pts). At 6 pts, this is a likely candidate to not get fixed.

Unfortunately, they’re not all that easy. Bug #3 is a data loss bug (10pts). It occurs in one of the main parts of the application, but only under certain circumstances (5pts) (btw – numbers are completely made up and subjective). Customer research shows that it’s hardly ever used (2pts). At 17 pts, this one could go either way. On one hand, it’s probably not worth the investment to fix. As long as the issue is understood, and there are no blind spots, leaving the bug in place is probably the right thing to do.

On the other hand, you have to weigh this with the rest of the bugs in the system. The Broken Window theory applies here – if there are too many of these medium threshold bugs in the app, quality (or at the very least, the perception of quality) will suffer. You need to consider every bug in the system in the context of the rest of the (known) bugs in the system and use this knowledge to figure out where the line is between what gets fixed and what doesn’t get fixed.

It sucks that the industry ships software with known bugs – but given the development tools and languages we have today, there isn’t a sensible alternative.

Edit:

As this sits in my head, I think I've missed a fourth factor in the forumla: Ship Date. The proximity of ship date plays into the fix/don't fix decison as much as the above. I'm not sure, however, whether it's a fourth factor in the math, or if the threshold of what "value" of user pain turns into a bug fix as ship dates approach.

Edit: 3/30/2010: This entry is also posted at my new blog - http://angryweasel.com/blog/?p=6. I'll open comments there if you want to add or discuss.

Of course, Phil’s list overlaps mine, so instead, I’d like to present:

7 Influential Books that Phil doesn’t Mention

1. The Feiner Points of Leadership – Michael Feiner One of the Technical Fellows at Microsoft recommended this book to me a few years ago, and now it’s one that I re-read often. The book is filled with lessons – and more importantly – practical advice.
2. Peopleware – Tom DeMarco and Anthony Lister Every person who manages teams or people – or cares about how people are productive should read this book
3. Testing Object-Oriented Systems – Robert Binder – This is probably the largest book I own, but one of my favorite testing books. I have a love for patterns and models, and this book covers both fantastically
4. The Dilbert Principle – Scott Adams From an anti-pattern perspective, this is one of the best management books in print. This book covers far more than cartoons – Scott Adams understands management far more than many of the managers I know
5. The Inner Game of Tennis – Timothy Gallwey – I discovered this book when I was a (sort of) musician. The author wrote a follow up for musicians, but the tennis book is the best. The premise is that performance = (potential – distraction). Most people try to improve only by increasing their potential. Gallwey’s premise is that you can improve your performance by decreasing distractions through focus and visualization.
6. An Introduction to General Systems Thinking – Gerry Weinberg – This is an easy one to mention – I almost feel like I’m cheating for including it, but I can’t leave it off (and I have to take advantage of Phil picking a different Weinberg book for his list). You’d be surprised how you view things differently when you can think of a system as a whole (this happens, of course, after you can identify a system in the first place). If you can’t do either of those, start with this book, practice, repeat.
7. The Pragmatic Programmer – when I talk to programmers and testers, this is probably the book I mention the most. The writing is good, the concepts are good, and it’s full of great advice. If you aren’t fluent with boiled frogs, broken windows and tracer bullets, you have to read this.

I almost bumped Scott Adams to include Maguire’s Writing Solid Code, but as much as I like it, it just doesn’t come up in conversation as often as the others. For every book on this list, I can name at least a half a dozen people that I know who share my love of the book.

So – that’s my list. What do you think?

The advantage of being in a niche profession is that there’s plenty of room at the top. The problem, of course, is that a ton of dolts and wannabees self-proclaim themselves as experts and leaders and assume they’re at the top. They come up with new ways to describe what they do (e.g. sanitation engineer), and tell everyone who uses the old terminology that they’re idiots. Meanwhile, the real experts are the ones usually advancing the profession. The connected world we live in enables the loudest voices to be "experts" regardless of ability to do the job.

Interesting world we live in – isn’t it?