Adam White

To follow up my post on weak measurement being better than no measurement I decided to write some things I think can affect the ability of a development team to turn bugs around and hence make the use of the metrics from past releases not useful.

- Starting testing too early
- Starting testing too late
- Incorrect Risk Assessments by testers/developers/product managers
- Misunderstood Features by testers, developers, project team
- Constantly changing features (code churn/ greater risk of regression bugs)
- Inexperienced and/or Immature coders/testers
- Vacations/Sick days/Personal days/emergencies/snow days/Halo 3/WOW was released yesterday days
- Too many bugs carried over from last release.
- Unknown changes being checked in
- Misunderstood Features
- 3rd party applications cause problems
- Software licenses run out for development/test software.
- Busted Build process
- Product won’t install
- No business spec
- No Technical Spec
- Not enough hardware
- Incorrect hardware
- Not enough power to run the hardware
- Hardware/hardrives die unexpectedly (Does this ever happen expectedly?)
- Not enough People
- No Unit Tests
- Incorrect Time Estimates (oxymoron?)
- Miscommunication of vital pieces of information
- Features not cast/frozen/signed off on or otherwise stopped changing
- No requirements/Unclear requirements
- Bug system goes down.
- Internet connection goes down
- Power goes out
- Key stakeholders not available
- More time spent in meetings than fixing/testing software
- Customer problems take senior resources away.
- Meeting Interruptions/Coding interruptions/testing interruptions

It’s been a while since my last post. I’ve got lots to write about and not enough time to do it.

 The one thing I do want to mention is the upcoming CAST conference which will be held in Toronto this year. Some of the best minds in software testing will be at this conference. Speakers like Michael Bolton, Robert Sabourin, Jerry Weinberg, Cem Kaner. Not to mention I’ll be doing a presentation as well

The full program is available on the website – you can find it here http://www.associationforsoftwaretesting.org/drupal/conference

Make your reservations soon – Jerry’s tutorial is selling out quickly (if it’s not already sold out)

Why do humans insist on predicting things that are inherently unpredictable?

We can’t predict the stock market. Why not? We have years and years of past data. Data is the key right? If data allows us to predict the future then it’s simple – build a model of the market, test it on past data, and get rich. Right? Hmmm – something is flawed in that argument. I’m thinking that it might be a little more complex than that. I know that people build their lives around trying to do this – my experience tells me that very few of them ever become rich.

Jump over to software. There are people who believe it is possible to predict the number of bugs in an upcoming release of software based on the number of in the past release. The logic goes like this “We have 5 years of data in the bug system- so we should be able to predict the number of upcoming bugs in the next release. We can even predict how quickly we will be able to fix those bugs based on the time to close the bug.”Does this argument sound familiar? Why is it that people believe this – but don’t believe they can predict the stock market? Or worse they believe this and believe that the stock market can be predicted.

In software I often get asked how long the bug fix cycle of the upcoming release is going to take. I actually have no idea how long it will take and I don’t want to spend my time figuring it out. There are too many variables and too many factors to take into account to make any prediction useful.

The person asking usually appeals to authority or my ego saying “You’ve been around here long enough – you should have an idea” My answer is always – it depends. “Oh yeah – on what?” is the usual response Well – It depends on the number of bugs we find and how long it takes to fix them. Ask development how long it will take them to fix the bugs we find.

“Well we have 5 years of data in the bug database. How long did it take to fix the bugs we’ve already addressed?”

My point is that it doesn’t matter how long it took in the past. What matters is how long it’s going to take to fix the ones in the future.

“Well we can just average out the fix times across releases. Remove the high times and as well those done really quickly so we have a good statistical average.”

Taking the average of fix times defeats the purpose. Why would you remove the ones that took a really long time? Those are the ones you should pay attention to. They also won’t help you in predicting the fix times of the future. Do you really believe that the past data on bugs will help you predict the bugs in the future?

“Well -In the absence of a good measure I’d rather use a weak (read: bad) measure than nothing at all.”

Never give a number to a bureaucrat. Such is the state of (some) software businesses.

Here is a tool that no tester should be without – BBTest Assistant made by blueberry software. I love this piece of software. It helps you show bugs that aren’t “reproducible”.

One time we logged a bug about performance of a certain part of our app. We were dismissed and told we were being impatient and too picky. We created a BBtest assistant movie of the perfomance showing the delay the user would go through. Guess what happened after that? Yup – the bug got fixed. The proof is in the video….

Here is my bb test assistant video from CAST

Knowing what’s going on during a testing session is important. Some of the tools outlined in this video help you see the bugs sneaking around your computer.

I thought I would post some videos from the CAST 2007 testing conference. CAST stands for Conference of the Association of Software Testing. I was lucky enought to attend this past summer. At the conference there was a testing competition. The basic idea was we were given software and asked to test it. We had access to the developer and business owner (who happened to be the same person) as well as access to a bug tracking tool.

We could submit bugs using the tool and also gain extra points for doing a video presentation of some of the bugs as well as the techniques we used.

I wanted to toot my own horn here and say that we killed the competition. Nah – We pwned it!!!! My team (Team Canada) won first prize based on our bugs, techniques and test report. Unfortunately we couldn’t claim the $1500 cash prize because one person on our team was linked with the conference (in a very loose way). Thanks again Paul!!!!!

I wanted to post some of the videos that I was in during the competition. Here is the first one – talking about

Direct link to video

There are more to follow – so stay tuned. I may even post the videos of the others on the team if they give me permission.

Here’s a problem I need help solving.

How do you load test an application when the application makes remote calls to Windows machines, uses WMI to collect and return information and stores the info in a central database?

We can fake it by calling each machine more than once but this isn’t exactly the same. I can tell you the other ways we’ve tried to solve the problem creatively but I’d rather not get into that right now.

I’m looking for access to 4000-5000+ machines. The machines can be physical or virtual. They can be windows or linux. I’d prefer more windows than linux. A user account that has admin type privileges is required so that we can read the data off the machines (although someone else can type in the password so we don’t have to know it). The system has to collect data for 1-2 months.

On a side note – there are other types of applications out there that do this type of stuff. Does anyone know how they load test?   

 If you know of anyone who might know someone that would have access to this many machines or perhaps work on a product like cirba, or microsoft systems center (formerly MOM), or VMware’s consolidation planning tool – I’d love to talk to them (even if we make a competing product )

I’d like to show you a bug in iTunes. I’ve created a video to show this. This is the first time I’ve used a video to describe a bug in software (outside of my company). We do it all the time inside our company. Let me know what you think of this.

ITunes Delete bug

Picture puzzles are something I used to love doing. Life magazine recently released an entire magazine devoted to picture puzzles (find the differences). Until I saw this magazine I thought these puzzles were only for kids. As I flipped through the magazine I noticed the puzzles were more difficult than I remembered from my childhood.

I did some looking at home and found Life has some examples online

 http://www.life.com/Life/picture_puzzle/

Along the way I found this bug 

(more…)

I like cooking. It’s one of my passions. I also like software testing. It too is a passion of mine. While cooking one night I noticed that I was using things that resembled heuristics I use in testing. I don’t usually use a recipe to cook – whatever is in the fridge will do. I just “go with it”. The results are usually pretty good. Some disasters have ensued – but not enough to make me follow a recipe. The creativity in doing this really gets me pumped. I experience some sort of flow or zone when putting ingredients together – taste a bit of this, add a bit of that, stir, taste again, repeat. While testing I experience similar feelings.

(more…)