Joining the pieces

How many testers can do this? I didn't see a lot of them in my career.

To take an example, there are few favorite questions that i always ask while interviewing for QA position (for SE-2 levels and above). One of them goes this way...

Two QA Engineers have installed the same Java based application from the same place on a Windows XP OS. For one of them, the application crashes during start, for the other it works perfectly. How would you go about debugging this problem step by step.

Most people stop after mentioning that they will check the logs or reboot the machine. Even after giving a few minutes time, they couldn't come up with different options to eliminate possibilities. I am not even expecting composite answers but simple ones like:

1. Check the location of install, is it in the same drive or different drive?
2. Are there spaces in the install location?
3. Are the two machines on same service packs level?
4. Are there changes in the OS settings, like firewall options?
5. Is the application picking the right JRE? Check the classpath to make sure no other JRE is affecting this.
6. Check all the processes that are running. Are there any issues with CPU or memory?

There can be numerous other things that we can check depending on our application, just the simple ones, nothing complex. When the application is same and the difference is only with the machines, isn't it simple to correlate and think of machine to machine differences and join the pieces. I think this is one of the major difference between a good testing engineer and others. Every day you will see bugs like this. Debugging and providing the right information will earn you the respect and not the bug count of this type saying "Application crashes".

Exposing your thoughts to external world

Until few months back, every time I search Google for something, I some how used to feel bad about myself. There are lot of people contributing lots of good stuff every minute and all this material helps me in some form or the other every day. I never contributed anything useful in blogs, technical websites or knowledge base until few months back. The excuse I used to give myself is, I am not so expressive especially when I have to write my thoughts and I am too busy. These are true to some extent but not blockers (excuse me for my testing language - I am used to this) to contribute.

Coming to another story... few months back, I want to check how many entries will be listed in Google when I search for my name (Srinivas Kantipudi) . To my surprise, there are quiet a few entries (both in web tab and images tab), some because of the presentation that I did in Eclipse Summit and some because of my contribution in Progress communities. My next thought was, how can I increase this count. I just have to contribute whatever little I know in various places. So I started with a blog (I have been postponing this idea since years) and then searched for some active testing sites and started contributing wherever I can. In few months, I see at least two pages when i type my name in Google. Surprisingly my blog had already started showing up in first page, a very nice feeling when i saw this.

Now I don't have to feel guilty when i Google for information and at the same time I am marketing myself by contributing whatever little I know :).

UI Automation does't mean...

Every time i meet someone who had mostly worked on back end, I had a hard time explaining them about UI Automation tools. All they think of UI Automation tools is that they are just a record and playback tools which checks the fields from UI and nothing else. This is same for a person who had only manual testing experience and never looked at UI Automation tools. Mostly they think these are some fancy tools for marketing purpose within the company. This is really not the case. If that's your experience or opinion, I think you did not actually use the tool properly or never worked on automation. Here are some misconceptions on UI Automation/tools.

UI Automation doesn't mean:

• Checking Button's and field's status
• A Record and playback tool
• Breaks for every simple change in UI
• Doesn't touch actual functionality
• Back end still needs Robust tests
• Starts only after the release or after everything is frozen
• Involves lot of maintenance
• Needs a lot of manual intervention
• There will be inconsistencies in runs

If any of your automation matches any of the above, then it's a pure misuse of the tool. Maybe you are not using the right tool or doesn't have the right plan. It all depends on us and not the tool, tools just does what we ask.

My Reflections - My Managers

In these 12 years of Journey in Software, I got a chance to work with some really great Managers. Every manager is wonderful... the way I am today is the way my Managers are with me. I am just a reflection of all my Managers (in work), everyone is so wonderful, I did learn a lot from everyone. There are few wonderful words/gestures which I remember every day, which I learned from my Managers from different companies and which I try to implement every day. Here are few of them.

1. One day I was very mad (didn't remember why) and went to my Manager. My Manager was very cool and told me, whatever you do, whether right or wrong, I will support you always. I believe in you, so go ahead and do what you think is right. That's like magic words which i remember every day. It gave me lot of confidence to fight for things that I think are right. If I don't have this kind of support, I would never had been a good tester. Of course the first thing you need to do is to earn this trust and it takes lot of effort to earn one's trust.
2. Support the team when they are in trouble - This was not explicitly told to me but learned it as my Managers implemented this. Be ready to take the beating yourself but don't let anyone touch or point your team if you really believe in the team/person.
3. Think of the question before you act - This is one of the wonderful things that I learned. Always think of question and see how you can beat the other person to death if they ask this question. If you don't have the answer, don't do the task until you find an answer or do it in an alternate way so that you won't get this question.
4. There is a right way to do things and there is also a way that everyone wants to see. I really don't want to explain this. You have to talk to me in person if you want details on this and you shouldn't be my Manager or Manager's Manager to know the answer.
5. Always be a role model to your team, especially if you are a lead or above. Your team tries to learn from you and will follow you in many occasions. Show the team why you are in this position. Work is the first main thing, gain the respect of the team by being on top of the work. Apart from work, there are million other things. Your dedication, punctuality, commitment and so on and so forth, everything counts and matters.
6. Never hire an average guy - One of my Manager always used to say this. Never hire an average guy. It's good to hire great performers. It's OK to hire a poor performer, we can fire them when they don't perform. Never ever hire average performer's, they will kill the company. You can't really fire them because they do their work. They really can't go beyond a specific limit and all the main load goes to the top performers and you over kill the top performers. This way the whole company will sink. So I am OK if you hire a poor performer but never hire an average performer.

Finally I will end with a quote that one of our boss in my current company always says - It has taken a lot of great people to make me look this good.

Journey of a QA Engineer

I have interacted with many QA engineers during my career and I still remember all of the QA groups that I worked with (5 in total) and our discussions on bugs, quality, certifications and QA during the initial days and there after. Here are some differences in the mind set of QA engineer (including mine) during the initial phase of the career and few years after.

Initial stages	Few years after
Passionate about every bug and fights for every bug and wants every bug to be fixed in the current release	Learns when to fight and thinks of release priorities
Automation is of no use, only helps while switching jobs	Automation does help when done properly, we need automation
QA Certification's will help in career	Certifications only teaches definitions, doesn't help
Process related things are boring, testing is only important for me	Process helps
Test plans are a waste, I can test everything without a test plan in an hour	Test plans are important, helps us in not missing out scenarios
It's cool to be a developer, I want to move to development	Testing is Cool, I will continue in testing
Everything is in my brain, why should i write a document	Documents are important and helps in maintaining the process

So next time, when you hear any of this from your colleagues, it's because they are in a specific phase in their career and it's common in that phase .

Can we replace Human Brains?

Last year i went to a Hysea conference and in one of the talks there was a mention of how there will not be any testing groups in two years or five years from now on. It was an interesting topic, atleast in the lecture or on the papers.

My mind did not agree to that statement at that time and I thought that might be because of the fact that I love manual testing. Even now, after one year, it's still the same. One year or ten years, I think products can't survive without manual testing. Can we really replace Human brain? Lets take an example... we need to test a login screen with valid user name and password. Can we say that there is no problem if we try with all valid inputs? There can still be hundreds of problems there. You can be extra smart and automate every possible case there and build a super computer to run all your billion tests. Can we still say that there will not be any other problem? Login might work but it might be taking 10 seconds instead of one second or the screen might be flickering a lot while logging in. How many of these can we automate? How many every tests you build, I still think that human brain can not be replaced. There is lot of judgement involved while testing. We question a lot of things. A smart brain can even narrow down future problems while testing. Machines just say Pass or Fail, good brains tries to see if there are other problems irrespective of Pass or Fail.How can we replace a brain with a tool or a machine?

Why do people honk on roads?

I travel around 40 kms a day and daily I start my car saying that I shouldn't honk at all but at the least I do it like 4 to 5 times in a day. I then started noticing the situations where my hands starts itching to honk. I mainly do it when the vehicle before me starts moving left or right without noticing who is behind. I then started noticing these vehicles and mostly this happens with vehicles that doesn't use rear view mirrors. So the persons inside these vehicles have no clue on what's going on behind them, they have no clue if they are blocking some one by going in the middle. When they want to shift lanes, they just start moving slowly towards right or left until some one honks and then they stop if they hear the honk. They have no complete control on the road, all they know is what's in front of them.
Now coming to work, are you the one who doesn't use rear view mirrors and so don't know what's going on around. Do you just do your work and doesn't look at anything else? If so aren't you working blindly, same as driving blindly. You don't know how other team members are performing or how you can outperform them. All you do is look straight and follow someone, doing everything in an orthodox manner.
Always be in control of your work. Look at your team mates, look at other groups, look at other companies and see how you can outperform all of them. Apart from your work and from all your research and innovation, also look around and explore new things, see how others are doing and try to beat them in their own court. If someone is highly regarded as good in testing, look at his/her bugs and see how they are doing and try to beat them in their strong fields.