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.
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
This clip is from a local newspaper I found during one of our trips to Niagara-On-The-Lake. I got such a laugh out of it that I wanted to share it.
Ever wonder what all those advertising terms really mean?
New – Different color from previous design.
All new – parts are not interchangeable with previous design.
Exclusive – imported product.
Unmatched – almost as good as the competition.
Foolproof operation – no provision for adjustments.
Advanced design – the advertising agency doesn’t understand it.
It’s here at last – rush job, nobody knew it was coming.
Field testing – manufacturer lacks test equipment.
High Accuracy – unit on which all parts fit.
Futuristic – no other reason why it looks the way it does.
Re-designed – previous flaws fixed, we hope.
Direct sales only – factory had a big argument with distributor.
Years of development – we finally got one to work.
Breakthrough – we finally figured out a use for it.
Maintenance fee – impossible to fix.
Meets all standards – ours, not yours.
Solid state – heavy.
High Reliability – we made it work long enough to ship it.
Rugged – too heave to lift.
A number of different approaches are being tried – we are still grasping at straws.
Customer satisfaction upon delivery is assured – we are so far behind schedule the customer should be happy just to get it delivered.
Test results were extremely gratifying – we were so surprised that the stupid thing worked.
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 good news on PlateSpin’s rankings across Canada. An annual poll by Deloitte put us at #2. Nice!
Read more about it here -> http://www.platespin.com/corporate/newsdetails.aspx?id=249
My company, PlateSpin, made the top 5 list on Profit magazine’s Hot 50 for the second year in row. Wow! It’s pretty exciting to see your company’s name in print on a list like that. It’s even more exciting to go through it!
Testing starts as soon as we have a build to test. If it’s checked in - it gets tested even before the features are deemed “Feature Complete”
Now - how do we track the bugs found during this stage of development? Up until our most recent proejct we’ve always used the bug tracking system.
Now weve been asked to stop using the bug system because it adds too much overhead. The explanation given is “A developer is working on a feature and you log bugs on it when they know it isn’t working…then at the end they have to go back through the list and re-test everything you logged to make sure it’s fixed. It adds too much to their plate.”
My first reaction to this was one of fear and anger. Fear because our development culture appears to moving towards information hiding. To me, as a tester, not logging bugs is hiding information. One of the main goals of testing at PlateSpin is provide timely information to project stakeholders. Without having the bugs logged in a central place for all to see it becomes more difficult to get the information to everyone. Also, for most testers, not logging bugs is equivalent to developers not checking in their code for several days. I wonder what kind of reaction I would get if I asked development to stop checking code in after code freeze?
Why the sudden aversion from development to the bug system?
In the previous release we started testing a feature that was clearly not ready. By the time we were done we had accumulated about 200 bugs on a particular feature. This added a significant overhead for the developers responsible for that feature. The aversion is understandable to a degree. We made an “amateur” tester mistake. We used a tornado to knock over a straw house.
After being asked to not use the bug system I stated my case that I thought this was a bad idea and gave my reasons why. Other testers did the same. We decided to go the route the developers wanted and not use the bug tracking system. Instead we said we would send out a daily (running) list of issues.
During a pre-release status meeting somone said “It would be good if we could number these bugs so we could just refer to the numbers”.
“I know a system that we can use to do that - and it doesn’t require any effort to use.”
Someone else suggested that the testers could simply use Word instead of notepad to write the list of issues. This would give them access to the handy numbered list. (Notice who had to change their work)
Then someone suggested “It would be really nice if we could have these issues in one central place”
“I have just the system for that” - I replied.
Then it was requested testers put the bugs in a project tracking spreadsheet. This sheet had the exact same headings as the bug tracking system. Hmmm - very curious indeed.
This is where I drew the line. We told the developers that if they wanted the information in the spreadsheet that we didn’t mind. We just weren’t going to do it for them. If they wanted to enter it - they were more than welcome to.
How many issues do you think got copied into the spreadsheet?
We haven’t hit our feature complete date yet so I can’t say how this little experiment will work out. We’ve had some developers complain to us for not logging bugs on their code. When they ask for screenshots and logs we have to say we don’t have them becuase have no place to put them and reference them to a bug.
I’m really curious to see how things go with our experiment. Our backlog is already 100+ bugs. The day of feature complete is going to a fun bug logging day! 
I mentioned above that we gave reasons for using the bug system instead of a spreadsheets - here are some of them.
Got any other ones we can use?