Showing posts with label tester. Show all posts
Showing posts with label tester. Show all posts

Thursday, August 19, 2010

Relationships Matter - Tester and Programmer

This post is close to my heart. I dedicate this post to all the programmers I have interacted with. My official testing career is just over four years old. In these four years, I'm very lucky to work on multiple products and interact with many programmers. Initially, I was worried that I never worked on any product for a full release cycle. After few months I realized that this continuous swapping between products meant increased interaction with different sets of programmers.

First product:
The programmer was my friend. Both of us joined the company on the same date. I always got the news about the changes in the build, which feature would be implemented, confidence level of the programming team and many more *secrets* before they were officially announced later. He used to tell me the bugs in others' code and I used to help him by testing his fix before it went into the build. Both were happy with this *adjustment* until the project was scrapped.

Second product:
I was the only tester in this project and there were four programmers. By this time, I knew that programmers are a good source of information. I also realized that they are ready to talk about their work. They too feel proud on doing a good job. My interactions with this team was more informal. We had more Coffee day meetings than formal meetings. I gave them my test suite and highlighted the different scenarios. They taught me ways to analyze log files and answered all my questions about the product.

I worked on many more products and I'm very happy to say that my programmers like to work with me. I'll share some of the tips which might help improve your relationship with programmers:
* Remember that they are human beings first and then programmers. Give respect and take respect.
* Programmers do not code to introduce bugs. If you think programming is easy, exchange your job responsibility for few hours.
* As Michael Bolton and James Bach highlight, our job is not to prove them wrong or make fun of them. Help them understand that you are helping them and not finding faults.
* Give them the information which would help them solve issues easily and quickly. Improve your bug investigation skills.
* Appreciate in public when they fix a very difficult bug, on their good work. People like to be encouraged and appreciated.
* Be patient, listen more, complain less, help more, fight less, talk more, argue less, discuss more, work together towards one mission.

And don't forget: 'Relationships matter' :)

Leia Mais…

Saturday, September 19, 2009

A five minute conversation with a programmer

This is a post highlighting the conversation I had with one of my programmers.


Programmer (P): Hi Ajay! I need your help in reproducing the defect #abcdef

Defect #abcdef:
Step 1: ...
Step 2: Enter a value 50 in the text field.
Step3: ...

Ajay (A): Sure, How can I help you?

P: I'm unable to reproduce the defect.

A: Which OS are you trying it on? I had logged it on Win 2003.
P: Yes, I know that. It would be easier if I could reproduce that on Win XP.
A: (he he smiles) OK, I'll reproduce the defect first on Win 2003 and then we could try on Win XP also.
P: OK, great.

A: Step1, Step2, Step3 and here it is, REPRODUCIBLE!!!
P: Ok, let me try it. Step1, Step2 and Step3 and ??? Where's the defect?
A: Oh!!! Let me try again. Step1, Step2 and Step3 and again REPRODUCIBLE!!!
P: (Smiles) Step1, Step2 and Step3 : NOT REPRODUCIBLE

Silence for few seconds.

A: (thinking what could be different) Hmmm, maybe the speed with which I execute the steps is different from your speed of execution.
P: Maybe. Very little chance of that happening.
A: OK, let me try consecutive times. Step1, 2, 3: REPRODUCIBLE. Step1, 2, 3: REPRODUCIBLE.
P: Oh!!! How do YOU reproduce that Man!!! See, Step1, 2, 3: NOT REPRODUCIBLE.

P: Maybe you are pressing 'Enter' after entering the number.
A: Hmmm, I'm not pressing Enter key.
P: Then maybe single click causes this problem. Or maybe double click to select the field before entering the number.

A: (thinking WOW, so many factors!!! Let him go on)
P: Or this might happen if you select the text by 'Click and Drag' using mouse
P: OK, I'll look into this issue. Thanks for your time.
---------- END OF CONVERSATION ---------

This particular conversation refreshed my memory of how many different factors affect a single entry in a text field.

> Operating System
> Response time
> If the focus is on the field or not
> After entering the number, did the user press Enter or Tab?
> Did the user double click on the field to select the default text?
> Did the user delete the text before typing in the new text?
> Did he press 'Delete' or 'Backspace'

I'm sure there are many more factors related to the single entry in the text field.

The point I want to highlight here is "How useful is it to have a conversation with a programmer about the product?"

In my case, it was useful. Have you experienced such an interaction?
Do let me know.

Please feel free to share such experiences(Good & Bad).

Leia Mais…

Thursday, July 2, 2009

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…

Wednesday, June 17, 2009

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…