Firefox Beta Goes To 11 (Thousand)

When I got the heads-up from Josh and Duncan that the beta of Firefox 3 was now available, what put a twinkle in my eye was that Mozilla has fixed 11,000 issues with this release. I could not believe it, but here is the info directly from the source:

Firefox 3 Beta 1 is based on the new Gecko 1.9 Web rendering platform, which has been under development for the past 27 months and includes nearly 2 million lines of code changes, fixing more than 11,000 issues.

My first reaction was "How great and wonderful Mozilla is for giving us such a vastly improved product!" This was followed 2 seconds later by "Yikes! My most used application and the product my company has hitched our wagon to has at least 11,000 known issues!"

My next thought was "How great and wonderful the Mozilla test team must be for finding that many bugs and driving them to resolution." I doubt I've found anywhere near 11,000 bugs in my career, and I've been a software tester since long it was cool and hip. Even if these issues have been accumulating over the last 27 months, that is more than 10 bugs a day - and that is just the ones they fixed.

I then came to the conclusion that Mozilla actually has hundreds of millions of the best kind of testers - free ones - aka users. That is the only way they could find, track, and fix 11,000 bugs - with a strong and active community. So, my final thought was "How great and wonderful the Mozilla community is for finding and reporting all these bugs!" Mozilla should buy them 11,000 beers.

More on the Firefox 3 beta on Techmeme.

A Touch of Quality

I am not, by any means, an Apple fanboy. For most of my life I've been quite the opposite. A couple of years ago, I got a first generation iPod Nano, and thought it was fairly decent. Last year I got a MacBook and it has slowly become my laptop of choice - especially when I travel. When the iPhone came out, I was intrigued, even more so after getting to play with one. Since I am boycotting Cingular however, the iPhone would have to remain something I would admire from a distance.

So, you can imagine my interest when Mr. Steve announced the iPod Touch which had many of best parts of the iPhone but with no phone, and therefore no Cingular (now AT&T) contract. I resisted temptation for what seemed like a long time, but a few weeks ago I gave in and bought a Touch. I am heavy into gadgetry, so it really means something when I say that the iPod Touch is the

Best Gadget Ever.

This is a blog about quality, and I am here to tell you that the Touch is chock full of quality, both in the hardware and in the software. Lets start with the hardware. The thing is crazy thin. Even when I was 6'3" and 140 pounds (a long time ago) I was nowhere near this thin. Even so it feels solid and sturdy. The screen is plenty big and bright, and easy to read. The wi-fi is strong. Even though there are only 2 buttons, this is actually just enough, and I have yet to find myself wishing for more.

As good as the hardware is, the software is even better. Whether you are making your way through music, videos, pictures, or real web pages the navigation is thoughtful and intuitive. Even entering text is not that bad. The software is also very solid - and this from a guy who makes his living breaking software.

That is not to say the iPod Touch could not be improved. Some changes I'd like to see:

• A speaker - This thing begs to shown off and passed around, and so it would be real nice to have a speaker to play the music and video soundtracks so your friends can enjoy it without getting goo on your ear buds.


• Some games - These will be coming after Apple opens up the platform next year, but it would nice if they included some simple time killers from the get-go


• Attached mode - This is a bit unusual, but stay with me. Most of my iTunes listening occurs on my computer - the screen for which is taken up with stuff other than iTunes. Wouldn't it be cool if I could plug in my Touch, then use it as dedicated interface to control iTunes on my computer?

Good work Apple. The Touch is so good that I may actually break my Cingular boycott and get myself an iPhone one of these days - though I am going to *try* to wait until the next generation which I *hope* will be announced in January.

Seek First to Understand, Then to Exploit

The Seven Habits of Highly Effective Testers
Part 5 of 7

This is the fifth post in a series which is based ever-so loosely on Stephen R. Covey's book but focused on what you can do to be more effective as a software tester.

Customers don't have inside knowledge of how an app is designed, architected, or coded. That is why I've always been a big fan of black-box testing - it best approaches the way a customer will use the app. Still, there is something to be said for glass-box testing as well. Looking inside the box can give you insight into where the good bugs are.

Sitting in on developer meetings is one good way to gain some understanding about how the code is built. When there is disagreement about how something should be designed or coded, that means that the features being discussed will likely be target rich environments once they are ready for test. The more heated the argument about a feature, the more you should plan to test it. As an added bonus - after an hour in a developer meeting, you'll be even more glad that you are not a developer.

Unit test tools can also provide you some insight. If your developers are running these tools themselves, ask if you can take a look at the reports and logs. If they are not running any unit tests (which is another issue), look into running these tools yourself. Even if you don't totally understand the results, it is a pretty safe bet that areas with a higher density of findings will be more likely to have bugs, and therefore, more worthy of your testing time.

One other important thing you should know about the application you're testing is which developers were responsible for which parts. Like with any profession, there are good developers and not-so-good developers. By knowing what the weaker developers coded, you know where to focus your test energy. Likewise, you don't have to spend as much time testing stuff written by the more competent programmers.

By taking a little peek under the hood and getting and understanding of how the app is written, you can better exploit weak areas and find more bugs.

Previous Posts:
1 - Be Protractive
2 - Begin With the Vend in Mind
3 - Put Worst Things First
4 - Think When/When


Next Up:
6- Sinner Guise

Think When/When

The Seven Habits of Highly Effective Testers
Part 4 of 7

This is the fourth post in a series which is based ever-so loosely on Stephen R. Covey's book but focused on what you can do to be more effective as a software tester.


This post is about defect triage. I first learned abut triage from watching M*A*S*H. When the choppers and ambulances would bring in the wounded, the doctors and nurses would assess the men and decide who needed to get surgical attention first. These decisions would be based on the severity of the wounds as well as what part of the body the was injured. So a massive leg wound might not get precedence over a moderate heart wound.

When deciding when defects should be fixed it should work the same way, but it often does not. That is because of the confusion between severity and priority. Generally severity is measured on a scale from Sev1 - Crash the system to SevX - No harm to foul.

The problem comes when severity is the only factor that is considered. In such a situation, a bug that crashes the system but only occurs through a very unlikely usage scenario will get fixed before a more moderate problem that happens in a common user flow. Also, important bugs that are not especially severe will be deferred.

This is just wrong.

A better way that more advanced teams use is to assign a priority to each defects. To determine this priority, many factors should be considered. First and foremost, is severity, which can be assessed by the person reporting the defect. Also to be included is the likeliness of the defect being encountered by users. This can be determined by the support team with perhaps some input from the marketing folks. Another factor is the current workload of the specific development resources needed to fix the problem. This system therefore requires stakeholders from across the project to be most effective.

When these other factors besides just severity are considered, you will come up with a much better answer to the question of "When should this defect be fixed?"


Previous Posts:
1 - Be Protractive
2 - Begin With the Vend in Mind
3 - Put Worst Things First

Next Up:
5- Seek First to Understand, Then to Exploit

Put Worst Things First

The Seven Habits of Highly Effective Testers
Part 3 of 7

This is the third post in a series which is based ever-so loosely on Stephen R. Covey's book but focused on what you can do to be more effective as a software tester.

Lets face it, you usually don't have enough time to test everything that needs testing as thoroughly as it should be tested. That means that you will need to prioritize your testing to be effective. But what is the best way to do this?

A simple way to approach test prioritization is to use the one fifth method - where the test team consumes a fifth of whisky before test planning. Just kidding (as far as you know). The one fifth method involves asking yourself what you would do if the software needed to ship in one fifth the time you really have. For example, if you are supposed to have five weeks to test, what would you test if you only had one week? If you are supposed to have a week, what would you test if you only had a day?

Approaching the problem of prioritization in this manner will quickly lead you to the target-rich areas where you are likely to quickly find many bugs. By testing these first, you give the developers something to keep them busy, and also help ensure you'll have time to retest fixes.

Previous Posts:
1 - Be Protractive
2 - Begin With the Vend in Mind

Next Up:
4- Think When/When