I know you'd have a test case for this !!!

Here is a question answer session for my blog readers.

Context:

The image at the right was taken at a ticket counter at Bangalore City Railway Station. Passengers wait for their turn to buy tickets. The officer inside the room asked questions like "Which station, Which train, Number of passengers?"

Once the passenger gave the details, ticket was given after collecting the fare.

There was a display put up to help the customer with details of the ticket.

Now, with the message : "There are unused icons in your desktop" overlapping the fare details/breakdown, some of the questions arise:

* Is it a bug? How risky is it to ignore such messages?

* Is the purpose of the display served?

* If the overlapping of the message on the display is a bug, will you fix it?

* What if it is not fixed?

* Which tester will think of these kinds of tests?

* Do you wear the hat of a non-tester and say: Hmmm, there is a workaround. I'll not fix it.

* I do not know how to fix it.

* It might be a bug but it is a limitation of the technology. [Cannot fix]

Finally one question:

"IS THERE A PROBLEM HERE?"

(Thanks to Ben Simo)

Please feel free to question, think, comment, argue and discuss :)

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…

Software Testers: Can you take up this challenge?

Do you like fame?

Do you test software?

Do you like to be interviewed?

Do you like to be featured on the Test Republic Forum?

Do you like to be appreciated?

Do you like to win prizes?

Do you like to test yourself?

Do you like to compete with the best?

Do you like challenges?

Do you have the confidence that you are a good tester?

If you answered Yes to most of the above questions, then read no further. Just click on this link and start testing your testing skills.

Good Luck.

Last date is 12th July 2009. :)

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…

Base state of a software application

This is a post on the importance of base state or initial state of a software application.
In the last post, I had mentioned about activating mobile office on my mobile.

I had not taken any note of the condition of my mobile connection settings. After I deactivated my mobile office, I was unable to access any websites on my mobile. After a lot of trial and error, setting up some other settings, I decided to approach the customer care and ask them to solve my problem. Finally I got it solved.

Observations:
> I was careless not to note the initial settings of the connection.
> I should have gathered more information about the new service(mobile office) as it did not support my access to wap enabled websites.

Connection with testing:
How many times have we come across a situation where we could not reproduce a defect or a behavior due to the change in the initial settings. We waste a lot of time reproducing the issue and finally realize that it was environment specific and had to ghost the system and start afresh. After this mobile experience, I realized the importance of noting the settings of my mobile. In testing, an environment of a test plays an equal role as the test itself.

Lessons learnt:
A tester has to know each of his test case/input. We never know which test may give the unwanted result/behavior.
How about running a test in our mind, imagining the probable consequences before running it in real. If testing was that simple, anyone could do testing.

Sometimes, we do need to probe a defect further to unearth even more critical defects. At the same time, we have to be careful to note the initial/base state of the application.

So, how do you deal with the ever changing state of a software?
Do you know each test you do?
How do you handle the issues you fail to reproduce at the first attempt?

Share your comments. And finally a question to you:
Is it necessary to know the initial/base state of the software under test?

Happy testing :)
-Ajay

Leia Mais…