Friday, March 19, 2010

Uncovering myths about Globalization Testing- Testing MUI feature

Myth 22 : A tester testing Globalization features need not pay any special attention towards testing MUI feature.

I had touched up the nuances of Multilingual user interface (MUI) feature in this post as well as this one in the past. These posts primarily focused on how MUI technology is implemented in Windows Operating systems and spoke about the differences in MUI technology in different versions of Windows OS. What these posts did not cover specifically about MUI was- if the software application you are testing supports Multilingual user Interface, then what are the aspects that you can look at from testing perspective to ensure that MUI is tested properly. In my experience, this is an often neglected area of Globalization testing. May be because supporting MUI is one of the basic features and it is often "expected" to be working fine just because few common user cases work. The purpose of this post is to correct this myth and look at the finer details of a typical MUI implementation and the areas the could be generally tested.

MUI at a basic level:
What does it actually mean why you stare at a requirement that says- the application you are testing supports MUI ?
At a very basic level, it means that-
1. In the application under test, the strings are separated from the source code. What does "Strings" include in an application ? Strings may include any text on User Interface (or even sometimes Command Line interface) such as Menu names, Text labels,Control names etc. All these are generally static texts, which are usually the candidates for translation into any given language. These strings are separated from the source code and included in the resource files.
2. The second part- at a higher level, of being an MUI supported application is that the application has the ability (built programatically) to load the separated resource files dynamically at the run time.

So MUI software application is the one which is language neutral, has the translatable strings available separately in the resource files and finally has the ability to load the resource files dynamically.

Lets further look into some questions that might come into mind at this time-

What is the need to separate the strings from the source code ?
If the strings are not separated from the source code, then it will reside in the source code. What that means is- the language experts who translate the strings to the target language wont have access to those strings as they usually get the strings in separate files (called resource files) to carry out the translation. In this situation, when the strings are still in source code- it will result in that text being shown in the base language even when the application is localized. e.g. suppose the application's original language is English and there is a requirement to translate in German. So, the strings residing in source code will not get translated in German and we will have part English and part German text because of some English strings still being "hard-coded".

The second question that might arise is-

What is the need to dynamically load the resource file ?
Few examples here-
- Suppose an application supports 3 languages- English, German and French. If user installs the application on German OS, then at the time of installation, the application should recognize the Germaan OS and load the German resource files. If it does not then the German customer may end up seeing English or French text.
- Suppose the organization has a support group in Germany and they deal with English customers. The German support engineer might prefer the User interface to be in German and as he is dealing with English customer, there may be a need for him to switch between German and English User interfaces. This is where dynamically loading the resources and hence, the MUI features comes in real handy.

What are the questions i should ask before testing MUI feature ?
Asking questions helps! and it does always help to ask quite a lot before testing and of course, while testing. Some questions below might help understanding the scope of MUI testing-

- Is the Installer of my application support MUI i.e. does the application Installer installs different supported languages' resource files as a part of Installation ? i.e. if product supports English, German and French languages- does the respective resource files gets into the system during installation ?
- Does the installer recognize the OS locale settings and installs appropriate resources files as per locale settings ?
- Does the application installer provides an option to select the language before proceeding with Installation ?
- Is the Fallback logic implemented ? i.e. say if supported language is German and the application is installed on Dutch OS, does the application falls back to a common language say English ?
- After the application is installed, does it provide the option to the user to switch language at a run time ? i.e.
- If the computer has 2 users with different languages (its possible in Windows OS!) i.e. say English and German and the user logs on to German user settings, does the application desplays the German UI ? This should be taken care of by the application's dynamic resource loading logic.
- If the application happens to be a web application, then too all the above questions will hold good. One additional question to ask, though can be- What is user's browser language ? This is a typical case- when OS language is different from the browser language. In this case, what is the fallback logic ? How should it behave ? It can become more complex say in a situation when the web application runs on French OS with French Canadian browser settings and at the application logon page, the user selects English language as his preferred language. In this case, what language should be shown to the user ?
- How does the MUi logic works in Mac, Linux, Firefox, Mozilla etc. ? Are there any implementation differences that i need to be aware of ?

These questions (and may be more) can help clarify MUI requirement in detail and accordingly testing strategy can be formed. Asking questions is required because Test engineers may never get the requirements in as much detail as might be required for them to test effectively.

Why is testing MUI feature important ?
For an International application, MUI is one of the key features. It is a feature that has helped Microsoft add the required scalability to scale their products across the world. The reason i used Microsoft's example here is because probably Microsoft is the most Global software organization in the entire world. Consider this- Windows 98 supported 30 languages, Windows XP supported 42 languages and Windows Vista- a whopping 97 languages. One of the prime reasons, Microsoft has been able to scale up so much in Windows Vista is because of advancement in MUI technology during the Vista release and this technology is further used in Windows 7 too. So, for an application to be truly global, it has to have a core global arhitecture in place which is what MUI helps achieve.

What are typical Test ideas of Testing MUI feature in the application ?
At the core level, testing MUI means-
- Testing for Language neutral core binary
- Testing for single MUI Installation
- Testing for switching language without Reinstallation
- Testing for the logic of dynamically loading resources
- Testing for language Fallback mechanism
- Testing for Single base binary

Depending upon the answer to the questions asked in the section above, the right testing strategy can be formed.
I think with this information, i will be good to continue the discussion further on what parts of MUI can be specifically tested in your applications.

Please do share your ideas!

Saturday, March 13, 2010

Key professional lessons from Football coaching principles

In football circles, the mention of Don Shula doesnt need any introduction. He was a coach par excellence of Miami Dolphins in American National Football League (NFL). What stands him apart from most of other generations of Football coaches is sustained success in pressure cooker situations. If you have any doubts about what a pressure cooker situation means with respect to Football, just watch any high intensity international or even European club level matches to get an idea. Maddening crowds, Sharp critics, tensed coaches- it has all the elements of a nerve wrecking drama. In such an environment, Shula set numerous records in his 33 seasons as a head coach. He is the All-Time leader in Victories with 347. He is first in most games coached (526), most consecutive seasons coached (33) and many more.
His coaching was regarded as out of the world and to top it all his consistency in achieving super results over the years set many standards which are hard (if not impossible) to match.

Don Shula teamed up with Ken Blanchard to write an impressive book on coaching called the little book of coaching . This book is quite unique in its writing style as Don Shula shares his Football coaching methods that helped him achieve all the results that he did and Ken Blanchard on the other hand, presented his understanding of those very principles and utilized in day to day dealing. The content of this book is engaging and for sure opens up many a thought processes and the text that follows represents my attempt to decipher these valuable coaching fundamentals and its potential use in coaching Software testers-

[The text in Italics below represents the excerpts from the book, mainly in the form of quotes from Don Shula]

The Bull's eye philosophy:
I believe if you want to hit a target, you should aim for the Bull's eye. If you aim for the Bull's eye and miss, you will still hit the target. But if you are aiming only for the target and miss, you will be nowhere.

In 1972 NFL season, Don Shula's team won each and every game and remained unbeaten. And this was the goal that he set for his team.
While leading your testing teams, have the highest goals set for your team. As an example- say finding all the non regression bugs by the first iteration of testing as one the goals. If testers know this to be as their goal, they will strive to achieve this (of course if provided with the right kind of motivation). But if the goal stands like- Find all the non regression defects by the first Release candidate build, it is very likely that there will be last minute bugs before the release.
As a coach, always describe the vision of Bull's eye to your teams. More often than you might think, the team members do not know or have a clearer picture of how a perfect work output looks like. And in absence of such a vision, they adopt for a relaxing, comfortable goal that will invariably make them complacent. Drawing the vision of Bull's eye does not require one to be a magician but requires two things- One- clarity of thoughts i.e. first knowing what a perfect work output is like and Second- Ability to weave the picture of perfection for the team members, which they can strive to achieve. More the team strives to achieve the Bull's eye vision, more closer will it reach to perfection.
As Leo Burnett rightly quoted-
"If you reach for the stars, you might not quite get one, but you won’t end up with a handful of mud, either."

Overlearn, Overlearn, Overlearn...:
Overlearning means that the players are so prepared for a game that they have the skill and confidence needed to make the big play. More than anything else, overlearning- constant practice, constant attention to getting the details right everytime- produces hunger to be in the middle of the action. Perfection happens only when the mechanics are automatic.

As a coach of a Software testing, it pays to have your team reach the "Overlearning" state. Overlearning for Software testers cover many critical aspects of the Job-
- The testers are aware of their prime roles in the current project/scheme of things.
- The testers are trained so adequately that they almost simulate and visualize the situations and their response to it.
- The testers work independently as they strive to reach the auto-pilot mode i.e. not needing minor directions.
- The testers achieve Execution excellence- they dont just stare up the steps but step up the stairs.

The above areas form the core of activities for a Software testing coach also as these are the ones that actually are the difference between an average team and a performing team. The coach would need to Overlearn themselves first and then have their teams follow the suit.

Lead by Example:
I dont know any other way but lead by example.
During the 1994-95 season Don Shula ruptured his Achilles tendon. The day he had the operation was the first regular season practice Shula had missed in his twenty-five years with the Dolphins. After the operation, Don was taken to recovery and then to his hospital room, where he was scheduled to stay overnight. By 2:30 in the afternoon, he'd had enough of the hospital. He asked the doctor for his crutches and was on his way home shortly afterward. By 5:30 the next morning, he was up and wanting to attend Mass and then go to practice. By 10:00 A.M. he was on the practice field in a golf cart.


Moral of the story- if as a coach, if you expect commitment, demonstrate the same to your team. If you expect excellence, demonstrate the same to your team. The team wont learn anything in a better way than seeing you do the same very things you want them to do.

Change Plan as situation demands:
There is no point sticking to a game plan that's not working. The sun does not rise and fall based on one person's judgment. Effective coaches are continually out there scanning for data and advice that will make their decision more intelligent.

Software products probably undergo more changes during its entire life-cycle than any other products that ever existed. That really makes Software testing a very dynamic entity.
In spite of this, there is a growing tendency among the test owners to stick to a Testing Plan document that gets created at the start of the release and is probably never looked at through out the duration of the project. Effective Software testing coaches realize the importance of updating the overall plan as need arises and keep the team updated and informed. Such coaches can sense, anticipate the changes and be well prepared in advance.

Apply twenty-four hour rule equally to Failures and Successes:
I had a twenty-four hour rule. I allowed myself, my coaches, and our players a maximum of twenty-four hours after football game to celebrate a victory or bemoan a defeat. During that time, everyone was encouraged to experience the thrill of victory or the agony of defeat as deeply as possible, while learning as much as we could from that same experience. Once the twenty-four hour deadline had passed, we put it behind us and focused our energies on preparing for next opponent.

I feel this rule is very much applicable to handle mistakes and errors at workplace. Not all days are similar, there may be some days you do well and at other you end up doing mistakes. A typical bad day at office for a Software tester can be- Missing a deadline, missing to find a bug that could have been found earlier, committing an error in verifying a test properly, missing to gather right information to advocate defect appropriately and many more. Many people let these disappointments affect them and future work tasks severely. I think the role of a coach becomes greater and significant during these situation. Enforcing a twenty-four hour rule can be immensely beneficial in these situations i.e. for twenty four hours feel the current situation as much as possible and to an extent to learn from it enough not to repeat it excessively and after twenty fours- like they say- "let bygones be bygones".
Personally, i dont think the successes should also be lived only for twenty-four hours as more they are remembered in a right way (not losing the focus on present), it acts as a positive source of energy for the team members.

Be consistent:
Consistency is not behaving the same way all the time; it is behaving the same way in similar circumstances.

People generally have varying notions of consistency. Generally speaking, if as a coach you give no response/feedback to your team member when he or she does well and you neither give response/feedback when he or she commits a mistake- then thats not consistency. Though the conventional wisdom will call such a behavior consistent because as a coach one acted the same way in both the situations. As Shula clarifies, Consistency is actually behaving the same way in similar circumstances.
Withholding feedback when it should be given and not praising an effort when it should be applauded are an example of coach being inconsistent with his team members.
Consistent coaches deliver consistent results.

Personally notice your team:
You cant catch your people doing something right if you're not there to see them do something right.

People appreciate praise more when its genuine. A coach can be genuine in expressing his praise for the team only when he or she witnesses it firsthand. If as a Software testing coach, you are not there to directly witness your team member logging that all important bug or delivering a great presentation or convincing a developer, you are for sure not up-to-the-mark there.
Being personally there with the team when they are in pressure situations or not even in so much pressure situations gives them a belief that they can look upto you and also that you will be fair with them in performance related dealings.

Managing meetings effectively:
I want to make sure that my team came out of every meetings a little more intelligent than when they went in, that they came off the practice field a little better prepared mentally and physically to play the game than they were before the practice.

In the corporate world, meetings are for sure necessary evils. Organizations need meetings to synergize, sync-up and work towards the shared vision. But at the same time most of the meetings turn out to be ineffective with a very little takeaway for all the stakeholders. Below is an interesting nugget from this source about the way meetings are conducted in US corporations-

"More often than not, company and department meetings are inefficient, disorderly and ineffective. Every day, approximately 11 million meetings are held in the United States. That means roughly 37 percent of employee time is spent in meetings, according to the National Statistics Council. What's more, researchers have found that nearly all meeting attendees (91 percent) admit to daydreaming during meetings, while more than one-third (39 percent) have dozed off."

I think you would appreciate that the above inference is not only US specific but the rest of the world is not too far behind. Being a coach, Don Shula's thinking about ensuring that the team members should come out of the meeting little more intelligent and better is quite insightful. Even in the corporate meetings, the intent of meeting organizer is quite vital. This is where effective coaching can make a difference.
I feel as a coach of testing team or any team for that matter, if someone inculcates "making the team members more intelligent, more informed, more knowledgeable at the end of meeting" as a driving goal, we might probably see more happy faces and less dreamers during the day.

Do you already apply these principles in your coaching ? I would love to hear your thoughts.

Sunday, March 7, 2010

Key lessons from the life and times of Steve Jobs

I had completed reading the Book- Inside steve’s brain a while back. I found this book an excellent representation of the business lessons that can be learned from the life of Steven Paul "Steve" Jobs , the co-founder and chief executive officer of Apple Inc.

I have this inherent interest of going through the biographies of the people who have strived to excel in their chosen fields. (i could have used the word "Successful" in the previous sentence while describing the people who achieve something, but i tend to refrain from using that word because Success to me is very subjective, its very definition changes from people to people. I find Striving to Excel much meaningful representation here).
The prime driver of this interest is that there is a lot to learn from these people who had managed to do the seemingly unthinkable things. Books are simply a great medium which virtually help to connect to these people's lives and imbibe the learnings.

I have read quite a few biographies in the past and i would love to share my learnings through this medium.
This post is obviously all about Steve Jobs. Here are some detailed insights into what Steve Jobs is made up of-

Taking hard decisions head-on:
When Jobs took over as a CEO of Apple, he took a critical view of the situation at Apple. He arranged for each product group to present to him or rather virtually sell to him on the work they were doing, why it is important and why should be keep on funding them. In effective, the overall review process resulted in him taking some very tough decisions ranging from either the non critical projects being cut down or people being "steved" (meaning fired in Apple folklore).

He had to make some very hard tough decisions but he had courage and conviction to take them head-on rather than procrastinating or delaying them just because they were tough to make.
There is no official track on how much time human beings waste by just delaying some decisions just because they are uncomfortable but it were to be calculated, it would virtually run into zillions of hours wasted.
Facing hard decisions head-on is a vital quality for any decision maker.

Not hesitating to rightly say "No" when situation demands:
Steve Job's favorite mantra at Apple is: Focus means saying "No". When Apple first launched iMac, Jobs insisted on it not having a Floppy drive, which was an essential part of any computer of that era. It received a severe backlash from critics in the market with one of the critic even went ahead and declared-
"The iMac is clean, elegant, floppy free- and doomed."
As a fact of matter, Jobs himself wasn’t too sure about his decision to exclude the floppy drive given the odds stacked against him, But he still went ahead and said "No" to it trusting his gut. Also, the factors that helped him take this decision was the iMac was primarily supposed to be one of the early Internet computers and also that it was one of the first computers to be shipped with USB.
Whatever be the reasoning, it does take a tremendous mental effort to say "No" trusting your guts and knowledge when everyone else in the visible world is saying "Yes" to something. Many a professional situations demand that we say "No" but we end up saying "Yes" merely because of a feeling of lack of power on our part to reason the "Yes" men out. It does take a huge strength of character and belief in one's ability to be able to rightly say "No" when situation demands.

Focus on what you are good at; delegate all else:
Steve Jobs has a great sense of his strengths which is new product development, cutting deals for Apple (he is a master negotiator) and giving product presentations (which are flawless to say the least). At the same time, he knows what he is not good at- i.e. Directing movies, or handling the Wall Street or doing the Operations related tasks. His idea seems to be always playing to strength and take the advantage of the fact that there are people who can do the other jobs better than the way he could do. This aspect shows 2 points- One is the self awareness and second is not hesitating to admit that he cannot be good at everything. In professional life, there are many who have certain blind spots about themselves which prevent them to maximize their potential.
If one is not good at something, it often eases the work as well as the work relationships to actually delegate the tasks away. It is certainly not a sign of weakness.

Attention to details:
Steve Jobs is known for his obsession with details. As one of the design folks of Apple, Ratzlaff (who worked directly with Steve) says- "He was way down into the details. He would scrutinize everything, down to pixel level." He was so much so involved in the design that he had his own ideas how the seemingly minor thing such as Scrollbar should look like.
As goes one of the sayings- "God lies in detail", often the difference between a good job and a not-so-good job lies in the level of detail spent.

Never compromise with Excellence:
In Jan 1999, the day before the introduction of a new line of multicolored iMacs, Steve Jobs was practicing his product presentation at a big auditorium near Apple's HQ. Five of the machines in a range of bright colors were mounted on a sliding pedestal hidden behind the curtain, ready to take center stage on Jobs's cue.
Jobs wanted the moment when they slid out from behind the curtain to be projected onto a large video screen looming over the stage. The Technicians set it up, but Jobs didnt think the lighting was doing the translucent machine justice. The iMacs looked good onstage, but they didn’t really shine on the projection screen. He then kept asking the technician crew to alter the lighting till it looks just perfect. Finally, after the fourth attempt, they hit the bull’s eye and he was satisfied.
The above excerpt provide Jobs's commitment to Excellence. The key learnings from this is that one should marry Excellence in everything one does and then success becomes a mere formality.

Decision making through Intellectual combat:
Jobs makes decision by fighting about ideas. Its hard and demanding but rigorous and effective.
Though Jobs had a reputation of being a micro manager but he is smart enough to involve and engage people rightly to make worthwhile decisions.
The key learnings here- Never lose focus on the betterment of organization while making decisions. Involve people, look at an idea from all the possible directions. The idea for iPod’s scroll wheel came from Phil Schiller, the head of Apple’s marketing who was never a part of formal design process.

Dont Innovate for the sake of Innovation:
All about this here.

Dont be afraid of trial and error:
The typical design process at Apple goes through the myriad of trial and errors. Even the iPod's breakthrough interface was discovered through a process of trial and error. Such processes require a lot of perseverance and tolerance for mistakes but the end result is often a very refined one.
While indulging in any new task never hesitate to commit mistakes as long as one can learn and the output becomes close to perfection.

Well, these learnings are few of my chosen ones from this wonderful book.
I intend to supplement the series by sharing the learnings from biographies from other wonderful people. Watch out this space for more!

Thank you for reading through. I would love to hear any comments and feedback!

Wednesday, March 3, 2010

Uncovering myths about Globalization Testing- Finding Localization bugs before actual translation takes place

Myth 21: It is not possible to find the Localization bugs before actual translation takes place.

This is a myth because it is possible to find Localization bugs before actual translation takes place using an approach called- Pseudo Translation.

To know more visit my article on Pseudo Translation

Visit here to know about other Globalization Testing myths uncovered in the past.

Saturday, February 13, 2010

How often do you challenge the Pseudo comfort of your Comfort zone ?

One of the things that have always intrigued me is why majority of the human beings (including me!) just love being in their Comfort zones. Consider a few examples-

- In front of a large audience, if one was asked to give an extempore presentation- wouldn’t one's feet tremble and the heart skip a beat?
- If one is always habitual of sitting on the back seat of the car is suddenly asked to drive the vehicle (of course one has to know the driving), wouldn’t you take up the driver's seat with a great deal of anxiety if you are not used to driving so much on busy roads.
- Your employer asks you to pass on a bad news about pink slip to an employee.
- You are given a project for which expect the out to be delivered at a very short time.

There can be numerous such examples in our lives when we unwillingly are "asked" to do something that we think is beyond our "scope of existence". The key element here is that be in our Jobs or day-to-day lives outside of Jobs we tend to define a certain scope of existence. If any event in our lives falls under this scope, we execute it with certain comfort. If anything goes beyond this scope, normally we tend to feel discomfort, we feel anxious, and there may be other visible indications each amounting to discomfort. The general tendency exhibited by human beings is to avoid this feeling altogether. The question that arises is- Is it right to avoid this feeling ?

I was recently reading a ebook (Titled as "Dare to Dream") by Anthony Fernando , there was a mention of Comfort zone and its finer points. With due credit to the author, i am sharing a few key points that this article touches.

Everything you want in life is waiting for you outside of your comfort zone.

When we stay safe inside our comfort zones, we limit ourselves to experiencing the things that are already part of our life.

The only way to change your circumstances is to venture out of your comfort zone into a Possibility zone, because it is here that you will find everything you have ever wanted.

The only way to expand your comfort zone is to bite the bullet and step out into the possibility zone.
Initially this can be uncomfortable but with repeated effort, your comfort zone will slowly expand to include the things that you really want from life.


To me the above are the real gems of the wisdom. Whenever we are faced with any unfamiliar situation at work or in life usually that very situation tend to push us outside our self defined Comfort zone. And generally our mind treats getting out of Comfort zone as something unpleasant and something that it does not have natural motivation for. From what I know, it is just natural for the human beings to live life in set patterns. A normal human being usually favors a certain predictability in life in a way sequence of events shapes up. E.g. One generally tend to expect praises from the superiors and if some situation leads to reprimands, then that’s kind of breaking the set pattern that one had expected for one self.

The journey towards something meaningful, towards achieving one’s goals start with discomfort, with pains of trying something new despite hiccups, glitches or difficulties. Rather than running away from the discomfort the real courage lies in facing it upfront, quell the fear, defeating all the apprehensions. Even if the initial results of leaving your comfort zone aren’t favorable, I think that’s still better than someone willing to be in its own comfort zone. That discomfort is certainly the first step towards achieving the intended goals. I the true sense, the comforts brought forward by the Comfort zone as Pseudo comforts that keep us in illusion and hamper us from achieving our true worth.

Do you have any stories to share across regarding breaking your comfort zones and achieving something that even surprised you ? Do share it across!

Well, I didn’t initially intend this post to be as much philosophical as its eventually turned out. But my experience tells me that its an important enough topic to be deserving a rightful mention.

Sunday, February 7, 2010

Motivating (or relentlessly Pushing ?) Testers towards higher number of bugs. Does it always work ?

Numeric defect related goals. Have you experienced the syndrome ?
Have you ever heard a team owner (read Leader, Manager or whatever) of a Testing team say any of the below-
- My study of Defect Prediction model suggests that this project should have 400 bugs. Why have we found only 50% so far ?
- You have logged less number of bugs in this cycle. Please pull up your socks.
- Your performance is not upto the mark. Please log more bugs.
- Your goal is to log 50 bugs in this cycle.
- In this quarter, you need to improve your bug logging rate.

If you haven’t heard any of the above in your Testing experience, I would consider you lucky, you have been in a good company. Given the professional situation we stay in, i am convinced that many of the test engineers might had to go through the situation where in they were assessed or recognized solely based on the number of bugs they report, no matter what that means.

Is it worthwhile having Numeric defect related goals ?
It usually makes me wonder about the benefits of having the numeric goals bestowed upon the Test engineers. I really fail to find many.
One may argue that having a numeric goal as a reference always keeps the test engineers focused on the goals that they need to achieve. This may be fair for some but this explanation does not capture the overall scheme of things. Consider the below quote by Ichek Adizes that i recently read-

Managing only for profit is like playing tennis with your eye on scoreboard and not on the ball.

To me this quote clarifies a lot of things. With due credit to the author of the quote, i would take the liberty of tweaking this quote a bit for our profession. Read this-

Managing only for number of bugs is like testing the software with your focus on a mere number to achieve than for the love of profession.

Doesn’t the above quote (or requote i say) brings out the essence of the ill effects a senseless numeric goals has on the most important assets of a testing group- The people. The people who are passionate about Software testing would resonate that what interests them towards this craft is the process of learning something new about the Software, having or working to build a unique perspective to assess the software, to solve the problems of complex nature, to apply new techniques, to learn and relearn and many many more things. And the end result of application of this passion, interest, skill is the bugs that we see testers find.
Having focus only on finding a certain number of bugs seem more like robbing a Test engineer of all the greatest perks of work that result in finding the good bugs.

The need for Positive motivation to find bugs:
Before I sound like going unidirectional, I do recognize there is a need of certain motivation that can possibly help find good defects. And certain people do apply the thought of keeping numeric goals to improve defect rate and probably may achieve certain success but this certainly leads to defocusing of Test engineer's energies to a mere number leaving him/her not enjoying the overall process of testing, which is certainly not good for the overall sake of the profession.

I do believe that in addition to educating Test engineers on the right knowledge and skills, as a Test group owner one needs to have effective motivational strategies in place as well. How-so-ever tempting the business of numeric goals may sound, somehow it doesn’t seem to convince me fully. I would certainly worry if any project in question doesn’t have any bugs found but then such a situation is ideal for further analysis and to be figured out the root cause of such an issue rather than just setting a number goal. This may work sometimes (may be if you are dealing with staff who isn’t passionate enough about Software testing and treats it as just as a Stop gap arrangement) but not in majority of situations.

Try using Placebos for silent motivation:
In his book, Stop the Excuses , Dr. Wayne W. Dyer says-

That mind controls the body is hardly up for dispute. You have probably heard of documented studies where sugar pills given to control group believing that they're a remedy for, say, arthritis, turn out to be as effective as the drug being administered, for arthritis. This placebo effect apparently occurs due to the belief in the effectiveness of the pill.

Placebos are quite widely used in the field of medicine. It’s a kind of make believe treatment in which patient believes that he is being treated upon with medicine for some ailment but in reality he is just being sugar pills. This makes his mind believe that he is being treated rightly and to some surprise the medical field has found considerable success with such a Pseudo treatment.

Placebos and Software testing- Are they related somehow ? Some might think this reading the above. But i feel there is an inherent connection there. Consider a situation that you are dealing with a complacent team who believes that they have tested all that could be possibly tested in a product and there are "no" bugs in the product (In my experience, I find teams feeling confident, may be over confident to make such a tall claim, which is improbable). In these situations, one could either believe what the team says or may be "push" them to find more bugs by setting numeric goals. But I do feel Placebos do work quite well there. Just have the team swallow a Placebo that "Development team feels that there is some part of code which is vulnerable to bugs, many bugs." I call this Placebo because as this is no less that a sugar pill that helps Testing team deal with Complacency and act as a certain source of motivation. Complacent test engineers, no matter how much skilled they are- tend to let go of opportunities to find good bugs. You might even be surprised to see the number of test ideas that starts flowing out of the minds that weren’t even considered before. All this just by chewing (not literally!) an artificial Placebo.

The overall point I was trying make is that there are good ways, better ways than mindlessly directing numeric defect related goals.

Do you tend to agree or disagree ? I would certainly love to hear!

Sunday, January 24, 2010

Managing multiple passions- make most of your hidden talents

Harsha Bhogle in his book-"Out of the Box - Watching the Game We Love" has a mention-
Peter Reobuck once told me of the twin loves of his life: cricket and the English language. They work well together; certainly in our game which lends itself to fine writing.

The above lines have an unique reflection about people having Multiple passions and interests. People's talents are usually not limited to being good at just one thing for life (we usually refer to as Passion) and are helped immensely by parallel interests. In case of Peter Roebuck, its Cricket and Speaking, Writing in English language.
Jack Russell came into limelight when was a part of English cricket team in 1980s and 1990s. Though not being formally trained at art, he had a special interest in art and took up as a Full time artist after his Cricket career was over. Not only this, he also is a Football goalkeeping coach.
In Michael Phelps biography (Michael Phelps The Untold Story of a Champion) by Bob Schaller, there is a mention of fellow swimmer Natalie Coughlin . He says “A graduate of Cal-Berkely, Natalie Coughlin has interests outside of the pool that means as much to her as her life in water .She goes out of her way to keep balance in her life, and while swimmers everywhere do doubles and train hours every single day, Coughlin is just as prone to balance a single daily workout with Pilates, walking her dog or Spinning.”

Pradeep Soundararajan in his blog wrote this post giving some insights into how interests different than Software Testing help the craft. Looking at the Blogosphere, there are so many distinguished testing practitioners who not only are the experts at their craft but also find time to do write frequently in blogs, magazines, speak in conferences and other relevant forums. All this really gives a view that there are two types of people in the World- One who find time to just do what they are supposed to do and the other half being the people who not only do what the profession demands but also goes a few notches beyond that and manage multiple interests. Though there may be doubts about accepting such an extreme classification of the world, but one thing is for sure that there exists people who seemingly achieve more in a day thereby giving an impression to the external world that God probably was more kind to these guys and gave them more than 24 hours in a day. It is often intriguing to me to wonder why some people manage different passions so well while some people make an attempt at the same but with little success. My mind had been working overtime to demystify this fact and following in this post i would like to share some thoughts around it. The text that follows is mostly in the form of answers to some relevant questions involving handling of multiple passions-

Am I "Only Interested" or Am I "Fully Committed" ?
Ken Blanchard in his book "The Heart of a Leader" mentions-
I learned from author and consultant Art Turock that we need to make a distinction between being interested and being committed. When you are "interested" in doing something, you only do it when its convenient, but when you are "committed", you follow through no matter what, no excuse."

I think this is a very relevant observation. I think people who manage multiple passions are not only interested and deeply in love with their areas of interests but are also hugely committed towards the same. They operate in a mode as if it’s their responsibility to contribute towards their passion every day, every hour no matter what. Many people get inspired and interested in pursuing additional interests but fail to pursue it for a longer period of time because the convenience factor creeps in with the lack of commitment. If one is committed to the cause, it’s not impossible to cross any obstacle.
If you like to do something but haven’t been able to pursue, just ask- Do i really want it badly ? Am i really only interested or committed also ?
The sooner one sorts out the answers to these questions, it lends the desired clarity to live with one's passions.

Am I able to "prioritize" effectively ?
I was having a conversation with J.D.Meier about managing multiple priorities and why individuals even while having interests in multiple activities aren’t able to contribute enough or balance properly. Here is what he had to say-
Here's what I do:
Mapping Out What's Important:
- Identify the most important results in each area or hot spot in your life (just the top 3 result for each hot spot or interest)
Producing Results:
- On Mondays, I identify 3 results for the week
- Each day, I identify 3 results I want to accomplish (this drives my day)
- On Fridays, I reflect on my results. I identify 3 things going well, and 3 things to improve.
Monthly Themes
- Each month, I pick a theme for focus. This is how I can balance across my interests. It allows me to focus less on one thing, while I focus more on another.
This is a quick start guide that helps - http://sourcesofinsight.com/2008/12/10/the-zen-of-results-free-e-book/


I did try this suggestion and found it to be quite reasonably working. Of course, like with any other approach, this approach also requires one to be disciplined enough to follow it consistently. One thing that this suggestion helps achieve is the required focus on your interest at a given time. One of the challenges in managing multiple passions is effectively juggling between the different priorities while not losing the focus. Getting to work effectively towards three focused areas in a week helps one take baby steps towards an eventual achievement. The beauty of this approach is that it does not suggest you to take up huge tasks and then later struggle to complete them (that’s the reason i used the word "Baby step" in the previous sentence). Like with every endeavor- Patience and Perseverance is the key here too. This is because Baby steps taken in the right direction leads to Giant steps in a longer run.

The question may arise, whether an individual should talk about more than 3 priorities at a give time. Here's how J.D. Meier answered it, when i asked-
Why not finish the first 3, then bite off more?
The value of 3 is that you can remember it without writing it down. Test yourself. Today, I had 3 priorities - complete my draft vision, confirm the budget, and sync w/my partner group. Did I have lots more things to do? ... Sure, but those 3 were my best bets for the day. If I got through those 3, I could always bite off more. What I didn't want to do was have a long list of things I couldn't remember.
The rule of 3 was actually found to be the most effective number in the military for people to remember outcomes without writing things down. I didn't know this at the time. I'm just happy that the military came to the same conclusion. I lucked into it :)


Isn’t this Simplification at its best ? Clear mind does achieve more than a cluttered mind.

Am I able to "create" enough time ?
Of course, the common thought people who want to do more but aren’t able to do so is that they don’t have enough time. From my observations, the idea is to create time for self, for what you want to do.
There are infinite ways one can look at the day and build up time for something you really want to do. One of the ways, Subroto Bagchi mentions in his book- "The Professional" when he introduces the term- "White Space"-
I do not know how the term White Space originated. In telecommunication, it denotes frequency allocated to a channel but not used. Typically, broadcasters are provided additional frequency that is not meant to be populated so that the adjacent broadcast stations do not overlap. In print, the white space denotes emptiness so that we can read between the characters that form a word and a group of words that form a sentence.
In our professional lives, white space is a train or a bus ride to work, it is the time waiting outside the client's office, the time spent on long flights. We have all been given huge white spaces and we simply let their power go waste.


Look back at the day you spent, you will notice the white spaces and how you utilized them. If you wanted to read a book, could you have utilized the white space better. If you wanted to write something, could white space have been utilized in a better manner. I am not suggesting you to use all the available White spaces towards your interests, probably that’s not ideal. But what is more apt is that in order to create time for self, White space do offer the necessary time space for you.
By just having a look at how you utilize the time in the day, you would be able to figure out how to manufacture time. Believe me, it’s possible!

Am I able to "compartmentalize" life ?
"Our main business is not to see what lies dimly at a distance, but to do what lies clearly at hands" - Thomas Carlyle

Dale Carnegie too was a huge proponent of Living in a Day tight compartments. Over a period of time, i have begun to appreciate the essence of living in Day tight compartments. Much of our mental and emotional energies drains out worrying about what will happen tomorrow or also by replaying the mistakes that we did yesterday in our minds. Living in a day-tight compartment is a metaphor that symbolizes that we shut out thoughts that carry over from yesterday or thoughts that represents tomorrow's anxieties and live life as it happens today. The idea is not to let residue thoughts of yesterday and toxic worries of tomorrow bother you today.
I have found the application of this concept suitable even while managing multiple passions. I try and live a slightly modified version of this principle- "Live in a hour tight compartments" when you are dealing with multiple interests.
It often happens that disappointment resulting in failure or a mistake in one task during the start of the day often occupies your mind throughout the day and affects everything else you do throughout the day. Living the day in a hour tight compartment helps one shut out what happened in the earlier on and helps maintain the required focus in other interests.

Am I believing in myself more than i should ?
This may sound somewhat naive. I always thought that believing in oneself is one of the foremost things everyone should do, till i read Don't believe in yourself if you want to succeed! . In its heart this article talks about how believing in self always leaves us vulnerable to unknown situations. When faced with these situations, we often tend to think about our limitations.
If at all you think you cannot manage multiple interests, it might as well be the case of excessive belief in your own self. Try not believing the part of you that says "you cannot do it". It works! Every achievement starts with a thought in mind.

---------------------------------------------------------------------------------
Updated on 13th-March-2010
Martin Bailey --a man with multiple passions, quite beautifully balances his passion for photography with his work as a Software Management professional. For more on him, do visit- http://www.martinbaileyphotography.com/

Here is what he had to say upon reading this post-

I read your blog post with great interest. You write very well, and although I intended to scan over it, I ended up reading it fully.

I thought the part where you mentioned about being interested as opposed to committed is so very true. People often ask me how I find time to do my photography, including the weekly podcast and forum etc. while maintaining a busy full time day job. My answer is often that I don't find time, I make time. People will always make time to do something that they love and they really want to do. If you aren't able to do that, question your commitment to your passion, and not how others miraculously seem to have more time than yourself.

Prioritizing what you attack first is also very important. I've never locked into the number three, but when I have a long list of things to do, I prioritize how I spend my time. I often quote the 80:20 rule. You can say that 20% of what you do will be responsible for 80% of your success. If that's true, you can stop doing the other 80%, concentrate on doing your 20% really well, and excelling in those tasks, and your overall success will be enhanced even more. Of course, there are always going to be things in the 80% that you can't avoid doing, but you don't need to work on these as hard. I learned from an old boss, that sometimes good "enough", is good enough. You don't have to do everything to the best of your ability to succeed.

You also talk about creating time in your paragraph about White Space – I have no white space! There is no time such as on a bus or walking when I am not listening to a photography related interview, or an Audible book etc. Even when I'm sitting next to my wife after dinner, enjoying our time together before I go to my computer, if we are not talking about something, I'm running through ideas and planning my evening's activities or future plans. I do feel that I need to work harder on giving myself some white space to be honest. I am often so plugged in, that I can become over tired sometimes, to the point of making myself ill. Taking time off is important.

I like the idea of day tight or hour tight compartments. I generally learned a long time ago that I need to shut off one thought or problem to enable me to concentrate on the next. In my early twenties I would lose weekends worrying about something that happened on Friday, only to find that on Monday the problem had either disappeared, or was not such a problem after all. There are times though when I am not able to cut off feelings from previous incidents, and I'm not sure that we should. One of my bosses always praised me for being able to cut away from work easily though, and giving myself time for my photography, creating a nice balance in my life, so I'm probably doing an OK job of this.

The only thing in the article that I found a little difficult to read, or awkward was the double negative at the end. You say that we should not believe in ourselves, but then turn it into a positive, by saying that you should not believe in yourself when you think you can't achieve something. This last paragraph is funny, as I'm sure you meant it to be, but it boils down to the fact that you need to believe in yourself to give yourself the confidence to proceed, but not to be over-confident.

Personally, I have a very easy philosophy around this. I never question my ability to do something when trying to decide whether or not to take on a new task or project. The only question I ask myself is whether or not I want to do it. If I want to do something, I will make it happen, no matter how difficult the undertaking. Of course, I realize that although I'd love to be able to fly unaided or go to the moon, right now that's just not possible. You have to be realistic, although I do fully expect to go to the moon or into space at least once before I die.

Great article Anuj! Thanks very much for sharing.