Cloud Testing; How to Test on the Cloud?

Unless you've been living under a rock you must already be knowing that 'Cloud Computing' has been making a lot of buzz over past couple of years -- whether it your peer meeting, a client interview, a demo POC session with a prospect, the recent Red Hat Enterprise Virtualization Online Event on January 18, 2012 -- the talk about cloud is everywhere.

And why wouldn't it be? After all,  if industry analysts and virtualization experts are to be believed then cloud based computing and business solutions are going to be the NEXT BIG thing of this decade.

So I guess it is only natural if you find yourself to be asking yourself questions like 'what is cloud testing?',  'how to test on cloud?', 'how can we use cloud to better our testing?', 'how does cloud impact how we used to test before?' etc.

However, since all these queries pose different questions, the answers to them would be unique. For starters, if you are looking for cloud testing, it simply means a testing environment that utilizes cloud infrastructure for performing software testing.

How to leverage Cloud to Transform Software Testing?

If you are someone who heavily use tools while testing then IBM (IBM Cloud) and Hewlett-Packard have already jumped into the market for software testing in the cloud. Thankfully, if done smartly, cloud based computing can prove to be a great value-addition for both software development and testing. The reason is simple -- the very nature of a cloud based infrastructure allows for great team collaboration.

As an added advantage, cloud based testing (as well as programming) environments are easy to setup (on-demand). In today's tight budgeted IT world, this can be a much bigger advantage than it appears at first. It is no secret that IT managers are operating under a very tight budgetary constraint and when it comes to testing phase, the budget is even smaller.

Traditional approaches to setting up a test environment involves high cost to setup multiple servers with various OS, hardware configuration, browser versions etc. And if you are going to simulate user activity from different geographic locations you will have to setup test servers with localized regional language OS, which in turn can add up to the cost. But using cloud based infrastructure, the team wouldn't have to setup expensive physical servers -- rather, setting up new testing environment will be fast and efficient and VMs (virtual machines) and test servers can be launched and decommissioned as needed.

On the other hand, as a tester you might also be required to one of those ever emerging cloud based SaaS applications that aim to cater to various large and small customer base, on-demand. If you are testing such a cloud based application then your challenges are double-fold. Because, testing all the layers - from your application to the cloud service provider - is something that as a tester you will have to become efficient in.

As a closing note, if you are a tester and if you are intrigued by all these buzz surrounding cloud testing, then here are 2 main reasons why you might consider trying it out -- Cloud based software testing infrastructure  greatly helps in reducing capital expenditure and these testing setups are highly scalable , thus allowing your team to expand or decommission your test servers on-demand, as needed.

Are you someone already using cloud testing? Share your experience with me and other readers by leaving your comment below.

The Se7en Deadly Sins in "Software Testing"

1. Lack of "Lust for finding Defects" – Lust could be an objectionable vice in the Bible, but in the "Bible of Software Testing", lust is a good thing; lust for finding defects that is. Have a craving, appetite, or great desire towards finding defects is something that differentiates a great tester from that of a mediocre one. Once this lust dies down inside a tester’s heart, it would be very difficult to keep going. 

Having said this, I do realize that there could be times like the "tester’s block syndrome"  [a condition, associated with testing as a profession, in which a tester may lose the ability to find new bugs and defects in the software that (s)he is testing]. It can happen with anybody. But don’t let it become the end of the world for you. If you are struggling to find bugs in the software and feeling burnt out, "change the way you have been testing" – adopt new test ideas, try new ways to find where the AUT (application under test) might be broken, try out pair testing, explore new unexplored areas of the AUT and even try taking a short break. And still, if nothing at all works… then change your AUT! I know how difficult it can be to change the AUT (and your project) in certain contexts. In such cases, try out new applications (there are tons out there begging to be tested; just look around) and once you start finding defects in the new AUT, it won’t be long before you would start discovering defects (again) in your old AUT.

2. Envy – If you are in the field of testing then I can almost certainly bet that you must have come across testing teams where only few team members perform exceptionally well and the others instead of taking it as a reason of motivation rather feel envious about them. Enviousness and jealousy leads to hatred and hatred in turn takes you further away from the path to success.

3. Lack of "Greed for Knowledge" – Like lust, greed also is a good thing to have for a software tester. Some call it the "burning desire to learn" and others call it "the passion to excel", but to me they all mean essentially the same thing. Once some great mind said -- "knowledge is wealth/money". And it couldn’t be agreed more for software testing. I believe that a tester should be like a "search engine king", who is a jack of all trades and the master of many! As a test manager I would want my testers to be knowledgeable in every aspects of computing -- knowledge about programming languages, operating systems, web services, technology updates, gadgets, search engines, scripting skills… everything counts as long as they help the team to be better at testing.

4. Sloth – Laziness is not a luxury if you are in the software business; and the onus is even greater if you are a tester working in a tight testing schedule. In my opinion, this is one of the greatest sins a tester could ever commit – laziness in testing, laziness in learning new stuffs, laziness in updating your skills, laziness in showing interest in finding defects in what you’re testing… all can doom you and your career as a tester. So beware!

5. Wrath – Numerous situations may arise in a tester’s life where (s)he would find her/him against the team of programmers. But anger and wrath are never the solution to such scenarios. Hate the defects, NOT the programmer. Criticize the software that we test, NOT the programmer who coded it. And don’t ever forget that to err is human and if there were no errors, there would be no need for us (testers) in the team. Being diplomatic and factual with a small dose of humility can do wonders in dealing with any such adverse situations; NOT anger/wrath.

6. Pride – I can imagine how an occasional self-pat can help boost self-confidence and create room for the much needed motivation. But be careful NOT to overdo it and keep it at "occasional" level. Pride is probably the easiest gateway to witness failure and the feel-good factor associated with pride makes it even more dangerous.

7. Gluttony – Yes, I said that greed is a good thing for you if you are in the profession of software testing. But greed is not same as gluttony (over-testing, excess testing)! Learning to know where to stop testing is a lesser known art. If you didn’t find any new defects in the past hour of testing, then perhaps you wouldn’t find any, even if you extend the testing session for another couple of hours! In such cases taking a much needed break is a wiser decision than to extend the testing session. Furthermore, every test projects are associated with budget constraints and you wouldn’t probably want to make your testing efforts look like a liability to the whole project instead of adding value, would you?

What are the other deadly sins for a software tester that you would want to add to the above list? Share your thoughts via comments.

Seeing own 'tweet' in the Twitter 'replies' page! Is this a Bug?

Before I go ahead and publish this anomaly, let me clarify that this is an 'intermittent' issue that I have been seeing for the past few days. Though I have few screen shots to describe the happening of the issue, I'm yet to find out a reliable way to reproduce this. So good luck.

If you have still no idea on what twitter is then in a single sentence - 'it is the most happening micro-blogging phenomenon in web right now, which is redefining how people used to communicate with each other"! In case you have not joined there, I would recommend you to give them a try. It can be a very productive tool to collaborate with peers, colleagues, friends, clients and virtually everyone who is using Twitter.

This particular issue that I'm going to discuss today is basically an issue in Twitter replies page. I understand that they are doing lot of changes to their interface (both under and above the hood) and so this could very well be a manifestation of some regression bug. At any rate, here is what is happening [please click the screenshot to enlarge].

As I understand it, the @replies page on Twitter is supposed to list out ONLY those tweets that mention your twitter username (e.g. @MyTwitterName). But as you can see above, I'm seeing one tweet that doesn't contain my twitter username and rather is one that was tweeted by me! This is something that can NOT be treated as a reply. How can my own tweet be considered as a reply message aimed at me? Can someone make any sense out of it? What do you think? Can this be due to a bug in twitter?

Happy Testing...

Lessons Learned from “How I Fixed” Posts!

Yesterday during an online conversation, one of my blog readers expressed her concern: “Debasis, recently I have seen you posting 2 “How I Fixed” posts in quick succession. I wonder why you are deviating from your mission, considering “Software Testing Zone” is primarily a testing related blog”! I replied back quickly: “Well, why not? And no, I don’t think that I’m deviating from my mission to grow STZ as a testing-centered blog”!

If you are a regular reader of “Software testing Zone” and also wondering the same [why I have started writing these “How I Fixed” posts (first “IE 7 Operation Aborted Error” and now “MyWebSearch Spyware Removal”)], here is why…

I believe that technical investigation is one of the major responsibilities that we are often required to perform as testers. Personally, I love this aspect of testing more than anything else and I take pride in describing my role as a tester to be a “technical investigator” who helps the project stakeholders by providing important project related information that in turn guides the stakeholders in taking critical decisions. While trying to get rid of (fix) the above problems I think I did quite a bit of technical investigation to get around the problem and learned the following lessons that, in my opinion, can be helpful for a tester in her work:

a) How to maintain a cool head while being confronted with tough problems/situations.

b) How to narrow down the problem and get to the root of it. This particular skill can help testers while trying to narrow down the reproducibility criteria for hard to reproduce bugs.

c) How to engage in critical problem solving.

d) How to explore free information that is available via search engines and how to use them to your advantage.

e) How to use your observation skills to spot any subtle clues that can lead you to the error triggering condition of the problem.

f) How to use your critical thinking skills to pinpoint the problem.

g) How to use your lateral thinking skills to identify multiple possible causes of the problem.

I think each of the above lessons can also help someone in becoming a better tester. As testers, often we are required to do some research to learn more about a bug and do some investigation to narrow down it's reproducibility factors. As we all know, the shorter and crispier are the steps to reproduce certain bug, easier it is for the programmers to reproduce it and hence the chance of the bug getting fixed gets higher. Good technical investigation skills can also empower a tester to quickly nail down a critical defect that may be too subtle for a mediocre tester to spot and recognize. So overall, I think while trying to *fix* the above problems in my real life  I learned important testing lessons.

Moreover as Dr. Cem Kaner says, “The best software tester isn’t the one who finds the most bugs in the software or who embarrasses the most programmers. The best tester is the one who gets the most bugs fixed.” (~The Bug Advocacy) I thought, why not move one step ahead and fix the problems whenever we have the opportunity to do the same? I completely understand that as testers we seldom get the chance to fix the problems (bugs, defects, issues) that we find in the software. But while testing (problem solving) in real life I did recognize opportunities where I had the chance to hunt down the problem and at the same time try and fix it myself. Thus my recent “How I Fixed” posts took birth. At any rate, I like to solve problem that has the potential to tickle my gray matter and problems like the above proved to be worth trying. And I thought that it would be appropriate to record my approach in the form of blog posts as the documentary of the episodes!

Do you feel that this is against the mission of a blog that is supposed to be testing-oriented? Do you think that I should stop writing these posts? Do you think that I am deviating from my goals as a tester? I would like to hear you out.

Happy Testing… 

Confusing LinkedIn Status Update Screen when the Session is timed-out! Is this a Bug?

As if the number of post categories on Software Testing Zone were few, I am introducing yet another series of posts, which I have decided to call as “Is this a Bug?” In this series I am going to post a number of software anomalies that look suspicious and buggy to me. This series will be a kind of repository where I am going to dump all the suspected software defects and bugs that I encounter in my day to day life. When I post them under this category it essentially means that these are the kind of software failures that are ambiguous and one can’t be very sure if something indeed is a software failure or it is just the way it was designed to work! I would leave the final decision (whether this is a Bug or not) up to my readers and will just post here my observations. I think this is going to be fun. 

So here goes the first post of the “Is this a Bug?” series:

1. Login to your LinkedIn A/C (yes, you need a LinkedIn profile to be able to verify this).

2. Update your LinkedIn status. You can find the corresponding text box to enter and update your status on the home page, on the left side bar and elsewhere. “Your status was updated” message should be displayed by LinkedIn.

3. Now simulate a scenario of network failure. 

[Hint: unplug your modem and connect it back OR disconnect the connection and connect again OR simply logout of LinkedIn -> hit the browser Back button -> Page Refresh (F5) OR use your own ingenious method to simulate a network failure.] 

I had a REAL network failure and when I connected back to the internet I saw this rather confusing LinkedIn screen (please refer the screenshot) that displayed on one hand that *my* status was updated and on the other hand asked me to Join/Sign-In to LinkedIn. This is same as asking a guest at your door to come in and take a seat in your living room, offering her with coffee, chatting with her for a while and then asking her "do I know you?"!

[click on the image for an enlarged version]

What do you think? Is this a Bug? Feel free to share your opinion by commenting below.

P.S. If you had experienced such a bug?/not-a-bug? situation, feel free to Contact Me with the details (if possible screenshots) and I will try to post it on Software Testing Zone with your name.

P.P.S. This “Is this a Bug?” series is inspired by Ben Simo’s Is There A Problem Here? Blog. If you liked this post I recommend you to visit Ben’s Blog as well. Chances are very high that you would like it.

Happy Testing…

How I Fixed my Hijacked Firefox from MyWebSearch Spyware!

Update! For more such awesome Tips and Tricks do visit the Technology How To section. 

3 days back I was browsing a popular website and I spotted “Zwinky” (which is supposed to turn a photograph into a 3D image)! It did look harmless and hence I installed it willing to give it a try. If you read me regularly, then you might probably know that I prefer Firefox over any other browser. I had used Firefox while downloading and installing “Zwinky”. But my excitement was short-lived when I spotted a new web search tool bar (MyWebSearch) that was added to my Firefox toolbar without my permission during the installation. I uninstalled this toolbar and thought it was the end of it; but soon I was going to be proved wrong!

Sometimes later, while trying to lookup something in Google, I directly typed the search query into the Firefox location/address bar. Usually, it should have displayed Google search results or a direct website based on Google’s "I'm feeling Lucky" algorithm. But this time, I got this instead:

It was super-annoying because I couldn’t search with Google, my primary search engine and Firefox, my primary web browser. It was clear that my dear browser (Firefox) was hijacked by MyWebSearch, which was causing browser redirection to their site. What the hell? I went through all of the Firefox preferences (Tools --> Options) to see if I could change back the default search engine to Google but I couldn't find any such option! Searching in Google for “MyWebSearch” gave me loads of information about this spyware. Yes, I would call it a spyware because it collects and stores information about the web pages you view, the data you enter in online forms and search fields, the "clicks" you make, the IP address, URL and country of the sites you visit, your IP address, information about your browser and operating system, and the products you purchase online while using the service. Instantly I did a scan of my PC using “Spybot – Search & Destroy”. It did find some instances of “MyWebSearch” and claimed to clean it too. But when I started Firefox, I saw it remained hijacked! Damn! :(

"MyWebSearch" Spyware Removal - Getting rid of Firefox/Google redirect Hijack:

The most irritating thing about a spyware is that it can manage to hide in your system and thus hard to be cleaned/removed. And “MyWebSearch” appeared to be quite good at it. I did the following things trying to hunt it down:

1. I checked again in “Add & Remove Programs” list. It wasn’t there.

2. I did a manual search in the “C:\program files”. I didn’t find any suspicious folder here as well. I expanded my search to whole “C:\”, without any luck.

3. Now I opened the “Registry Editor” (Start --> Run --> regedit). I did a search (Ctrl+F) for “MyWebSearch” and found 3 registry entries. I deleted them after making sure that they were the ones I was looking for. To make sure I was not missing any more registry keys, I did a search for “search” and this gave me some more entries. Out of these most were genuine Windows registry keys. But I found 2 of them were pointing to “MyWebSearch” entries; so I deleted them as well.

WARNING! If you are doing this, please be very careful while deleting a registry entry. Accidental deletion of a genuine entry may result in corrupted Windows that can only be fixed via reinstalling Windows.

After deleting the relevant “MyWebSearch” entries from the registry I was almost sure that this time it was finally removed. I started Firefox and oops; I was wrong! It was still hiding somewhere and hijacking my search results everytime I tried to do a quick Google Search via Firefox location/address bar. I searched on Web in hopes of finding out a MyWebSearch removal tool. But most (all) of them described how to get rid of the toolbar, which I had removed already. I could hardly find any info that could help in getting back my hijacked Firefox. I tried HijackThis (a free spyware removal tool by Trend Micro) too. But it was unable to sniff out “MyWebSearch” in its scan result.

I was beginning to get frustrated at this point and suddenly another “test idea” came across my mind. I went to the configuration mode of Firefox by typing “about:config” on the location bar. But searching for “defaultSearch” in the filter bar, gave me “Google” as the default engine! Damn. Where did they hide the redirect hijack configuration then?

Baffled, I now keyed in “myweb” in the filter box and here it was. It showed me the entries where the user setting was modified to hijack the browser, without my permission.

I right-clicked both the entries, choose “Reset” and restarted Firefox.

Hurray! And now the search result is back to Google. I am glad that this nasty hijack episode is finally over for me. Sorry Firefox. You had to spend 3 days in hostage situation due to my stupidity (in deciding to try out a malicious program like “Zwinky”). If you are facing a similar situation of browser hijack and looking for a way out, feel free to try my above steps and let me know if it helped. 

Update! For more such awesome Tips and Tricks do visit the Technology How To section. 

Happy Testing…

Interviewing a Testing Expert - Phil Kirkham

I am back again with yet another interesting Interview with a Testing Expert; this time with Phil Kirkham (from UK) who is a Programmer turned Tester turned Test Consultant at Acutest. He writes about testing on his blog at Expected Results! He is a Moderator of Software Testing Club and Testing Reflections as well. I felt it would be exciting to interview him and when I approached him he was kind enough to honor my interest in taking his interview. Here is what Phil has to say:

Debasis: What led you to become a software tester? And what was the topmost reason that attracted you to the field of testing?

Phil: I was working as a programmer but the s/w we were sending out was of really poor quality and the customers were getting more and more irate. My boss knew I had a knack for breaking things and debugging so asked if I would help out with the testing effort. At the same time I was also thinking about a career change after 20 years of programming, I'd got a few career change books ( such as 'What Colour is Your Parachute' ) and realised that my personality traits and tester traits were a very good match. I'd also read a few testing books by then and started to realise that testing was more than just banging away on a keyboard.

Debasis: Did you try testing anything other than software before diving into software testing?

Phil: Funnily enough, when I left university I was on a graduate training scheme at a large company and was moved around various departments. One of the departments was testing a sea-mine clearance system which meant using a large device to simulate the noise of a ship.

Debasis: Tell me 5 unknown/least-known facts about you.

Phil: (i) I used to coach a girls soccer team. After that, managing anything else is easy.

(ii) I won a slogan competition run by a coffee company and the prize was a £10K holiday which was spent on 2 weeks in the Seychelles.

(iii) My first money making scheme was finding lost golf balls at Royal Birkdale golf course. That was a bit like finding bugs - you knew there were some hiding and you got to know the areas where they could be found.

(iv) I have a scar on the back of my right hand after I put it into an oven when I was 3 - unsupervised exploratory testing can be dangerous! :)

(v) My first website was set up over 13 years ago - all about footy and the girls teams I was coaching and my daughter was playing for. Some pages still exist [http://www.geocities.com/Colosseum/3562/wkham.html]. Doing this site taught me a lot about building a community, lessons I've tried to put into practice with the Software Testing Club.

Debasis: What was the hardest challenge that you faced in your career as a tester?

Phil: Trying to convince management to take testing seriously and that being 'agile' did not mean shipping out a program after testers had give it a "quick once over". That and trying to get a tester I worked with to read a testing book.

Debasis: Tell me about the most satisfying moment in your testing career.

Phil: Sitting in a meeting near the end of a project and hearing someone say that the testing effort seemed so much more professional now that I was involved. And someone adding onto the end of that that they wish I could be cloned. Also in an annual review having it noted that "Phil's testing efforts saved the project from disaster".

Debasis: Tell me of any situation when you had wished you were NOT a tester!

Phil: The end of year pay review when the CEO decided that because I was now a tester I shouldn’t get as big a raise as the programmers (despite the comments being made in the answer above).

Debasis: Has the profession (testing) ever affected your personal life? If yes, how?

Phil: Couple of ways. I can sometimes embarrass my wife by trying to break things when out in public - such as the self-serve machines in the supermarket.

And when I was trying to change the culture of a company from a chaos culture where testing meant bashing keyboards to somewhere where testing was given some thought I found I couldn't switch off after 5:30. The work/life balance was way off.

Debasis: What do you think as the most essential skills that make a great tester?

Phil: Desire and ability to learn and a passion for testing.

Debasis: How do you see software testing as a career, let’s say after a decade? What would be the biggest challenges for the field and what would be the biggest advancements?

Phil: I had a blog post called 'The 50 years old test' that showed that in some ways not much has changed. There's the techy challenge of keeping up with all the advances that allow programmers to create apps with a few lines of code and the challenge to get management to understand what proper testing can give. I'd like to see testing moving up the chain so it takes place much earlier and I'd love it if we got to the stage where we were never finding and reporting simple boundary value bugs.

Debasis: What single thing would you want to tell every newbie who is struggling in the early stage of building software testing career?

Phil: Keep going! I found it hard to break into the field [no ISEB certificate, being a programmer rather than a tester (implies I'd be too expensive)] and I'd been at the same company for 20 years. Then a company came along that wanted people who were passionate about testing and I was on my way. Thank you Acutest.

Debasis: Is there anything else that you would like to say?

Phil: I learnt a lot from the online community and got a lot of support. I'm trying to give some of it back and would encourage everyone else reading this to do the same.

Thanks Phil for taking your time and answering my questions. It is really interesting to hear how Phil was a Programmer and became a Tester, how NOT having a Certification (ISEB, ISTQB etc) didn’t stop him from advancing in his career as a tester and how his “Passion for Testing”, more than anything else, helped him in becoming a Testing Expert. I hope all of you enjoyed this interview as mush as I did. Any thoughts?

Happy Testing…

How I Fixed "IE 7 cannot open the Internet site - Operation aborted" error!

It all started from a reader’s email this morning. Duane Cantera reported: “When I try to open this web page I get an error message in internet explorer and the operation aborts.”

Emails like these are strange. They can send a blog owner into panic mode much quicker than an earthquake warning can possibly do; I was no exception. Before I knew, I had already opened Internet Explorer 7 and was opening the URL. The page started loading, as my eyes remained glued to the monitor screen and for a moment my heart raced like a speeding bullet. And boom! IE 7 crashed with “Internet Explorer cannot open the Internet site. Operation aborted.” message [here is a screenshot]. Clicking the OK button displayed "The page cannot be displayed" instead, thus restricting anybody from opening the blog URL! This was really shocking as well as unexpected for me. Shocking, because my blog was crashing in Internet Explorer [around 35-45% of my visitors use IE, mind it]. And unexpected, because I had NOT touched my blog template (HTML code base) in months, thanks to my current hectic schedules. And still here I was. All I could remember, my blog was working fine in IE 7, the last time I had checked. Hence, I was spellbound regarding what must have caused this. Instinctively, I did a Sitemeter and Google Analytics check and saw a 40% decline in my blog’s recent page visits. Damn! Must have been due to this IE crash.

But when all this was happening, the tester inside me was telling me not to panic and be rational. Quickly, I did a Google search for the above error message in IE and came up with some informative references. It looked like; it was an old bug in IE and could happen if your web page had many JavaScript code snippets (which I had many). But, still I had not edited my blog template in months. So the chance of this being a regression bug was almost impossible, in my case. Few more minutes of Googling and I came to know that this error has been reported and is now a "Known Issue for Blogger".

» I tried to follow Blogger’s recommendation to remove the “Follower’s widget” but in vain. I could not get rid of the crash.
» The more I searched in Google, the more suggestions I saw; to move all your JavaScript tags below the body tag, adding defer="defer" to your JavaScript tags… I tried them all, but still in vain.
» Even I saw suggestions to redirect the readers to Mozilla page to download Firefox. I considered this option for a while but felt that it would be too intruding for the readers.
» I searched for a patch from Microsoft so that I could redirect my readers with IE 7 there. I could not get hold of one. Instead, I came across a suggestion from Microsoft to upgrade to IE 8 instead.

I was getting tired and frustrated by now and decided to get back to my blog template code and see if I could find out the cause that was causing this mysterious crash. All I knew at this point was that this was happening due to a bug in IE 7 that caused errors while parsing the JavaScript. I didn’t have the luxury of loosing 40% of my blog readers just because Microsoft IE 7 had a bug in it and was having trouble parsing my blog template. As far as I knew, IE was able to parse my blog template till recently. As I had not made any changes myself, it had to be some third party script that must have changed and was causing this error out of the blue.

Initial investigation/testing into this issue suggested that:

» This was a problem with ONLY Internet Explorer 7 (and earlier versions) and not in Firefox, Chrome, Opera or any other.
» My blog’s homepage was opening fine in IE 7, but not the individual archived "post pages”. This gave me a test idea. I tried opening the label pages. And wow! They opened fine in IE 7.

This showed that it must be some JavaScript code snippet that was there on my “post pages” but was not on the “home”, “label” or “search” pages and was causing IE 7 to crash. I do use conditional display of some JavaScript widgets in my blog [using b:if cond='data:blog.pageType == "item"' tag]. But before scanning them, something else struck me as the possible culprit that differentiated my blog “post page” and rest pages. It was the “Comment Form”! Few months back, I had switched to the “Embedded Comment Form”. It had been working fine after an initial glitch (even in IE 7). But, it was also the one thing that stood out as the difference (as far as JavaScript code was concerned) between my “post pages” and rest pages. So, as a test, I changed my comment settings from “embedded comment form” to “pop-up”. And hurray! When I opened my “post pages” in IE 7, I no more saw any crash/errors. So I conjecture that Google/Blogger must have made some server side changes that affected it’s JavaScript code snippet that handles the “embedded comment form” and in turn it was crashing IE 7. I personally liked the embedded comment form and found it more user-friendly than the pop-up version. But for now, I have to change back and wait until either Blogger fixes it’s JavaScript OR Microsoft fixes the bug in IE 7 (the chance is low, as they have a newer non-crashing version in form of IE 8). So, I am hoping that Blogger fixes their embedded comment form code soon so that I (and many bloggers like me) can again use it without crashing our blogs in IE 7!

I must admit, it was a great and thrilling experience. Being a tester, it was frustrating to see my own blog crashing like a pack of cards in Internet Explorer. Though, the problem was with a problematic parsing error on the part of IE and a possible JavaScript error at Blogger’s end, ultimately I was loosing visitors to my blog. And it really feels great to have fixed the problem at my end in just 6 hours [Microsoft is yet to fix it in IE7 even after 1 year, and Blogger is yet to come up with a solution, mind it :)]! If you are a blogger and experiencing this problem, try if this post can help you fix it. And thanks a ton to Duane, for alerting me about this error.

Update1! Looks like the fix was not good enough to support IE 8! This is irrespective of Microsoft's claim that IE 8 has the fix that should take care (handle parse errors more gracefully by hiding them to the status bar and allow the user to continue browsing the web page) of the issue in IE 7. Thanks to Mistah Bonzai for alerting me about it. I have upgraded to IE 8 now and I could reproduce the "Aborted Operation" error, even though I was on Windows XP. Damn! Now what? Well, I don't know! Let me investigate more into this and I will update this post as soon as I have new information.

Update2! Looks like Blogger (read Google) and IE (read Microsoft) have signed a secret "no-offense; let's be friends" agreement! Out of curiosity, I reverted back to the Embedded Comment form recently and now IE seems to behave nicely without any "Operation aborted" error. I have confirmed this in IE 6, 7 and 8. And all 3 of them work fine with Blogger's Embedded Comment form now. I am hoping that this is a permanent fix. I will keep testing this compatibility from time to time and update this post in case I find anything unpleasant.

Happy Testing…