Firefox: Directly add a feed to Google Reader

I use Google Reader to subscribe to feeds. And I use Firefox to browse.  However, every time I wanted to do that, I was presented with a dialogue where I had to choose between iGoogle and Google Reader. Today I searched on the net for a solution and lo behold, like everything else, this too was there.

Here is the post from where I have taken the suggestion http://bit.ly/23kSsz and here is the summary

i. Type about:config in the Firefox address bar

ii. Put the following in the filter field ‘browser.contentHandlers.types.2.title’. Double click and change value to ‘Google Reader’

iii. Put the following in the filter field ‘browser.contentHandlers.types.2.uri‘. Double click and change the value to ‘http://www.google.com/reader/view/#overview-page/view/feed/%s’

iv. Restart firefox.

note it…

From today on I am planning to write more regularly on my blog(s). To start with this blog…

I was asked to test a patch a few days back and I started testing it. The patch worked fine. However, I did notice a few things that I should mention here.

i. Make sure while testing you read the README.TXT file (or any other name by the which the accompanying instructions come). And yes, if there are no accompanying instructions please make sure you add one NOW.

ii. Make sure the instructions are as unambiguous as possible. I feel, more instructions are better than less.

iii. I saw some discrepancies in the ReadMe and I thought I will point them out – however the way we consider documentation to be less important, I completely forgot about it. However, my Boss – and that is why he is the boss 🙂 – noticed it and we made amends.

But that brings me to the title of this post – NOTE IT. During the course of testing, especially when we are talking about software products, we come across many issues that are subjective, unclear, not ready to be logged as a bug straightaway. We think we will file them or discuss them but just forget it. So please NOTE these things. Else they are not just opportunities lost for you to do a better job, they may also result in occasions where we did not perform our jobs.

Usability issue with telecom providers

I call a number and the lady says in a very sweet voice –

“Your phone call is being diverted because the Some-tel number you have called is currently” busy/out of coverage area/switched off.

The lady may also say (depending on the provider)

“Your are being taken to the voice mail box service since the Some-tel number you have called is currently” busy/out of coverage area/switched off.

Well I see, there are two important parts to this message and they are not necessarily listed in the order of importance.

i. Your call is being diverted

ii. The number you have called is not available for any one of the reasons listed above.

Now if I am a caller there are two possible outcomes of this use case

i. I am not able to reach the person on the number I called and I do not want to leave a message on his voicemail box or I do not want to talk to him or his relatives on the diverted number.

ii. I actually do want to leave a voice message or try and see if I can talk to him on the diverted number.

But most important of all is for me to know the status of his phone i.e. whether his phone is switched off or out of coverage area or busy. Sadly this information is revealed at the last and I have to go through the rigmarole of listening to the monotonous voice for 5 seconds before I know the status. Wouldn’t something like this be more user friendly.

“The <provider name (optional)> number is currently <any one of the reasons>. <Rest of the rigmarole>”

Curse of the QA

I have been working as a software tester for close to 4 years now. For all these four years I have worked in India for American clients. I state this to state the kind of experience I have. I have noticed a discernible sense of gravitation towards things that involve coding or programming and an equally discernible sense of indifference towards things that involve less of programming and more of testing. Inside testing too, automation testing is a sought-after skill and manual testing is a taken-for-granted trait. This proves the propensity, especially among software professionals, towards computer knowledge compared to business functions.

Testing professionals are partly to blame and the rest of the blame can be attributed to institutes and companies. While studying Engineering in Computer Science there was no emphasis on Software Quality as a concept – obviously the usual knickknacks about ISO and SEI were there. But nothing to dispel the notion which led almost 90 percent of all engineering college pass outs to say “I do not want to be a software tester but I want to be a software developer”. Our training sessions at our first jobs did not do much to change this mindset. Again software testing was a tertiary function. Somehow, it was ingrained in our minds that “code writing” is the only actual component of software development (Maybe software n code & writing n development were used interchangeably).

This has led to some characteristics that one often gets to see in projects.

1. Software testing is not considered cool and if you are into Manual Software Testing well you may as well be a crocodile – the cold blooded reptile which has not evolved over thousands of years. To be sure, do not gloss over the fact that it also makes crocs one of the very few species which has thrived without evolving.

2. Many “code writers” are unable to visualize a software project as enabler of a real life function. This leads to questions like “Why would the user do something like that” in response to queries like “why doesn’t your software support this particular scenario”. To be sure, the former is a valid response to the latter, if it is indeed backed up by real data.

3. Automation efforts are left mid way. The most cited reason is – the automation effort was started but the application was changing continuously (was not stable) and hence it was halted. Obviously , this reason is mostly cited in case of testing UI interfaces.

4. Voluntarily or involuntarily software testers are unable to breach the upper ceiling when it comes to understanding the inner working of the applications. They are able to understand the flow of the software and are even able to wear the actual user’s shoes but they are not able to understand the engine behind the shining car. In more complex applications, software testers are unable to conjure scenarios akin to real world functions – for example generating actual mashup scenarios for an enterprise for an enterprise mashup Platform. This results in thorough testing of existing functionality but falls short when it comes to finding missing or required functionality.

5. Some software testers who are able to breach the ceiling and are able to demystify the inner workings are unable to keep their understanding of the functionality and inner working separate. This results in justifying to themselves missing parts of the software. This is what I called the problem of “understanding” the code. Software testers SHOULD be in a postion to understand the code but they should always remember that they are paid to “not understand it”. Which means they should not use their knowledge of the intricacies to justify the application’s shortcomings to themselves. On the contrary they should use it to find the shortcomings and bring them to notice.

Do let me know your thoughts on my thoughts.

logging in – the usability quirk

I have talked about this with some colleagues but when it comes to opinions – the more the merrier. The interface to login to an application has a very simple logic to it.

i. Majority of the users are there to login.

ii. A few of them want to recover their password.

iii. A few others would want to check the “Remember me option” when they login

Therefore, my thinking says the flow of a login screen should be

User name(Text field)

Password (Text field)

Remember Me (Selection Box)

Login (Link/Button)

Forgot Password (Link/Button)

Isn’t it really simple? Yet I see so many websites messing up with this order. Since there are lesser number of users for the Forgot Password functionality as compared to Login functionality why would one have it before Login. Similarly, whether or not I want the website to “Remember me on this computer”  is a decision I need to make before Login. Why would someone do it the other way round and therefore why would you place Remember Me after Login?

I am interested in knowing your thoughts on this? Any more aspects to be included?

creating add-ons for firefox

[Main Link]

I have always wondered how to create one and am still wondering. However I came across this post and thought I will share it with everyone. I am still in the process of reading it and may take a couple of weeks to put what is written into action. However, my reasoning behind sharing it with readers on a software testing blog is that software testers should try and leverage automation to their advantage. Automation need to not necessarily entail a full fledged automation test plan and usage of “automation” tools.

If you do try out creating a firefox add-on do share your experience and opinions here. Even automation related opinions are welcome.

testing software product interoperability

I have been trying to write on product interoperability for quite sometime. So here it goes. What do we mean by product interoperability? In my opinion, interoperability of a product is its ability to function while different variables of its environment – software as well as hardware – are changed. Testing software interoperability assumes more importance for software products as compared to enterprise applications or services offered under SaaS model. Enterprise and SaaS applications are hosted in an organization or in the cloud, in both cases the deployment and network configurations and other such variables remain constant for a considerably long time – discounting exigencies, of course. Any change made to an organization’s IT infrastructure impacts all applications and hence we do not worry about it when it comes to a particular application’s interoperability.

Designing a test plan for interoperability poses many challenges due to the sheer number of possibilities when it comes to environment configurations. Let me try and find a method to this madness.

1. Identify the external variables:  External variables are what I was talking about in earlier parts of this post. What could they be?

• Platform/Operating System(including version)
• SDK version – if it is a Java application then JDK version, if .Net based then .Net framework version. For other software development frameworks, there may other criteria.
• Browser (including version)
• Proxy/Firewall/Security – how does the application handle them
• Application Server (including version)
• Database(including version)

I am sure there can be more variables that can be added here.

2. Identify the internal variables: Internal variables are configuration/customization parameters provided by the application. Such configurations tend to be specific to the application. Even common configuration parameters like authentication and authorization vary in their implementation and interpretation. Other configuration options may include file size limits or support for encoding formats. These features are very specific to the type of product being built. Technically intensive products and/or those that target the technically proficient user will have more handles for the user to use.

3. Understand the most used set(s) of configurations. This is an exercise in perpetuity because the data that we will rely on to arrive at our configuration set “may” change with every new client. This job can get very mind boggling because the tester inside us will pinch us to cover even remote possibilities whereas the pragmatic side of ours will ask us to keep track of time and effort required. It is important to strike a balance in this regard. This balance can be achieved by using scientific methods like Orthogonal Arrays – not to forget experience and market research. Once we have a probably list in place we are good to go.

4. Setup the configuration (at least most of it): Depending on resources at disposal this exercise in itself can be a point of innovation. Limited resources will push you towards more planning for resource sharing.

5. Create an interoperability test suite: Arriving at this test suite requires us to keep in mind the number of software testers in the team, the degree to which test cases have been automated, the number of configurations arrived at in step 3 and obviously the time available for this exercise. In my opinion, this test suite lies somewhere between the “eagle eye view” of smoke testing and the “devil lies in the details” style functional testing.

6. Automate test cases: Please do not start thinking of QTP, LoadRunner and WinRunner. Automation is much more than that. Identify what exactly do you intend to test with a particular set of test cases. Now, explore the possibility of repeating this set of test cases across multiple installations of your product. This could involve using a spreadsheet or flat file to store data for testing, writing batch/shell scripts with adequate comments so that we can take a look at the output and see which test cases failed and which passed. I have found Ruby+WATIR to be really simple for web-based applications (Thanks Imtiyaz).

Hope this helps you get started with interoperability testing.

Reproducing a bug ….the eternal quest

There are some really cliched problems which software testers and consqeuently software developers face as part of their job. Reproducing a bug comes right there among the top of that list. Recently,  I faced one such instance where I was at my wits end to reproduce a bug – needless to say, it wasted precious man-hours.

I was testing a MS Excel add-on and was unable to get it to work when requests where send through a proxy. I did what most software testers would normally do. But let me tell you the software that I was using – Windows Vista, MS Excel 2007, Squid Proxy 2.7.

To start with, I just repeated the same steps again and again hoping that a miracle would happen. Then I took the next step – Google.  I entered the error being thrown and got a lot of results. Not successful at getting an instant answer I faced away from Google. Let me tell you that during this time I had contacted the developer and he was using a different version of Office and a different OS Win XP .

I tried to test with Windows XP and the Office version used by the developer but still no luck.

Then I started doing what most software testers SHOULD do. I checked the squid proxy log and saw the error details. But could not make much headway. Tried again and then saw that there was some issues with the Squid Proxy version that I was using. I tried with an earlier version and lo behold it worked. So, what is the big deal. I think with a better approach we, the software testers and developers can save a considerable amount of time and avoid some frustrating moments.

Some bugs/issues do not need elaborate processes to reproduce because the problem lies entirely with the software you are testing.  E.g. If I try to login and the login code allows everyone to pass through, it will behave the same from any browser/platform.

However, in some other cases, the problem is caused by the software and components that it uses. What can be the dependent componets, JDK version, Platform (which platform? which version (including special packs), permissions), Firewall, Proxy (including authentication types), Databases (if being used).

A few instances that I can think of is:

1. database configuration – we were using mysql as the database backend and for some particular dataset the operation just failed. The logs and further Googling revealed that a setting on the mysql server and client side defines the maximum size of the packet that can transferred. The default value is 1 MB and it was failing when the packet size exceeded the default value.

2. jdk version – okay, this is specific to java based applications. In many cases, there are issues of jdk version mismatch – wherein the software is expecting one version but is forced to use another – which cause the operation to fail. If you are lucky, a simple change in classpath may do the trick in this case.

3. software quirks: We are trying to use the latest STABLE  version of a component your software depends on ,taking backward compatibility of the software for granted. This may not always be the case. Do remember, however, that if the software fails in this case the culprit could be the component or your own software. Let us say the standards have been updated and one of them does not conform to the latest.

It is very important for a tracking mechanism to ensure that such issues are searchable. Helps in creating test cases/scenarios not just for the issue under focus but for related areas too.

Setting up TestLink on Linux

I was assigned the responsibility of setting up Test Link (TL) on my network and import test cases from another instance of TL running elsewhere. It was quite simple but I would still like to put it down just in case someone runs into issues or better still if someone has suggestions – More than welcome.

PS: The commands may be Linux specific but there are very less reasons why it wont work on Windows too.

1. Lay out red carpet

Test Link needs some software to run. Main ones are:

i. MySQL – the database ii. Apache – the web server iii. PHP – the scripting language

The TL documentation itself suggests a nice package XAMPP (from Apache Friends) which essentially packages all these software and presents as a single piece of software – makes life much easier. I too would suggest the same unless you have special requirements. I used XAMPP for Linux and the installation is mere unzipping of the package using the following command.

tar xvfz xampp-linux-1.6.8a.tar.gz -C /opt

This unzips the XAMPP installation to /opt/lampp and this seems to be the mandatory location. Cursory digging on this led me to suggestions of creating a symbolic link to the folder in case you really do not want to install in /opt. Thereafter, you just do a xampp start/stop/restart for the usual errands.

2. Clean the red carpet

I am assuming you have downloaded Test Link ( I downloaded the latest stable release which is 1.7.4 at this point of time). Unzip the file that you have downloaded to the /opt/lampp/htdocs folder so that now you have the folder structure /opt/lampp/htdocs/testlink

Here are a few steps to pre-empt some issues that I faced when setting up testlink. They are in the order in which I faced the issues. 

i. Set register_globals to Off (by default it is On) in the /opt/lampp/etc/php.ini file

ii. Assign relevant privileges to the testlink folder. I do a:

chmod -R 777 /opt/lampp/htdocs/testlink

but you can choose to be more specific with the access levels and files

Now, run the TL installation from http://localhost/testlink/install/index.php

iii. Increase the memory limit in the following file /opt/lampp/etc/php.ini by changing the value in the following line to something that suits you. From my experience 32M works well.

memory_limit= 8M

iv. In my case, I was supposed to import the test suite from another test link instance. The problem I faced was during importing the test suite xml file. By default the limit on file size while importing is 200 Kb ( a test link characteristic). You can change this by editing the following line in the /opt/lampp/htdocs/testlink/config.inc.php file (information source)

define(‘TL_IMPORT_LIMIT’, ‘204800’); // in bytes

3. Clean the red carpet

Your TL installation is available on http://localhost/testlink

Linux Essentials

All of us who work on Linux but are not experts need help with commands. Here is a nice way to be reminded of them. Use this as your wallpaper. [Information Source]

Click on picture to get wallpaper