A bit of house keeping..

I’ve been away for a long long time! So long that I forgot about this blog and I need to start from scratch 😀

I thought of putting the list of my popular posts below so that it will be easier for anyone finding my blog to quickly go through them. So, here’s the list (in no particular order):

















Hope that helps some one! And I hope you enjoy reading them. As always, feedback would be great.

Until next time, Happy Testing!


What we want from Devs?

Hello my dear Dev friends!

First of all, I would like to thank you for the code you gave us for Testing. Without your code, we wouldn’t have anything to test! I really appreciate the great effort you put in the research and investigation for each of the modules you develop. However, there are some things that I would like you to do “more”; which will make life easier for us, as a team. Here are my suggestions:

Read the Requirements and ask questions.

Pretty obvious, isn’t it? I know you are reading the requirements and I know you are asking technical questions about how to write the code according to the coding standards. But I’m not quite sure whether you are asking questions about how the “feature” you are developing is going to be used by the end user! Unless you don’t know how the feature is going to be used by the end user, your development is not complete. Please don’t say that it is the job of the testers to do that! Yes, we do that; but there is no harm in you doing it either. Now you might ask “Why should we do that?” Because, when you ask that question before you develop something, you are effectively minimizing/avoiding the rework that can happen for something that was developed is not fit for the user! What is the point of wasting your time and effort in writing code that is not fit for purpose? Your one question might save a lot of time and effort for the whole team!

Take responsibility for your code!

Hmm, that is also pretty obvious. It is hard to be 100% perfect, but there is no harm in trying. Try to set a benchmark for your code, set a challenge for yourself “I’m not going to allow any tester to find defects in my code”. Code like your life depends on it. We all are humans, and we make mistakes. Owning our mistakes and taking responsibility to fix it will only make life easier. You can be rest assured that you are not going to make that same mistake in your life again 🙂

Ask your Tester for help!

Alright, do you think we are your enemies? NOO! Understand that I’m trying to help you. You are developing the code, and we are trying to give you information about what didn’t go well with your code! That doesn’t mean that we are giving you more work in terms of fixing bugs and implementing new changes. Imagine what happens if the testers also miss an obvious defect in the code and the customer finds it! Yes, Testers get the blame first, because we didn’t find that bug. But, we didn’t code that bug in the application either! So who is suffering in the long run? We all are! Our Organization’s brand is at stake if we don’t do it properly. When we work together and find defects together, we are working on the same goal and we are working on making something that is good to be better! And don’t you know that when we interact well, the rapport increases and you can be rest assured that your tester pal is there to save your back even when you have made a mistake? Quality is everyone’s responsibility, right?

Read my bug reports to the full!

Yes, you read that right. Read the reports to the full. Because, like the code you develop is your output; the bug reports we write is our output. My personal opinion is that I consider myself a disgrace as a tester if you are not understanding my bug reports on the very first read. You have every right to shout at me if I’m writing poor reports. That being said, if you don’t read the reports to the full, you may not know whether it is written well or not. Just skimming through the bug report may not be enough for some complex issues. This is something similar to the first point we discussed. Not reading a bug report to the full and implementing a partial fix is only going to increase rework for the team!

Ask me questions!

Yes, we like to answer queries and explain scenarios (if you don’t find that boring ;)). There are chances that even a very well written bug report might be complex and you are not able to understand it. Come to us! We are all ears. Also, asking questions might help us realize that the bug reported is a big blunder or a duplicate. 😉

Communicate your changes!

Obviously, we all want to have the information on our finger tips. So, once you make a change and deploy those changes to the Test Environment, please send out an email or ping your tester buddies to stop testing. Otherwise, they won’t be aware of the change and it could result in unintended bug reports, confusion and a whole lot of mess. Yes, the same rework stuff we discussed earlier. Your tester buddies might be investigating some other issues or setting up the test data for an important scenario, and one change in the environment can sabotage all the plans. It is a good thing to keep your team informed about what you are working on and when you are making changes.

So, that’s it. If you could try to accommodate at least a couple of things mentioned above, that will make a difference! I am great fan of Dev-Test collaboration and the points mentioned are NOT intended to start a Dev Vs Tester war. I know that my Dev friends have similar points on “What we want from Testers?”; and I would be really interested to know them! Send in your feedback, comments, mails, tweets…. 🙂

Game Testing on Mobile Devices

This post first appeared in the Nerdy Tester Club guest blog section. You can read it here as well!

As you might have noticed, the mobile market is on a surge. There is virtually an “app” for everything in your life from budget planning to fitness! There are also thousands of games you can play on your mobile device. As a software tester, this mobile mania is giving you endless opportunities and I would like to share some tips for game testing from my limited experience.

1.       Know your device

So, you have the super smart phone – the iPhone 4S, the Galaxy S2, the Google Nexus S, the Nokia Lumia… Good! But do you really know what your phone capabilities are?

  • What platform is it running (iOS, Android, Symbian, Windows Mobile)?
  • Do you know its strengths and limitations (Processor speed, RAM, Storage Memory, Maximum application size, etc.)?
  • Do you know what type of connection can you use (Edge, 3G, CDMA, Wi-Fi, etc.)?

If you do not know any of the above, then I would suggest gettingas much information about your device as you can. This is not only applicable to game testing, but also to any type of mobile testing. But the device’s processor speed, RAM etc. are really important in playing your favourite games seamlessly. What’s the point of having that wonderful game if it is subjecting your device to lots of heating due to the increased use of processor power? You are not willing to let your 30K worth smartphone burn for a game, right? 🙂

2.       UI

With the ascend of tablet computers to the mobile world, more and more developers are creating their games and apps compatible for many devices with a single installation file. For e.g. you could download an app from the Apple app store which is compatible with both your iPhone and iPad. There lies the catch for us testers. There might be screens where the rendering is not properly done in an iPhone screen because the app is showing the page as in an iPad!

As you might have noticed, the games usually have really colourful UI and it is one of the primary things that make a game appealing. So you need to look at the colours used, fonts, icons, button size etc.

and finally;

3.       Fail intentionally!

Sounds interesting, right? You have tried so hard and succeeded in beating the computer opponent, and this so called tester is telling you to fail the game levels intentionally?

This could be your most important tip for testing games – learn to fail. Because, when you are failing intentionally, you might be subjecting the game to its most critical test – whether it can behave in the right way when you fail. You are getting competent and matching the computer opponent with all the concentration in this world, it is easy to miss out on what the computer opponent might do in case you fail. I have experienced instances where the computer opponent or your sidekick looked really stupid after I’ve purposefully failed my mission 🙂

Hope my little tips will help you in testing those wonderful games and make your testing much more fun. Have a tip which can be useful for the testing community? Share it!

Thank you for your time in reading my post. Your feedback will be most welcome 🙂

It’s tough being a Tester! Testing Circus article

The people at Testing Circus are doing a great job and the magazine has just published their Anniversary edition. I’m really glad and lucky to be part of those passionate people.

You can read my article along with a host of many others in the August edition of testing circus.. Grab your copy now from the following link!


Thanks for your time!!

Your comments will be much appreciated!

Who is breaking the AC switch?

Disclaimer!! The characters in this story are fictional. Resemblance to anyone dead or alive is simply coincidental!!

“Ahh! Not again!!” Yelled the Admin team’s Manager…

and he goes on…

“Are you all little kids? Who is breaking these AC Switches daily? If you are not going to tell, then we are installing security cameras soon. Then we will see who breaks this stuff…”

We look at each other puzzled – someone from ourselves is breaking this switch… But who?

Don’t worry mates – Super Tester is here for your rescue!! He will find it and punish the offender (Grrrr!!) 😉

Puzzled?? I will explain…

Hope you all are aware of the temperature control switches for the centralized air conditioners. In our office, we had our centralized AC’s controls hanging from the wall. So people changed the temperature at will – when they felt it was too cold or too hot 😉 As a result the switches began to malfunction and our Admin team had to replace them. Also they instructed the security people to operate these switches and locked them up in a small plastic box. Now, if the employees want to change the temperature, they must call the security guys to open this box and change the temperature 🙂 In addition, they stuck these plastic boxes to the wall with an adhesive tape, to look more aesthetic…

And these small plastic boxes are causing the yelling now a days 🙂 Everyday the Admin team finds 2 of these boxes stripped from the wall and hanging inconveniently. They will fix it again and the next day, the same thing happens… No wonder the manager becomes mad at these…

So, from the day our Admin manager started to yell, I paid close attention to what is happening with these boxes. But it is sort of an intermittent issue and I cannot always keep on looking at these switches.. I somewhat forgot about this problem, even though the yelling and complaining continued 🙂

We usually have our video conference with onsite colleagues weekly. I forgot about this meeting once and went for lunch. I remembered about the meeting when my friend called me on her way to the meeting room. So I finished my lunch quickly and ran for the meeting room. I remember my shoulder stuck something, but since I was running to catch up, I didn’t really care about what I broke. While returning from the meeting room, I noticed that the switch box is broken!!! Oh my god! I broke it this time, rather unknowingly, with my shoulder 😉 Ah! here’s the naughty kid who is breaking the switch box!

But I was sure that this may not happen every time you pass that corridor. You can see the corridor outline in the below picture:

AC Switch near door
My first thought was like, the door when opened hits the box and it falls. But that was not the case, since they have fixed it in such a way that there is no problem in opening and closing the door. But I was also sure that the box fell off because I hit it with my shoulder. So what is the scenario which caused it?

I tried to rewind what happened earlier…

1. I was running
2. I hit the box
3. It fell off

That is not so clear – let’s try again…

1. I was running
2. I had to open the door
3. I hit the box
4. It fell off

That is also not clear – since there is no problem with opening the door as I mentioned above… Let’s try again…

1. I was running
2. I had to open the door
3. But, I didn’t open the door fully – since I had to be quick, I just opened a quarter of it and squeezed myself in
4. I hit the box
5. It fell off

Wow! That’s an “Aha” moment – I remembered the movie Source Code while writing this. Rewinding and fixing your actions to find a mystery…

But this solves only half the problem – what is happening to the other switch box?

Here’s the next corridor outline:

AC Switch near the Printer  You might have guessed it – there is a printer sitting on the way and someone is hitting the box with their shoulder while avoiding the printer. That is somewhat true. But, the corridor is big enough for a person to walk without hitting the switch box even when avoiding the printer. Here’s what happens:

1. You are walking towards the wall
2. Someone is walking towards you from the opposite direction
3. You two meet exactly at the printer
4. The person near to the switch adjusts so that you two don’t collide
5. That person hits the switch with the shoulder
6. Depending on the impact, it falls off..


So, what testers find?

They find this, this and this

And they sometimes find and solve mysteries as described above..

Have they fixed it? Not yet 😉

SBTM, Context Free Questions and Rapid Reporter.

Hello folks, hope you are all doing well and had a cracking start to the New Year. The year started very well for
me, I had a chance to take up a project in more of a consulting way than our usual projects.

The projects I worked on last year are in a support phase now, so I could manage some free time almost every day.
It’s pretty boring sitting idle, right? So I’ve gone through some lessons on Performance Testing, read a lot of
James Bach’s and Michael Bolton’s blog posts. SBTM and Context free questions fascinated me a lot, but there were limitations of actually trying them out in our projects (that old test case running syndrome ;)). And, out of the
blue I get a chance to test one of our internal projects.

This project has been going on for a while and one of my fellow testers had the test cases prepared for it. He had
tested it as well. So here is my chance to go back to Exploratory testing and do what I like!

The first thing I did was to go through Michael Bolton’s Context free questions to help testing.  I had a thorough look at those questions and comments for the post and identified that all of them need not be asked in my scenario. So I trimmed them down to about 20 questions. This decision was made completely on a personal instinct. Here goes my trimmed list:

  1. Who is the customer/stake holder of the project?
  2. Do you know any problems that would threaten the value of this product?
  3. How much time do I have?
  4. When is the next release?
  5. When do you want the reports/information?
  6. How do you want the reports?
  7. When are you planning to launch this?
  8. Is there another application like this?
  9. What are the issues with the old application?
  10. What are the improvements in this application over the old one?
  11. Could you describe the functionality flow with a diagram?
  12. Has any one tested this?
  13. What all information are available to me?
  14. Is there some specific type of data processed by the application?
  15. What are your thoughts on this?
  16. Have you shown this to end users?
    1. What are their thoughts on this?
    2. What is their overall perception of the application?
    3. Is there any thing specific they wanted to be included?
  17. Is there any thing that I should avoid?
  18. Have you seen any error patterns?
  19. What usually is the common problem you face with these types of systems?
  20. Is there anything else I should have asked/I must be aware of?

I had a meet with the Product’s user champion and got the answers for all these questions. I was granted a week to
provide my exploratory testing report. My fellow tester had done a good job in testing this, and his bug reports and test cases were very handy to start my mission.

Exploratory testing is accountable – and I wanted to practice SBTM for this project. Since I’m sort of consulting for
this project on my free time, I was sure that the Debriefing part will be a problem as it was nearly impossible for me
to find some one to get this done. So I had to avoid the Debriefing part. But still, I worked on chartered sessions
and taking logs.

For taking logs, I used Rapid Reporter developed by Shmuel Gershon. I had used the Session Tester previously
for my exploratory testing missions. But having read a lot about Rapid Reporter through various blogs, I wanted to
give it a try. And I was really impressed with this nifty little tool (Thanks Shmuel!). I performed 6 chartered
sessions using Rapid Reporter and it was a great help in my mission. I really liked the automatic creation of that
CSV document, that was virtually hassle free 🙂 How I wish to publish one of those documents here, but I’m bound by NDAs!

So, all in all a great experience and I’m happy that I provided a worthy report to my user champion on the product.
I couldn’t continue my work on that product even thought they wanted me to 😦 A couple of other projects came up
which needed my attention. There is an offer to train a junior tester for the above product, which I’ve gladly
agreed. Hoping to pass on some good lessons. Will blog about it once I complete it.

Off Topic: It’s been a year since I started Blogging! Whoa!! 🙂 I want to thank all my readers/followers for your
encouragement, your support has been invaluable to this blog and my career as a Software Tester.

Until next time, Happy testing 🙂

Testing Challenge and X-mas Greetings..

Darren Macmillan blogged about a testing challenge a couple of months back. I found the challenge very interesting and wanted to know how my colleagues will approach it.

Our organisation has an active tester’s forum and a steering group to drive the forum. Being a member of this steering group, I wanted to get the reaction of my fellow group members on the exercise. So the challenge was sent as an Email to our steering group mailing list.

So here’s the challenge once again.. What is inherently wrong with the following form?

Testing Challenge - What is inherently wrong with this form?

What followed was very productive with mails flying all over! 🙂 The following points were noted first (and the most common answers):

SPOILER ALERT: The following discussion has the answers of the challenge. So if you seriously wish to take a dip into the challenge, then please do so and come back later to read this post. And I would suggest you to take a look at Darren’s post and comments. There are a few gems out there!

1. The form has an improper UI – poor layout, the heading is not relevant – ideally it should be payment info.

2. VISA is selected by default – ideally it should be “Select Card”

3. Labels in the form – what is MI? Expiration? It should be Expiry Date..

4. The Address line shows only one line as mandatory – both lines should be mandatory

Okay, the initial reactions are somewhat similar – mostly towards the look and feel. I was also thinking about these cases when I first saw the challenge.

I then got a couple of replies that really showed the functional aspects:

1. No country information and the currency is not shown

2. There is no field for a CVV code, which usually is a mandatory field for Credit Card payments.

I was really happy that at least a couple of people could look through the UI of the form and provide functional aspects of it 🙂 The purpose of the challenge was well served.

Now, you might be wondering how I fared in the challenge. Well, I missed the Country part, but could point out the currency and CVV code cases. I know, I still need to improve on that 🙂

The steering group did presented this challenge to our testers on our fortnightly knowledge sharing session. We divided them into group of three and provided challenges including James’s Series, Lynn Mckee’s spot the difference and couple of other cases and of course Darren’s challenge.

Almost all the groups of testers cracked Lynn’s puzzles. No one cracked James’s puzzle and nobody came up with the “inherrent wrong” of Darren’s puzzle. Most of the responses where pointed at the bad UI as discussed above. One of them even argued that the Country drop-down might be available in the next page since the button is “Continue” rather than “Pay”. I’m not quite sure about that – if that is the case, then there is a usability problem in there 🙂

We are coming towards the end of another year. I’m happy that I’ve started blogging, and proud to be featured and to be a part in the Software Testing Club‘s wonderful endeavour.. Hoping and praying for more good things to come in the next year.. 🙂 and…

Here’s wishing you a very happy Christmas and a wonderful year ahead..

And oh! – A special round of applause to Pradeep Soundararajan and Santhosh Tuppad for their endeavor in enlightning the testing minds. You guys rock!!

Until next time.. bye bye and take care 🙂