The testing paradox: blogger template migration

Recently I decided to implement a new layout for my TestingMinded blog. My blog is hosted by Blogger, so I had to use the default blogger upload template functionality in order to migrate my design. Blogger promotes their "push button publishing" concept. That's why I felt quite confident in migrating easily at a push of a button. At that moment, I had no idea which trouble I was about to experience.

The migration

Testing is my profession but on top of that I'm testing minded as well. That's why I decided to try out the migration on a dummy blog first. I did not want to go live with the new template without fully testing the template transition. Taking those precautions would grant me an acceptable level of trust.

I started out by creating a dummy blog and added a few Blogger widgets. Basically widgets are html placeholders and a user friendly way to manipulate the layout. You can drag and drop them easily to your taste across your html layout.
Next I decided to upload the new layout. Immediately after clicking the "upload" button an exception message "We're sorry but we're unable to complete your request" and code "bX-vjhbsj" were displayed.

Basically the behavior of the widgets was at the base of this problem. When you upload the new template, Blogger tries to link the widgets of the old layout to the ones from the new layout based on their id. You should know that many different possibilities exist on that level as widgets can have a different type and content. Either Blogger did not test this very well in advance, or they didn't expect such various kinds of templates to be used.

Soon I started looking for solutions on the web and found several potential causes for this problem, all related to the widgets. I tried out many, if not all, solutions but that just didn't help. In the best case the error message remained and the error code changed. For every new error code I again tried out other solutions but unfortunately it wouldn't work. During some my tests, the layout of the test blog got screwed up, and the blog couldn't even be displayed anymore. Meanwhile I had already spent hours searching for a solution and trying myself. I became frustrated as I didn't understand the exact cause of each error. And I became disappointed because it just wouldn't work for me.

After all those "lost" hours I decided to upload the new layout immediately to my TestingMinded blog. You may consider this as being desperate kamikaze attack. At the moment when I was ready to push the "upload" button I realized the consequences if the same problems would rise again. But being really stubborn I clicked the "upload" button and blogger showed following message "Your changes have been saved. View blog". I couldn't believe my eyes. Blogger claimed to have uploaded the template correctly. I clicked the "preview" link and to my surprise the new layout was correctly displayed on my blog. I only needed to move some widgets around and fix their content but that was nothing compared to the mess I dealt with before.

The disappointment

For the very first time I put so much effort into trying to find out what's wrong with an application, without having any result. I do admit, I could have contacted the blogger help team. But honestly I didn't feel like starting a long procedure without maybe even getting any response or result. Having a detailed error message shown to the user would have been better at that moment. I then would have been able to debug the upload functionality and maybe even find a workaround. Informing the user on the exact cause would of course reveal more of their Blogger application, as people would be better understanding the inner working of the upload functionality.

I'm sure I will not change my habit of testing before implementing a change. I did learn however that trying to debug the application yourself as test engineer doesn't always make a difference. If the application under test is well covering its internal working and is giving little information, you might be better off by only logging a defect without anything more. In some cases it's simply not worth to investigate all the why's and the how's yourself. Still I find it very frustrating to have experienced so many problems on my test blog, while I didn't notice any of them on my normal blog and knowing that the application didn't change. I guess that something we simply have to deal with.

How about you? What do you do when encountering an exception? Do you immediately log a defect or do you try to investigate the problem yourself first?
And have you ever found that all your effort put into testing led to so few results?

Related Posts by Categories


Recent Articles

Top Commenters

Recent Comments