Rahul Dravid and the art of playing second fiddle

Rahul Dravid has retired. An era has ended. There have been glowing tributes flowing around the cricketing and the non-cricketing world to praise this truly great man. And he deserves each and every ounce of praise being showered on him. He has been the man i idolized not only for what he brings to the team on the cricket field but much for what he has conducted himself off the field. So i am sad for sure that he has gone off the field but what gives me a bit of assurance is that he still be around as a human being to look upon. I will still miss his sweaty face, with intense eyes with all seriousness immersed in any situation on the field but would still be following his each and every move (post retirement) by the same level of interest and awe that i did while watching him bat.

One of the interesting remarks that i heard in twitter was Rahul Dravid is not just a person but he is a philosophy in itself. So, it would be a gross error on my part of talk about his entire personality in one post. It might actually require a complete book,so the focus of this post is just one area which i have learnt from him idolizing him.

Lets get back into history a bit-
Lords 1996: Rahul Dravid-95 gets over-shadowed by another debutant Sourav Ganguly- 148
Kolkota 2001: India beats Australia breaking their streak of 15 matches. Rahul Dravid- 180 gets over-shadowed by VVS Laxman's score of 281
Hyderabad 1999: Rahul Dravid- 153 gets over-shadowed by Sachin Tendlukar- 186. Both share World record partnership of 331.
Taunton 1999: Rahul Dravid-153 gets over-shadowed by Sourav Ganguly- 183. Both share second highest World record partnership of 318.


This list would go on a lot longer if i flex my memory muscles a bit more. This list clearly tells one more thing that Dravid despite coming up with a brilliant performance himself was left on the sidelines as his more flamboyant partners did better on the field on that particular day. This is something that happened with Dravid for most part of his career.

I have heard that Sportsmen have great egos and it is something that helps boost their performance on-field. It just amazes me to consume this fact that how Dravid maintained his calm and dignity and let others take the honours when he too slogged and slogged hard to achieve what he has in the above listed (and many other such) instances. The lesser mortals would have criticized their luck, made their angst on not getting the much acclaimed credit, expressed displeasure, would be burdened with jealousy, would have had the mind filled-up with negative emotions- but not Dravid. He just managed to remain on his own and found some sort of contentment within his zone as if he didn’t care of what’s happening outside the realms and boundaries of his mind as long as his performance has satisfied his own standards. If this behaviour is not iconic, nothing else is. I remember he once said that as long as he can face himself in the mirror with the feeling that he gave his best at work, he has done his job. How people perceive it is beyond his control. That’s pretty much the way he has managed to deal not only with the failures and successes but also the situations where he did well but didn’t get the limelight he ought to deserve. Though there were many such situations throughout his 15-16 year career where his good efforts were dwarfed but the way he reacted to those situations certainly earned him legendary respect.

Again, as i move forward my thinking to our work lives, there can be some situations in which you would be required to play a second-fiddle like- You get to share the credit of the work with someone else which (you believe) was mostly done by you, or you get to split and share your work responsibilities with someone especially when you think you are doing well in your role, When you despite being more experienced have to learn a new skill from a new-comer and so on. Most of the times such situations are usually enforced upon you by circumstances at work and are not by choice. These situations could happen to you because either you deserve it or it could be simply because simply life is not always fair or it could as well be beyond your control. While it is important to understand the reason why these situations are happening to us but at the same time it is not quite possible to eliminate these situations altogether from our work lives. So, our reactions to such events are actually important and often set the course for future (including influencing the career specific decisions like leaving the organization etc.). I have been in such situations at work myself much like almost pretty much like everyone.
It is in these situations one can take heart from how Dravid conducted himself on and off the field. Some of my thoughts below on how we can apply "Dravid-like" philosophy in such situations-

- He handled such situations keeping the overall big picture in mind. Rather than getting influenced by how others are judging him he tended to rely more on his self-assessment of the situation, having his own high standards and judging by his own yardsticks. Most of the organizations do have the performance evaluation process and the philosophies. While it provides the framework for judging employees, it often more useful and practical for employees themselves to have their own sense of “where there are vs where they want to be” to put things in right perspective. Become your own benchmark.

- Another thing that Dravid did extremely well in such situations was to give team more importance than self. This helped him put things in right perspective when credit moved away from him. Rahul Dravid said in Harsha Bhogle's book- "The Winning way" I have noticed that good team players view success very differently from the rest. They are motivated without really worrying about the credit..
One can always argue that Dravid was playing for the country and which is obviously not same as the situation when one works for the organizations. That’s a fair enough point but what is common in this situation is the commitment an employee exhibits to the overall cause. If one takes longer view of time, the same employee may get credit for something he has not really contributed much towards, at some point in his career. So things generally tends to even out (as they did in Dravid's case eventually) in most of the cases. Dravid had this rare ability to turn the spotlight on to others which is an essential quality while playing second fiddle.

- One more thing i think Dravid did extremely well is living this philosophy- Focus on what’s on your control (performance), not on what’s not (who gets the credit) . If we inculcate the habit of seeing every situation though the right lens, focusing on what we can control is often more practical. If an employee chooses to focuses on the things that he/she cannot influence, that’s something that often causes significant dissatisfaction and stress.

Prakash Iyer makes a mention of Randy Pausch’s story in his book "The Habit of Winning". The story revolves around Pausch during one of his first Football sessions- when his coach arrived at the session but without the ball. The kids were puzzled and one of them gathered the courage to ask him about the missing Football. To which the coach responded- "How many players are there on Football field?" Twenty-two was the response. "And how many footballs on the field ?" One- Responded all the kids in unison. "Right"- said the coach. "At any point in time, only one man has the ball. Today, we are going to learn what the other twenty-one people do on the football field."
That’s exactly what happens in the life too. While all the eyes are on the man with the ball, it’s the other twenty-one who makes the difference.

If Rahul Dravid would have ever played football, he would have probably been the guy not in possession of the ball all the time but probably someone who would have helped create chances for the goals. For sure, he would have been best at that too. That’s the character of a man. He just knows how to be in a hopeless situation and turnaround that by his sheer will and determination.

He is an hope to not-so-gifted people around the world that great heights can be achieved in any of the chosen endeavours by just the sheer power of human qualities.

Rahul Dravid is indeed an philosophy in itself. There's a Dravid inside all of us, its more a matter of searching him and bring to the fore.

While i sign-off this article, Dravid has peacefully retired and another great man has scored his 100th 100. This might hog the limelight again from Dravid since the appreciations are still pouring in after he retired. But like the man has always been, he would love to play a second fiddle now as well.

Thank you Rahul for the way you are!

Images Source:
http://www.mid-day.com
http://www.crickethowzat.com

Some recent public talks and learnings

In the month of February, i was involved in delivering a couple of public talks. Through this blog, I just wanted to share something about those as i have been doing in the past.

Topic name: Demystifying Globalization Testing:
This was a public workshop that i delivered on 9th-Feb in Chennai. This talk was organized by STeP-in forum as a part of their Pre-conference tutorial for STeP-in Summit 2012. I had delivered this talk on this subject last year in Hyderabad and had a reasonable feedback, which probably prompted the repeat show.
Overall, this was a 4 hour talk and the audience included people from diverse testing backgrounds. There was quite a bit of interactions around know-hows around various aspects of Globalization testing.
I was lucky that the Conference organizers shared some written feedback of audience, which i am sharing here as i received it-

what aspect of the tutorial did you like the most?
Communication Skill, unicode testing, clear and clarity, taken extreme care for creating presentation content with maximum information, illustration, detailed explanation ,practice test cases, language specific testing data, demos shown using tools, things to be considered during globalization testing, examples, real time and experienced examples, examples, approaches, introduced many terms of globalization.

what aspects needed to be improved?
Its too technical to start-up with, the presentation seems to be more comprehensive and it looks like a one which we can use for fresher’s, tools information are missing

The improvement feedback is quite valuable to me and i am glad to have received the same. I have already worked to enhance the workshop along these lines further.
The presentation that i delivered in the conference could be found here

Topic name: The emergence of Cloud Computing and Software Testing
This was the talk that i delivered as a part of Plenary session of STep-in Summit 2012 on 16th-Feb. This topic has always been close to my heart as not only that this topic is an emerging one in the current times but also that i could experiment a lot on my delivery/presentation style. Some of the things that i tried included-
- Prepared the presentation with Associative learning principles.
- I was always fascinated by the movie- Rang de Basanti . One of the things that i liked about this movie was that it had 2 parallel stories running (one current and one about an event in History). I could apply this concept in this talk.
- Since the presentation was about the Cloud, i actually ran the presentation over from the cloud connected through Internet (and didn’t use Microsoft PPT for a change). This eventually proved to be a good justification for what i was preaching here. Cloud really works! (and i didn’t had any hiccup in the talk).

Overall it was a great learning experience.
The presentation that i delivered can be found here

I would honestly welcome any feedback on the content of these presentations.

What do you do when you "Hit a wall" as a tester ?

Further to the thoughts i shared in the post Great bugs exist "Beyond the Obvious" , i wanted to share a slightly different perspective.
The earlier post talked about how to challenge the notion of Stable components and working to redefine your Testing challenge around these components. It brought into focus the point that in Testing important things aren't always in front of us but often they are hidden. Below is one more perspective that i have found in my experience around challenging the things that visible and obvious and go some levels down to hunt the invisible and unobvious (read Bugs!)


In my experience, when a tester focuses on testing a Software application as a Black box, often the focus stays on two things- one is the User interface being shown in front and second is the Test case document being followed. Even if a tester does not follow a formal Test case document, it sometimes invariably occurs that focus remains on the how the application's UI is behaving under different functional conditions. There is nothing wrong with having such a focus as it helps to find the relevant bugs and simulate the user behaviour. On the contrary, in my experience, i have seen that limited focus on Software only as a Black box sometimes tend to limit the perspective and cause the shortage of ideas to test.

In running parlance , such a behaviour is sometimes called as "Hitting the Wall" i.e. when a runner has spent all his energies (happens because of depletion of glycogen stores in the liver and muscles) but still has a long distance to cover. When such a thing happens, a runner seeks inspiration from other sources to reach the finish-line. Similarly, a tester "Hits the wall" when he feels consumed, when he feels that all the ideas that were left to be tried have been tried and tested. I call this as a sort of trap because Software usually offers invariable no. of ways in which it could be tested all of which resides in tester's mind.


In such a situation of despair when the bugs seem to have dried up, the idea is to find the key that unlocks the mind of tester. Its actually the time to look "Beyond the obvious". One of the things that i have found useful in such situations is to gather the information around how the source code logic is developed. Always looking at a product from the Black box perspective, it usually becomes hard to know how the source code works. But one of approaches that i have found helpful is creating a flowchart (or mindmap) detailing how the internal logic works with the start-point being how user talks to the application and the probing what checks or logic would be built in the source code. As a tester, ask probing questions about how the internal logic works and dont be satisfied till you get an answer that makes sense. (That’s where the good relationship with Developers help!) In doing so, a lot of uncomfortable questions about the logic and thus unobvious bugs gets revealed.Having such conversations with developers help in more ways that one. It helps you enhance your credibility but also many times I have seen it gives ideas to developers on how to improve the code.

One more approach or heuristic (widely used term these days) is analyzing the source-code check-ins to derive more meaningful tests. Will talk about it in the coming posts.

At this stage, I remember one more story from Sherlock Holmes-

This point is also made in the oft-quoted Sherlock Holmes short story, "Silver Blaze", about the disappearance of a championship race horse. During the investigation, a detective asked Holmes: "Is there any point to which you would wish to draw my attention?" Holmes replied, "To the curious incident of the dog in the night-time." "The dog did nothing in the night-time." "That was a curious incident," remarked Sherlock Holmes.
For our fictional sleuth, at least, sometimes the most important things are those that don't happen. In this case a non-barking dog provided clue that the thief was probably someone the dog knew, and that narrowed the list of possible culprits.

If we're going to be resourceful as a tester, we should also take note of what's obviously not present (or not happening) as well.

I know this blog represents just one modest idea, Do you have more ideas on how to come out successfully when a tester "hits the wall" ?

Images Source:
http://www.softechniques.co.cc
http://smiceproductions.blogspot.com
http://www.rostudel.com

Key professional lessons from a Long distance run- Part-3

I recently participated and completed the Contours Women's Day 2012 10K Run . While the run was as much a tribute to the women as much it was to my passion for running, i could gather some useful lessons from this run as well.

This post is in the continuation of the previous post#1, and post#2 on the same topic.

My key learning from this run was-
Starting all over again is a often underrated but an effective skill that could be learned:

To explain the context here a bit. The route of Contours Women's Day 2012 10K Run was a tad different that the ones i have ran in the past. Though i have run on the park (in Bangalore) in which this run happened but not the same route. The official definition of route said-
The 10K starts from Kanteerva stadium, goes into Cubbon park and does 2 loops inside the park and ends with one loop inside the stadium.

So basically it involved 2 loops inside the park. Having multiple loops during the course of a run is quite a normal thing to do given the fact that any city hosting the run would have only limited space and then there are external factors like traffic etc. that proves to be a deterrent in having one long stretch as a usual route. Running on a route with multiple loops have got its own share of benefits like you get to experience the track and beauty of the park more than once, you get familiar with the track and there are less chances of you facing unknown situations as the run progresses.


These benefits are surely valuable but one thing that i realized while on the course of run this time was a unique challenge the run with multiple loop poses to the runner. With all the hard work and enthusiasm, i managed to complete the first loop only to find out that i was at the beginning of where it all started (first point of the race). The very fact that instead of seeing a finish line, you get to a sort of start point in the mid of the run can really pull you down almost as if giving a feeling that nothing much has been achieved despite all the running and slogging done under the scorching heat. Though this is really a false notion, which our mind knows while running but this is something that our body doesn’t comply with at actually not seeing the landmark at completing half the race (unlike other runs, this run didnt have markings at every Kms indicating how many Kms done). This is a sort of funny situation to be in but it has happened with me even in the practice runs. The key in such situations is to make sure to pull yourself up and get on with the run as if you have just started. Every step taken hence after gives you confidence that you are moving in the right direction.

Fast forward to our work lives, there are many situations in which we feel down and out like the following-
- When our good efforts in the projects fall short of expectation and the commitment is not delivered.
- When a superior comes and reprimands you for a lapse. You tend to feel that your reputation gets at stake and doesn’t really like the idea of rebuilding the same.
- Some mistake done while trying out a new idea makes you start off from the beginning.
- You are working to setup a complex Test environment and only at a very late stage you find out that a misstep in the early stage has caused you to restart the efforts again.
There could be many such examples.

The above situations have two things in common-
1. All these situations are not the ideal of the situations a professional can face. In some cases, it can even be termed as a crisis.
2. All these situations are temporary and not permanent.

The faster we get our minds to accept of the temporary nature of these activities and move on to the forward step, the quicker will be come out of the seemingly messy situations. While it is necessary to introspect about the mistakes but overly dwelling upon them take us a step backwards without us even realizing. Its something akin to the feeling that I shared of starting the second loop in a long run.


In his autobiography, "A Champion's mind" Pete Sampras shares his evaluation on how he was able to win so many matches over so many years. One of the relevant things he shares is-
Throughout my career, whenever i made a critical mistake, i just wiped it off the hard drive. I don't really know how i developed that ability to move on instead of dwell upon, but i had it. My guess is that it was some mental function, rather than an emotional one- a kind of extra-high focus on success. And a lot of it was sheer will.
If you train yourself not to let things get to you, they don't."

This assertion by Pete Sampras makes it clear that whether in work or in our personal lives-Starting all over again is a skill that could be learned.

Just do it!

Images Source:
http://www.sayingimages.com
http://www.keepingupwiththewalkers.com
http://ebookstore.sony.com

Great bugs usually exist "Beyond the Obvious"

I was recently reading the book "A Whack on the side of the head" and came across an interesting Sherlock Holmes story-

It seems that Sherlock Holmes and Dr. Watson went on a camping trip. They pitched their tent under stars and then went to sleep. In the middle of the night Holmes awakened and exclaimed," Watson, look up and tell me what you deduce". Watson opened his eyes, and said,"I see billions and billions of stars. Its likely that some of these stars have planetary systems. Further more, I deduce that there is probably oxygen on some of these planets, and its possible that life has developed on a few of the. Is that what you see ?
Holmes replied, "No, you Idiot. Somebody stole our tent."

I would like to share some perspective based on my experience in Software testing around this story-


The main point of this story is that sometimes the most important things aren’t the ones right in front of us but rather the ones that aren't. Most of the times when we test a Software product or application, the usual tendency is to test the newly developed areas which will have more likelihood of having bugs. This approach is pretty valid as it helps to attack the new code and find as many bugs as possible. Over a period of time, when the code changes starts to get reduced, the no. of bugs also tends to go down. What i have observed is that Testing teams start labelling the different modules in the Software products as "Stable", "not-so-stable", "unstable" depending upon the history of bugs found, doing the defect trend analysis. If the bug trends show one module to be stable, the usual strategy is to cut down on the tests and save time and efforts. While this approach may be quite obvious to follow but keeping overall view in mind, this approach could prove to be grossly inadequate. Here's the reason why-


Stability of a Software component depends upon myriad of factors beyond just the bug trends, Some of them are-
- Have i really tested the component adequately ? Are there any more heuristics that i can apply ?
- Do i base my test coverage only on the basis of written test cases or do i also take into account the exploratory testing efforts ? How do I measure Exploratory testing efforts ?
- Have the code changed in the recent past ? How do i know if the code has changed ? Did i follow the code changes check-in?
- How is my Software component getting impacted with integration from other "nearby" components? Are these neighbouring components stable too ?

As is evident, the stability of a module is actually a function of many things of which the Defect density and Defect trends are just one part. It is grossly inadequate to just analyse the bug trends but not have the trends specific to changes in the code, test coverage including exploratory testing etc. in front of you. Like with the profession of farming, testing also follows the principle of "the more you sow, the more you reap". The more test coverage and testing time you give to a certain module, the more chances you would have to find defects. Like in the Sherlock Holmes' story, dont overlook the obvious. It is often quite risky to fall in the trap of "Stable module having no bugs", eventually it may be your goldmine of bugs.

One learning i have had over the years is- When Software tends to get Stable, treat that as a time to redefine your Testing Challenge and focus. It often helps to go beyond the obvious and attack the stable areas with a renewed approach.

Which obvious aspects of work did you challenge today ?

Images Source:
http://blog.rezscore.com
http://www.vigilantsw.com