Three interesting bugs

When I started testing this feature, it looked quite simple. On a page, the user would be provided an option to view the default number of entries. This was helpful compared to the current UI where the default was set to X. Also, this feature was supposed to be a widget level change which meant that it can be applied across pages with minimal or no change. Also, one could jump to a particular page using a button.

The typical test ideas that came to my mind were:
- Change the defaults
- Compare with production
- Try every value
- Try combination of the Jump button and the drop down to change the default value.

But as I started testing, I discovered few interesting issues which I would like to highlight here:

Issue 1: Incorrect text displayed when the product of default value (drop down) and Jump to page value equaled 1000. The text read 'Displaying 1-1000' instead of 990-1000

First of all, I wanted the test data setup part to be automated. I wanted to have more than 1000 entries for my testing. Thanks to my colleague Vinod G Srinivas, who gave me a quick script to create X number of entries. This particular bug was present only for the value 1000 and worked fine for any value below 1000 and up to 2000.
For example:

This was an example of a bug at the boundary. Strange things happen at the boundary. To our surprise, this bug is existing in production. With 10 as the default, someone would had to navigate till the 100th page to see this bug. No one reported till now.

Issue 2: Action on records messes up the page count
For example, I have set 25 as the default in the drop down. I populate 26 records. I can now navigate to page 2. If I delete the record on page 2, I am left with 25 records and should be redirected to page 1. But guess, what happened? I was left at page 2 without any records and the text which read: Displaying 26-26 records.

Issue 3: Switch between default values displays incorrect records
Suppose I had 11 records and default was set to 10. I saw the results in two pages. Without navigating to second page, I expect to see all 11 records when I switch the default to 25. Everything worked fine till now. When I switched back to 10 from 25, I still saw 11 records. The switch back to 10 as default was not respected.

Think about these three issues. These don't look straight forward. You play with the software and slowly you get the ideas. And these bugs were interesting according to me. I had never predicted that I would have seen these issues when I first got the feature. And that is what makes me test - The uncertainty, the joy of exploration and investigation. Till next time, do share your interesting bugs. 

Leia Mais…

Less time? Map the bugs.

Last night when I came back from office, I saw the email from www.99tests.com about a one day contest on Android mobile. I joined the contest and observed that the max limit of bugs per tester was 15 instead of 25 (for 3 day contests). For every duplicate bug one logs, there is a -1 point. So, one has to be careful before logging bugs. And when I joined the contest, there were already 50+ bugs logged. I like to spend the initial few minutes of any contest, trying to understand the purpose of the application, the focus areas by the other testers and the validation strategy by the contest owner.

I wanted to go through every bug logged and at the same time understand the application quickly. I started with few bugs and then an idea struck me. Why not map the bugs and categorize the features too as parent nodes?

This is what I got after 25 mins:

Mindmap of Bugs

This way, I went through every bug and still made a high level model of the entire application.

I liked it and after three hours of testing, I got the 7th position with 100% valid bugs. I logged 6 bugs.

Maybe, there is a better approach but I liked the approach of mapping out the bugs before testing. What do you think? Do you have a better way?

Leia Mais…

Bugs - Stop following me!!!

Some not so good news: My mobile phone was stolen!!!

Good news: Time to buy a new mobile phone.

I had postponed the task of getting myself a new mobile for over a week now. I have dedicated some time from testing an iPhone app to buy a phone.

As a loyal to Nokia brand and after my friend suggested the 'Nokia 5800 XpressMusic' I wanted to know how the phone looked like.

Well, at 12:14AM IST, it is stupid to expect mobile stores ready to display a phone to any customer. The next option: Nokia India website.

After going through the specifications listed on the website, I started thinking about the following two points:

* How many customers would read the entire list of specifications.

* How well the author has *literally* sold the product on the website.

Back to my mobile hunt: First question: What is the price?

I hit the next website: Sangeetha Mobiles

The 'Search' feature of the website caught my attention.

I wanted to browse through the phones from Nokia and which cost between 5K -10K.

*Sometimes bugs follow you*

On selecting Nokia and 5000 - 10000 in the respective dropdowns & clicking on Search button, I'm greeted with this greeting: 'StockAvailable is neither a DataColumn nor a DataRelation for table .'

At 12.20AM IST, I'm in no mood for bugs after a to-and-fro journey from Bangalore-Mysore during the weekend.

As a tester, sometimes we are so used to bugs (which I feel is a trap and risk) that we neglect it and move on.

After the ritual(read screenshots, emotional bursts, careful reading...) I pressed the backspace key. On selecting the Price range : 5000 - 10000, and clicking on Search button gave a new greeting: 'Invalid postback or callback argument.'

I end my mobile hunt with two thoughts:

* I will give my best shot as a tester to help the stakeholders understand the impact of bugs.

* I will personally visit the store to decide my next mobile.

Till that time, I can be contacted on twitter , Skype @ajay184f

Leia Mais…

Weekend Testing Session Report.

Will it work?
Will it be good?
Will it be enjoyable?

Can we manage?
Will everyone benefit out of it?
Will everyone have fun out of it?
Will it be a learning experience?
Will everyone agree to our motto?
Will there be heated arguments?
Will everyone come on time?

How many bugs will we find?
How long the session it'll be?

How will we coordinate?
Do we need more than one software?


What if we face any distractions?
What if there is a power cut?

Ufff, all these questions were answered once the Bangalore Weekend Testing Session started.
Everyone came on time and wow what a session we had!!!!

Date: 15th August 2009
Session started at 9.30pm IST and ended at 11.30pm IST.

Testing session: 9.30pm to 10.30pm
Discussion Session: 10.30pm to 11.30pm

Every member participated actively and bugs flowed(literally) such that the discussion time was extended from 10.30pm -11.00pm to 10.30pm to 11.30pm IST. :)

I'll not hide the report anymore.
Please find the report shared at Scribd.

Most Important:
We promise to improve our bug reporting skills along with suitable screenshots.

Happy Weekend Testing!!!

Leia Mais…

Trio Testing at a distance - Part 1

Testers involved:
Ajay Balamurugadas, Sharath Byregowda and M V Manoj

Website Tested:
www.tinyurl.com

Mission:
To find bugs.

Start Time:
Aug 09 2009, 0022hrs IST

End Time:
Aug 09 2009, 0145hrs IST

About the website:
TinyURL is a web service that provides short aliases for redirection of long URLs. Kevin Gilbertson, a web developer, launched the service in January 2002 so that he would be able to link directly to newsgroup postings which frequently had long and cumbersome addresses.

Our Testing Session highlights:
The entire session was conducted over Group Chat on Gmail.
We started our search for a software to test around 1145hrs on Aug 08th 2009.
The search continued for an hour with Eyeos, Barcode4J and Piwik grabbing our attention.

Lack of prerequisites for the above softwares forced us to test TinyURL.

Bugs were communicated to the group as and when they were found.
The tests were based on learning from the tests conducted by the other testers.

Sharath's tests focussed on the security issues. Wish we had a proxy network setup. He'd have loved to test on a proxy network.

Manoj's tests focussed on the usability and Custom Alias feature. He highlighted the disadvantages of using Custom alias feature.

I focussed on the general functionality of the website.

It was fun testing coupled with good learning for me.
Though the testing session lasted for over an hour, the lessons gained would be for a long time. Thanks to Sharath and Manoj for their determination and passion at odd hours of Sunday.

Please find the testing report shared at Scribd.

If you would like to participate in such testing on weekends, drop an email to me at :
weekendtesting@gmail.com

Leia Mais…

Online or Offline??? Gmail or Gtalk doesn't matter

This is a strange behavior I observed while I was chatting online with my friend.

Application Used: Gtalk and Gmail chat

Reproducibility: 100%

Machine specific: No

---------------------------------------------------------------------------------------------------

I expect people chatting with me to reply within 5-10 seconds after I send them a message.

I also promise to reply instantly unless I'm not infront of my monitor.

It so happened that I sent my friend a message and I did not get any reply for a minute.

I got irritated by him not responding and I started banging the keys on my keyboard.

Infact I banged only one key - the DOT '.'

I pressed the '.' (DOT without quotes) and pressed enter key.

This continued for 15-20 times continuously.

Then these messages were displayed on Gmail chat window(pop up) and Gtalk application respectively.

As you can see on both the screenshots, the user is still Online indicated by the Green dot against the name.

And the message reads: "The user did not receive your chat" or "The user's email is offline and can't receive messages right now"

I liked this bug... Use of emotions helped me find this bug.

I don't really care if this is fixed or not but the behavior definitely brought a smile on my face.

:)

Leia Mais…

Simple Things Do Matter :)

I had to check a fix provided by a programmer to solve an issue.

I had to replace two files- One an .exe and the other .ini file.

Once I replaced the files, changed the contents of the files to suit my test and went through the steps to reproduce the issue, the issue was still reproducible.

So, I sent an email to the programmer that the issue is not resolved and the fix does not solve the issue. He wanted to have a look at my machine and try the scenario once.

Before handing over the control to the programmer, I copied the two files which were part of the test. This way I can compare the files after the programmer has completed his test.

The programmer was in Germany and was accessing the machine. I could not see what actions he was carrying out on the machine.

After ten minutes, I got a reply to that email that the issue is solved. Please re-test to confirm.

I was surprised and then along with my manager wanted to carry out the test. Before conducting the test, I wanted to compare the current file(after programmer conducted the test) and the file used by me to conduct the initial test.

And surprisingly, the contents were slightly different.

The initial file had 'Timer: 5:00:00 PM' and the new file had 'Time: 5:00:00 PM'.

Also, the programmer asked me to include an additional step so that the issue is resolved.

The additional step was to exit the service and run the .exe so that it may re-read the contents of the modified .ini file. I had not run the .exe after modifying the .ini file.

I replied back to him that the contents were changed and also the additional step was missed. These were the two reasons why I was able to reproduce the issue and he wasn't.

Learnings:

1. It is always safe to have a backup of files before and after conducting the test. Again it depends on what value this step adds to the overall mission. In my case, If I had not compared with the original file, there was very little chance that this issue would have been fixed before the customer found it.

2. Programmers have a natural tendency to fix issues on the fly. It is by nature that they fix issues and they do not consider it important to inform the tester about the changes. In my case, it turned out to be 100% true. The programmer never informed me about the change of text to 'Time' from 'Timer'.

3. I must have paid a bit more attention and come to the conclusion that the .exe must have been run to re-read from the .ini file. This taught me to relate the interaction between files & application to the tests I conduct using those files.

Simple things like having a backup of important files helped me find an important issue before it knocked the customer's door :)

Leia Mais…

Interesting defect

This is about a defect I found in my application this morning.

The application was not tested for a month due to some requirements change. I was shifted to test some other products and finally I got my application back.
There were supposed to be lot of changes introduced as per client request.

My application has a login window as soon as it is launched.The login window has fields username & password and OK & Cancel buttons.Username: guest, password: guest

So, the first test is as follows:Enter guest in the username field and guadt in the password field.Click OK.Observed Behavior:A window with the message 'Incorrect username/password.' popped up.This window too had a OK button.
I clicked on OK and clicked again on OK button in the Login window.

As stated in www.satisfice.com/rst.pdf slides 108 and 109, I wanted to test 'Error Handling'.I kept on pressing 'Enter' key in the keyboard.

This happened for more than 20 times and I was reminded of M.Bolton's statement in one of the post : 'Do the right thing after you have tried the incorrect thing' (Not the same words)

So, I thought of entering the correct credentials as I had tried enough of incorrect credentials and the application is not allowing me to enter.

I entered 'guest' in both the username and password fields.

Bingo!!!

The same window : 'Incorrect username/password' popped up.

I deleted the password and entered the password 'guest' again carefully and slowly.
Again the same message.I found something interesting here.

I went to the developer and asked whether they had changed the password and they replied 'NO'.

I closed the instance and opened a new instance.Entered 'guest' in both the fields and the application opened without any problem.
So, I realized that entering incorrect credentials and then entering correct credentials might reproduce this defect.

I tried entering incorrect credentials 10 times and the correct credentials at the 11th time. Application worked.
15 times, it worked.
20 times, it did not work, message popped up.
19 times, it worked.
21 times, it did not work, message popped up.

So, finally I logged a defect that 'After 20 incorrect logins, login with correct credentials also fails.'

Test Ideas that helped me find this defect:
Error Handling technique.
M.Bolton's statement.
Ben Simo's 'Failure' mnemonic

Have you ever come across such a defect?
Have you come across defects more interesting and wierd than this?

Please share the test ideas too as it may help others.

Scripted Testers:Would this defect be found by the execution of test case?

Feel free to question, discuss and comment.
Regards,
Ajay
www.enjoytesting.blogspot.com
ajay184f@yahoo.com

Leia Mais…