Key lessons from the life and times of Richard Branson

When i wrote this article on managing multiple passions, i had not really read through about the Life of Richard Branson . His life definitely adds a great dimension to article. To me, he is one the rare people who not only managed unrelated interests with great zest for life but also got a considerable success and fulfillment in doing so.
For starters, Richard Branson is the owner of Virgin brand which started modestly as a record shop company but the brand is humongous now with more than 400 companies around the world. Apart from managing such a huge business conglomerate, Richard has a certain flair for Adventure. He has made several world record breaking attempts like fastest to be Atlantic ocean crossing to travelling around the world in Hot air balloons.He do plans to take his Airlines- Virgin Atlantic to space. Apart from this, he is very much involved in social work covering diverse areas.
I got to know him better through one the book- Screw it, Let's Do it: Lessons in Life written by Richard Branson himself. The book presents a lot of learnings from his life capturing the key events and i have tried to capture the snippets in his own words) in this post. As usual, i have captured important learnings right from this book. Read on and Enjoy!
The personal pronoun "I" in the upcoming text represents the words said by Richard Branson himself.

Have goals but be practical about them:
I believe in goals. Its never a bad thing to have a dream, but I'm practical about it. I don't sit day dreaming about things that are impossible. I set goals and then work on how to achieve them. Anything i want to do in life, I want to do well and not half- heartedly.

Just do it:
The best lesson i learned was to Just do it. It doesn't matter what it is, or how hard it might seem, as the ancient Greek, Plato said- "The beginning is most important part of any work." A journey of a thousand miles start with that first step. If you look ahead to the end, and all the weary miles between, with all the dangers you might face, you might never take that first step. So, take that first step. There will be many challenges. You might get knocked back- but in the end you will make it.

Getting things done:
The staff at Virgin have a name for me. It is "Dr yes". They call me this because i wont say no. I will find more reasons to do things that not to do. My motto really is: "Screw it- let's do it!". I will never say, "I can;t do this because i don't know how to." I wont let silly rules stop me.

Never say "Can't":
I don't believe in that that little word "can't" should stop you. If you don't have the right experience to reach your goal, look for another way i. If you want to fly, get down the airfield at the age of sixteen and make the tea. Keep your eyes open. Look and learn. You don't have to go to art school to be a fashion designer. Join a fashion company and push the broom. Work your way up.

Brilliant ideas come when you least expect them:
Here's an anecdote from the book which proves the heading-
Our plan was to travel on to Puerto Rico- but when we got to Airport, the flight was cancelled. People were roaming about, looking lost. No one was doing anything. So I did- someone had to. I chartered a plane for $2,000. I divided that by number of people. It came to $39 per head. I borrowed a blackboard and wrote on it: VIRGIN AIRWAYS. $39 SINGLE FLIGHT TO PUERTO RICO. The idea of Virgin Airways was born, right in the middle of a holiday.

Don't moan a bad boss but Love your work instead:
If you do still have to work for a boss at a job you don't like as almost everyone does at some point, don't moan about it. Have a positive outlook on life and just get on with it. Work hard and earn your pay. Enjoy the people you come into contact with through your job. And if you are still unhappy, make it instead your goal to divide your private life from your work life. Have fun in your own time, you will feel happier and you'll enjoy your life and your job more.

Have dreams and never give up on them:
It's easy to give up when things are hard but i believe we have to keep chasing our dreams and our goals. And once we decide to do something, we should never look back, never regret it.

Keeping your words:
One thing i always try to do is to keep my word. I set my goals and stick to them. Success is more than luck. You have to believe in yourself and make it happen. That way others also believe in you.

Embrace challenges:
As the writer and mountain climber James Ullman once said- Challenge is the core and mainspring of all human action. If there's an ocean, we cross it. If there's a disease, we cure it. If there's wrong, we right it. If there's a record, we break it. And if theres a mountain, we climb it.

Self belief:
I believe in myself. I believe in the hands that work, in the brains that think, and in the hearts that love.

Have no regrets:
I believe the one thing that helps you capture the moment is to have no regrets. Regrets weigh you down. They hold you back in the past when you should move on.

Live in the moment:
Always living in the future can slow us down as much as always looking behind. Many people are always looking ahead and they never seem content. They look for quick fixes like winning a lottery. I know that goals are important. Money is important. But the bottom line is that money is just a means to an end, not an end in itself. And what is going on now is just as important as what you're planning for the future. So, even though my diary is full for months ahead, I have learned to live for the moment.

Compartmentalize life:
The man who started IKEA divides his day into ten minute sections. He says, "Ten minutes, once gone, are gone for good. Divide your life into ten-minute units, don't waste even a minute.

My final thoughts:
I think this blog has gotten far longer than i had thought but i really couldn't help it. I still ended up omitting a lot of what i thought i would put across after i read the book but the above represents the best of my learnings from the life of Richard Branson. Going by the precept- "Best is yet to come", i am sharing one more key learning as below-

One of the great things that i found impressive in Richard Brason's life is ability to overcome odds. In his school days, the teachers not realizing he has dyslexic tendencies considered him quite slow in reading and writing. To overcome this, he taught himself to memorize things and became good at his perceived weakness and went on to even win a School level Essay contest, which is indeed an achievement for a guy written off almost at the early age. Certainly, he showed flashes of greatness even at a early age!

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!

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.

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!

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.

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.

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!