Monday, January 05, 2009

Context Driven Testing gets a boost – to grow stronger…

It is a fantastic "new year" gift (and also week end feast to many like me who is spending better part of Christmas/new year in front of laptop) to all testers… Dr. Cem Kaner (along with James Bach) has posted about context driven testing with some new definitions and articulation. I belong to context driven testing community with many others. Context driven testing community has proclaimed its philosophy, guiding principles since its inception. As years went by, various groups of people (quite a few "unidentified" ones) started pushing false propaganda about our community. This I believe might have driven Cem and James to "rework" the original principles and overall articulation about context driven community.

I have personally been part of many discussions, where I heard people just attacking the theme of context driven testing by saying "Everything in this software world happens with the context. Only a fool would work without context … so talking big and calling oneself as context driven tester is no big deal. Context is forever one … every one applies the context to best of their ability and knowledge". The new articulation of "Context aware" - attempts to describe such people. If you think about a practice first, then tailor/modify that practice to the context – you would be a "context aware".

Another interesting point this post makes is that some people in agile software development community have found so much common with context driven testing that they were claiming agile and context driven testing as one and the same. With so much focus on people and their interactions – agile and context driven testing can be said to have common roots – "people focus" (as against process/standards focus). I would say Cem's articulation could have been much stronger when it comes to the differences between agile and context driven testing. Insistence of 100% automated unit tests, compulsory standup meetings, TDD is a must and all sorts of "standard" stuff is clearly deviation from agile manifesto (choice of people over Processes) as articulated by James Bach in his STAR West 2008. I see context driven testing community distancing from agile community on these areas …

Also look the new, cracked definition of context driven testing – "Context-driven testers choose their testing objectives, techniques, and deliverables (including test documentation) by looking first to the details of the specific situation, including the desires of the stakeholders who commissioned the testing." I am sure most of my friends who are not in the CDT (context driven community) will say … oh yes … that is a common sense. We work for stakeholders, customize our testing approaches to context … what is big deal? Why are you making common sense a big thing?" My response to such people would first "so called common sense in this case is not so common … so there is a big deal here. Secondly, thinking about practices first then context is "context aware" not "context driven".

Critical Focus on "best practice" has been rather mild I would say (appears in only 4 times in the post). Cem, apparently left the proponents of best practices, lightly by saying "Context-driven testers reject the notion of best practices, because they present certain practices as appropriate independent of context…. However, when someone looks to best practices first and to project-specific factors second, that may be context-aware, but not context-driven."

Context imperial testing is somewhat similar to what I normally refer as "goal displacement" (a term I learnt from James Bach). Instead of designing and adapting the practices to project /organization/group context, Context imperialists would RATHER change the project/group/organization itself to suit the "best practices that they are aware of. A recent example … someone said, we cannot afford to do testing this way as it will not allow us to collect the metrics that we need, so let us change the process so that we can collect and use the metrics". It is sad state of affairs that, people will get away with such "context imperialism".

Context driven testing community's view point on "detailed specifications, detailed test script documentation etc" has always been perceived as "means to promote exploratory testing". Many people, whom interacted, would immediately say "Oh!!! You mean to say do exploratory/adhoc testing then" in response to my statement that "In context driven community, we do not insist on detailed specification … In fact some of us think that is a crime to refuse to test without specifications". In reality, the crux of the matter is, in CDT, testers need to cope up with whatever information that they get and start from there to gather information that they need. In those situations where time, information, people with knowledge - are rare commodity, context driven testing is clear winner. It prepares its tester for such eventual realities.

Finally the assertion that "There are no context-driven techniques" – should put all those statements/viewpoints to rest such as "Exploratory testing is a context driven testing technique". Neither ET, nor context driven testing is a testing technique in itself…

Overall, this post is a great milestone in the history of Context driven testing … should be mentioned in context driven website.


Sunday, January 04, 2009

MS outlook as Alarm Clock: Is this a bug?

[Background in the beginning … those who are interested in reading about bug I am talking about, skip first few paragraphs and go straight to Bug]

There is a saying that "Software users, most of the time, do not use the software as perceived by the designers or analyst". I happen to deploy Microsoft outlook as an alarm clock for me to help with a wake-up call. I am away from home, not carrying a cell phone, ipod is not a good tool for this purpose, buying an alarm clock for short duration would be a waste … hence zeroed in on Outlook meeting reminder feature as a software solution to help me to give wake up call.

I set up a recurring meeting of 0 minutes at say 7:00 AM everyday in the morning with reminder zero minutes. I thought this would work. I needed another hack … a sound alarm long enough for me to wake up. Most of small sound files shipped with windows/MS office were not helping me with this purpose. I had Yahoo messenger on my machine with an audio file that plays for few seconds. I decided to use that as reminder sound file. Even there was a problem. I thought 2-3 secs of Yahoo sound file might not be long enough to wake me up. So I needed to play this one file repeatedly say 7-8 times and record the whole thing so that I can get a sound file that plays for 8-10 seconds.

I went live with this setup, thinking that my next day's worries of waking up at specified time were over. It seems that UAT was not proper … first morning the alarm did not wake me up at all… when I investigated, I discovered that previous night before sleeping, I had muted the audio of the laptop … so far so good. I was waiting for next day to see if it works … Bingo … it did … exactly the way I wanted. No big deal I thought. However, I was happy to discover a low cost (zero indeed) technology to a problem in hand … software alarm clock.

I am sure there might be better ways … one could have written a small program in VB or Perl or Python to do this … with even snooze feature …. But, I think my solution worked for me … only to fail next day …. What ..? Yes, next day, the important day where I had some important meetings to attend… Outlook alarm failed … Is that a bug … Looks like I accidently stumbled on this bug …

[BUG] I think few hours before the scheduled appointment – alarm to kick off, a pop-up message about (Junk Email alert) came up prompting the user to take action. This is a modal window. Hence before dismissing this dialog box, outlook cannot proceed with any other pop-up windows like meeting reminders. So, my wake-up alarm did not get activated as there was a modal window waiting to be acted upon.

Is this a bug? May be or may not be …. Some might argue that this is not a bug as outlook is not supposed to be used this way. A developer may say that Junk email feature was required to be implemented as modal dialog box, it was assumed that people will act upon it … as they do for any other modal dialog box. Others may say it is too small problem to worry about …Some may even point out a work around for me … check on "Please do not show this dialog again"… so that my alarms will work without any problem. The Fix might be simple … (superficially) just make it as non modal window…. Or there can be other implications. I do not know... What if I had missed the flight back to India due to this software problem? What if I was delayed to all important meeting due to this software problem leading to huge financial loss?

What do you think?