Release of my 4th book on software testing

I have released a book each on my mother's birthday followed by my sister's birthday and my birthday. Obviously, my father was feeling left out and I am releasing a book on his birthday. This is my fourth book on software testing.

Book 1: What If... A question every software tester must ask.

When I logged my first bug, I thought – ‘What if’ this bug was found after release? Years passed, many products were released, and I gained a lot of varied experiences.  I made a few embarrassing mistakes too. There were few instances where I wished that someone had warned me beforehand. So, I started preparing a book of tips targeted at software testers. Special care has been taken to keep each of the 22 chapters short and to the point. Emphasis is on ready-to-use tips which would give you instant results.

Book 2: What If... 50+ tips to win testing contests. 

This book is a collection of tips which might help any tester competing in a testing contest. Testers are under tremendous time pressure and the competition is tough. Skilled testers have a better chance of winning the contests. After participating in a number of testing contests, I realized that it is easy to win any contest if you dedicate some time and demonstrate the right skills. In this book, I have tried to highlight few points which will improve your chances of winning the testing contest.

Book 3: What If... 50+ tips to boost your productivity.

This book is a small collection of tips, tricks and list of tools to help boost your productivity. This is entirely based on my experiences in software testing as well as using computer. Internet is so powerful. A simple Google search will yield you so many search results. Google for “Screen Capture Tools” and you will find a minimum of ten tools in the first page itself. Which one do you choose? Do you have the time to try each one of them? What about Windows command prompts? There seems to be more than fifty commands. Which one is useful for us, especially for a software tester?

Book 4: What If... 50+ tips to improve tester-programmer relationship

This book brings into picture a very important person - the programmer & the programming team. Each one of us might have the experience of working with at least one tough programmer. Some programmers are very friendly and help us with finding bugs. Some of them are very strict with their deliverables and do not respond to any queries outside office hours. Some hardly talk to you unless you ask them a question. There are different types of programmers and bring in variety to our testing challenges. As I write this book, I have completed over six years of software testing and interacting with multiple programmers across different projects within and outside the company. With a rich experience of working with tough programmers, I write this book to help you.

My special thanks to my family members (for having a gap between the birthdays), my friends for accepting me as I am, my friends on twitter, facebook who keep encouraging my work, the programmers who keep challenging me, those who bought my first three books, those who provided me feedback and those who continue to believe in me :)
And of course, my love and thanks to my father who continues to encourage me in everything I do.

How to buy the books:
Download from bit.ly/booksaj

Leia Mais…

Developer & Tester on a Bug.

D - Developer
T- Tester

I have removed few confidential words about product/process. Other than that, this is a real conversation between a tester and a developer. Comments are welcome.

Leia Mais…

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…

Interesting Virus and funny bug investigation

Cool, the last post was not that bad when compared to a blogpost from web. In terms of the format, the last paragraph had 2-3 additional line breaks. Hopefully, I'll not repeat the same mistake in this blogpost.

Today I reached office few minutes late. Two of my team members had already started working on the build released on friday. I heard one of the two team members talk about Virus with the systems guy.

Incident No.1

I heard one of the two team members talk about VIRUS. I thought she was talking about the VIRUS character from the '3 Idiots' movie. On seeing the systems guy, I understood that its the VIRUS - the one we worry about. The network cables were disconnected and the systems guy was busy checking the security updates, patches and other vital information.
Hmmm, just when I thought 'one resource down' for the day, the systems guy was laughing loudly and my colleague was smiling. I was wondering what happened and what was so funny? The systems guy left and I went to my colleague to know more about the incident.

# My colleague had called the systems guy. Her exact words were: 'A pop up says that there are 7 virus detected and the xxxxxx antivirus has not detected the virus. Please come fast. I've disconnected the cables.'
# How could this happen? Why did the antivirus not detect the virus? How did the virus breach the antivirus barrier? How risky was this virus? How many files and computers were affected?
# Simple reason was: It was NOT a VIRUS. It was one of those funny ads on the website which tries to distract the user and install some junk toolbar on the browser.

No wonder the systems guy was laughing so loudly.

Learning:
1. My colleague was so focussed on the application under test that she failed to look at the bigger picture. Is this an example of 'Inattentional Blindness' or 'Lack of DeFocus principle' ?
2. She could have investigated a bit more before calling the systems guy.
3. She could have called for help within the team.

Incident No.2:
Colleague next to me had to reproduce a customer issue to the programming team.
What is the scenario? Let me describe it. Our software is used to print a photo and a footer with details of the photo. Around 4-6 lines were printed as the footer. The first line was for the title of the photo.
What is the issue:
The first line of the footer was not printed completely in Japanese language. The programmer was not able to reproduce the issue and the customer had attached a screenshot of the problem as a pdf file. The pdf file clearly highlighted how the first line of the footer was not printed completely.

My colleague's approach:
As he was not familiar with Japanese language, he wanted to reproduce the issue in English. He printed the pdf and found that the first line of the footer was not printed completely. An email was sent to the programmer that the issue was reproducible.
Five minutes later, the programmer was in my colleague's cubicle and what came out of the small discussion was a bit funny.

My colleague had printed the pdf without the footer setting. As the pdf had the screenshot of the issue, my colleague thought that the footer was not printed correctly. :)

Learning:
1. Carelessness or Lack of focus?
2. Pressure to reproduce an issue
3. Importance of bug investigation skills.

Two incidents in one day... Lets see in next blogpost if there are any other interesting experiences.

Leia Mais…

Do you TRUST the fix?

Something interesting happened when I was testing with my team.

One of the team members had logged a critical issue.

It was a bit complicated too. It involved a lot of parameters to consider.

After a week, the issue was fixed and the team member who logged the issue was verifying the fix.

After quite a bit of regression testing, I heard an interesting comment:

"Amazing!!! I'm surprised how could the programmer fix this issue without any side-effects"

Hmmm, it so happens that we expect the defects to be fixed.

And when they are fixed, we start questioning.

It is good to question but questioning everything.... being so skeptical... I don't know.

Maybe it is good some times but not always.

Do you TRUST your programmer and his fix?

Let me know.

Leia Mais…

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…

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…