Monday, 15 March 2010

Another day and another Farmville bug. For those of you not been hooked into this game it's on Facebook and has 75 million players a month ( more than the population of France). As a social gaming phenomenon it's worth looking at just to see how and why it has become so huge ( that's my excuse anyway )

Anyway, for those non-Farmville players, the game has a facility where you visit neighbours farms and 'fertilise' their crops. As you do so a progress bar appears that indicated the percentage of fertilisation done - it usually happens so fast that you dont notice it. However, as I have the tester DNA I got the progress bar to go way over the 100% limit as you can see from the extended green bar in the screenshot above.

Nothing too remarkable about this defect. However it brought back memories for me of my programming days and a function I wrote 20 years ago. It was for a book pagination program and needed a status bar to show how much each area on a page had been adjusted. The adjustment range went from 0-100% and my function popped up a little bar coloured red if more than 50% had been adjusted, green if less than 50%. It involved a nasty little hack into some Mac assembler code but I got it working. Until that is some of the other programmers on the team ( no devoted test team in those days ) tried it out and found places where the bar would zoom way past 100% and extend to the edge of the screen

Twenty years on and still progammers are struggling to get a progress bar to stop at 100%....( and at least MY defect was caught before the program went live )

Sunday, 7 March 2010

Found a showstopper bug fairly late in the process which has got me wondering about how it could have been caught earlier

The defect description :

The app has an address book - one of the fields in the address book is for a mobile (cell for any US readers) phone number. Put a number in there with spaces in - some people like their numbers formatted that way.

From the order screen of the app, find this address and select it for use in the order. The order can have extras where you can include the mobile phone number so the customer is notified about the stages of their order. However, do not select this extra option - so the phone number is not needed and does not appear on the screen. Only the mailing address is used.

Process the order - the screen hangs. Go to the address book and remove the space from the phone number in the address book, save the address, find the address from the order screen - order processes.Go to the address book again, put the space in, press the 'use this address' button that is on the address book screen, process the order, all works fine. From the order screen search for the address, find it, process. Hangs

So what testing technique ( apart from persistence and some luck ) would have caught this ?Not having access to the code I don't know if a code review would have - the code seems to behave differently when called from 2 places and somehow the fact that there is a space causes the hang ( maybe there is some exception being thrown that is displayed to the user if the phone number is actually being used )

Would a detailed script have caught this ? It would have to be a detailed scenario - I can imagine scripts which check saving values to an address book and scripts that check that an entry can be used to populate an order - but a script that will check an order that uses an entry in the address book with spaces in it that is not actually used in the order ??

So it will go into my memory banks and be one of those tales told when testers gather to tell tales about bugs found. I'll pass the defect details onto the other testers on the team to see how they might have caught it. But in the end it will be another bit of local tester folklore - how can this be passed onto newbie testers ?