Mr Tester, you are a Professional first!

One of my articles recently got published in the Testing circus emagazine. Including it in my blog as well for your comments and feedback. Please read on-

I was in a Panel discussion in one of the Software Testing conferences and one of the question that came from the audience was- "I am new to Software testing. What do i need to become a Good tester ?"

I had thoughts of mixed flavors running inside me when i first heard this question. A part of me was proud on this question being asked, Proud because i have seen our esteemed occupation grow from the times when it was not as fashionable to be a tester as it is now. That was the time when testing was more considered as a group of failed developers, testers a mere second class citizens in the organization and the testing group was more regarded as an unnecessary evil.  I was obviously happy that this question atleast gave me a momentary happiness to me that our profession has come of age, somewhat. (not that i need any such assurances now).

The other part of me was rather intrigued thinking if at all this was a right question to be asked from a person new to testing or may be even otherwise. Now, Why did i feel intrigued ? Let me try and put a perspective here-

For all that Software testing has achieved as an occupation over the years, i still believe it is somewhat at a nascent stages. To put the records straight, ours is not yet a 100+ year profession. Not that i am treating 100+ year as a some sort of benchmark to achieve greatness status but longevity is a factor or rather a crucial factor in deciding the relevance of a field (mostly in the eyes of people who do not belong to the said field) and also as a proof that a profession has stood its ground and survived and thrived ups and downs that come with time. On a lighter note, i was reading an article recently that appeared in Times on India titled- "Whats the shelf life of a techie (read Software professional) ?" and answer too appeared in the title- 15 years. :-). [If this were true (for which i have my own doubts) then we are entering an era where professions will be long lived but professional's work life span wont last a whole career span.]

Anyways, just to elaborate myself for the sake of clarity- Software testing has a multi decade history and it has evolved in many unique ways with the advancement of technologies- from mainframe to mobile platforms and also with people's creativity exhibited over the years. At the same time, it is fair to say that most of the organizations have started realizing the importance of Software testing as a separate field not so long ago- may be a decade or two back.

Who is a professional ?

I did make an interchangeable use of three words in my narration so far and these are- "Occupation", "Profession" and "field". They all, in essence, means the same thing. But what do they mean ?

Oxford dictionary defines the word- "Profession" as "a paid occupation, especially one that involves prolonged training and a formal qualification". 

Though this definition gives some light into what a Profession is but this definition in itself is quite narrow. It somehow gives a sense that people engage in a profession to get paid. Of course, getting paid is important but the true professionals do not engage in a profession for the lure of earning money alone. Subroto Bagchi in his book "The Professional" goes as far and says that "A professional who sees his work primarily as a means of earning money, runs out of meaning very soon.Being a true professional is nothing short of a religion and the capacity to serve is indeed a blessing in life."

Isn't being a tester and a professional one and the same thing ?

Now why did i feel intrigued on that question being asked ? Skills, without doubt, forms a very important part of any job in this world. Without mastering the technical skills required for a position, one wont even be qualified for an interview for a particular position. So my attempt here is not to undermine the importance of the technical skills that a tester would need. So, i am sure when a person asked- "What do i need to do to become a Good tester ?", the focus of the question was more towards the technical skills and honestly, there is nothing wrong with that. Any person new to any profession would always want to master the technical skills quickly to be eligible to apply for the position.

My main reason for intrigue was the fact that, more often in our quest to become experts at what we do we tend to forget some of the most basic facts. And that fact is-  When we embrace a particular field as our chosen career, our responsibilities does not start and end at mastering the skills need to execute or exceed the job expectation but it in reality goes much beyond. 

To make a point further, I have listed a handful of situations that we might face in our professional lives and followed up these situations with a question-

- A person finds a High severity, rarely reproducible defect in the Software component he was handling on a day before release. Should he go and inform the Management (despite fearing his lack of performance impressions) or he remain quiet and not report the bug (as anyway it is rarely reproducible and will be rarely noticed) ?

- A person was expecting to get promoted but for some reasons didn't get it. Should he go around criticizing the management behind their backs or show demeanor to initiate a discussion keeping calm ?

- A person is knee deep in a technical problem, whose solution is likely to be available with other team mate. He does not quite reach the other guy for help. Is it ok to let professional ego slow the pace of a project ?

- A person meets another colleague on a pathway, they have a discussion and as a follow-up, this person promises to send some information to the colleague in 2 days time. A week goes by and the colleague doesnt get the required information. Is it ok to be casual about the commitments made to people who are not your bosses or Managers ?

- A person installs a Software tool and learns it's very basic functions. Next thing he includes the very mention of the tool in his resume as one the "skills" he has. Is he right in claiming expertise on this tool (which may even turn out to be the basis of him getting an interview call) ?

Just ponder over the answers to these questions. My intention here is not to mention what are the right answers. I would rather answer these questions with another question- "Would you choose what is right in each of these situations or what is more convenient ?" The most favorable answer probably depend upon a lot of factors including the personal and organizational value system. The point i was trying to make here was that our response to many of these professional situations actually determines how we eventually get perceived in the organization and the perception that an individual creates matters a lot in deciding the elevation one reaches in one's career. If skills decide and define your entry into the profession, it may not be an exaggeration to say that a true professional conduct (along with other factors) define your ascent.

To me, being a successful tester and being a successful professional are not mutually exclusive but if one works hard to achieve this combination right, then we really have a powerful, world beating person at hand.

Concluding words...

Many people go through the whole career being committed to one profession and some get to choose and work on multiple professions in one lifetime. A true professional remains a true professional even if he or she changes the field altogether. In other words, the factors that makes one a professional, for most part, does not change with the change in profession.

Quite a sizable chunk of problems faced in Software Testing industry can be attributed to the lack of true professionalism as a root cause. In our almost mad focus on attaining skills, we do tend to lose the relevance of being a true professional. What it takes to become a true professional is a lot more than just learning the skills needed to master your chosen field of endeavor.

We always hear the terms like "Expert tester" ? Why dont we often hear terms like "Expert testing professional" ?

Would you like to become one ?

Image courtesy:

http://fbcoverstreet.com/Facebook-Cover/Be-Professional

http://www.joho.se/category/10-quotes/

Some tales about Cloud, testing and more- A corporate talk

A bit old update but thought to share anyway. I was invited to deliver a talk at the organization called "Target" a while back in late July 2012. I was requested a talk on the topic related to Cloud computing and testing. The prime reason for this talk was that there was a growing interest in the organization and the audience about Cloud computing and thus the nature of the session was more educational.
I had chosen the topic name as "Some tales about Cloud, testing and more". The presentation can be located here. There were a lot of interesting questions from the audience especially around the real-time implementation of Cloud computing in their setup and also the potential concerns around the Security.
A good experience overall.

SofTec 2012- Evangelizing Express functional testing approach

On 14th-July-2012, i was invited to speak in the SofTec 2012 conference in Bangalore. I was happy to be participating in this conference as this was my third straight year presenting here and each time a different topic. Previous presentation details are here- 2010 and 2011 .

Like with most of the testing conferences i have been to and presented, this conference too had 2 parallel tracks happening. One was "Test Technologies/Methodologies" and other one is "People/Process/Business" track or Management track in simpler terms. Over last many years my experience is more tilted towards the Management side of things but i do make it is a point to speak on the Technical track because of many reasons. The prime reason being this is one way it helps to keep me rooted to the foundation work (I call this foundation work because that's where core engineering value gets added) and also it helps me keep my professional thinking balanced.
So whatever the reasons, this time too i did do a presentation on the Technical Track and topic that i chose was- "Express functional Testing approach- doing more with less".

Overall, the presentation was well received. I must say in conferences usually when many speakers boast about the supposedly high-end topics like Security, Performance testing- a topic on Functional testing may sound a bit off-beat. But the fact i have experienced is that its usually the things which one takes for granted as easy is where the mistakes happen. Functional testing is one such area.

Many say it is easy, many say they wont be using their Engineering capabilities and brainpower if they did "just" functional testing, many say functional testing is "only" a manual testing and many such things but the fact-of-the matter remains it is very hard to master functional testing even after spending years on it. More often it is conducted in a closed box i.e. create test plan, create test cases, execute tests, report bugs, regress bugs and many such steps. I call this closed box because people tend to do all these activities without even questioning the need of these and they eventually see them fall in a rut. I always believe there are always 2 broad ways of doing things at work-
1. Do them as they have been done in the past.
2. Learn how things were done in the past and question if there is a better way.

What i have found is that the very act of questioning the way things are done is easier said than done. It requires much broader knowledge to suggest alternative ways and to attain that knowledge requires constant reading and practice. The approach that i presented in this session was more of a result of questioning the obvious and challenging the status quo.

More about this approach could be found at the presentation
here .

Would be keen to discuss this more if you are interested. Do let me know.

Here's the press release to this conference.

An overused but empty phrase- “I told you so…”

There is an ample literature available on importance of failures and how they teach us to be better human beings provided we are willing to learn from them. The current corporate world that value perfectionism more greatly often makes learning from failures somewhat challenging. But i do believe that failing is an important part of growing. I wrote about failing faster as one of the good ways of failing a while back. Since then of course, i did experience failures and have tried to learn quite a bit from what i wrote and learned earlier.

While it is important as to how you deal with you failures, at the same time it is important to deal with the surrounding vibes that get generated when something doesn’t go as per the script. One of the oft-heard phrases i have experienced in such circumstances is a deferred piece of reinforcement called as "I told you so..." (only if you heard me on time).

Before i delve further into this topic, i wanted to share interesting story in the book-  The case of Bonsai Manager .  Here it goes-

Dave Kote used to work in GE during 1980s, when Jack Welch was "Neutron bombarding" the company. Dennis Dammerman had been appointed as a CFO in 1984 in succession to the very successful Tom Thorsen. Dammerman's mandate was to renew the finance function, which was rather set in its ways. Jack Welch balked at the wasteful bureaucratic procedures and the bloated number of data obsessed staff at the headquarters.

35 years old Dave Cote was at a relatively junior position, three levels below Dammerman. One of his tasks was to compile a detailed report of sales in every country in which GE operated- not for the current period- but the project sales for next 5 years. Dave enquired from his peers and immediate bosses on why this report was being prepared and to what use was it being put. The response he got did not provide him the clarity, but was accompanied by the request to carry on doing it. "While we have not used it in the past, we may in future", was the message. Dave was puzzled and did as was required.

One day in 1986, Dave received a phone call to meet Jack Welch. He became quite anxious and nervous on the prospect of meeting Jack. He entered Chairman's room, armed with every possible question that could be posed to a young financial analyst by an aggressive and colorful chairman.

"So, Dave, you look like a smart guy, why the hell do you ask our operating managers to forecast sales for next 5 years, and anyway what do you do with this data ?" thundered Welch.

"Well, that's a fair question", replied Dave tentatively, "I circulate it to the departments that plan for future strategies of the divisions and perhaps it facilitates the planning and allocation of resources."

The conversation continued in the predictable manner for a while longer and concluded with the Chairman saying, "I am going to get Dennis Dammerman here, and ask him why this kind of stuff is being done. How bloody wasteful!". Dave Cote was convinced that he was going to be fired.

Upon exit from the room, Dave Cote immediately contacted Dammermann to tip him off.Dammermann was quite calm about the whole thing, and seemed self-assured about how he would handle the matter. Dave kept repeating to Dennis that "Jack was really upset".

Soon thereafter, the practice of asking for and compiling such data was discontinued. The episode still bothered Dave because this outcome could have been achieved had the initial issue raised by him been squarely addressed. However, not being the "I told you so" type of manager, he set about his other tasks, a bit puzzled and perhaps a bit wiser. He had still not been fired, so he kept a low profile.

2 months later, there was a company party. From a distance, the chairman noticed Dave and beckoned him. "So have you stopped producing that stuff ?" asked Jack Welch.Dave Cote worried that a further inquisition might follow. A colleague, who was standing in the group, interjected, "Jack, you should know that Dave was the guy who kept questioning the need for this report and had recommended stopping it".

"Is that right ?" asked an aghast Jack Welch. "I did not know that. Nobody said that to me."

That evening, in an appreciative and mentoring tone, Dave's boss, Dennis Dammermann said, "Dave, you don’t know how well you have emerged from this episode. That fact is that you wanted to stop it. Yet, not once did you defend yourself by saying, "I told them so." Both these insights have gone down very well with Jack. Good things will happen to you."

Some months later, Dave Cote was selected for a much Senior position, 3 levels higher- a rare honor and privilege at GE.

After i read this, there were a lot of things that sounded relevant in this story. Of course, there is a bit of destiny at play here especially looking at the end result but one thing that is reflective here is an attitude had gotten eventually rewarded here. An attitude that shuns "I told you so..." thought line on seeing something not work.

In our work lives, we are faced with many situations where we could have predicted an outcome of an event, change or a process to be negative and eventually when that negative outcome happens, the first thing our minds wants to do is to sing the tune of "See, i told you so...".

Personally, i see the phrase "I told you so..." quite critically because-

- It is actually a dead statement, of no value. Who does it benefit afterall ? To the recipient, who is anyway down facing negative consequences of the event. Certainly not.

- This statement may give some righteous feeling to the person who says this but may possibly hit recipient’s self-esteem (especially when all he may be anticipating is some empathy).

- This statement promotes a bit of negativity at the work place where the person who uses this seem to be saying- See, i was better than you at foreseeing consequences.

- This statement may eventually be a backward step in a situation which would already be so grim. Imagine, a team facing crisis and someone comes and says that "I told you this will happen". Suddenly, instead of thinking about the way out of the situation, everyone goes back in the past thinking how we could have made better decisions.

- This seems more like one of the parental phrases who might use it to discipline kids. Work place,for sure does not contain any kids, so why use this.

- This may not even be useful completely in postmortem of the situations or projects where the focus is usually the problem and not necessarily the person.

- Uses a statement of this kind affects the risk taking abilities of an individual/team in question. It is as if saying- "I warned you and you still took this step." This may refrain people from trying anything new.

- If such a statement is overused in a team, this probably is a sign of weak team work where passing the blame is the key.

- This statement can only be helpful if you have to hopelessly prove a point against all odds, that too only to some extent.

I am not sure if not using this phrase will get one the rise like the case of Dave Cote but i am sure that over-use of this term will not take one forward for sure. While i will write about why people tend to overuse this phrase sometime later, but it for sure does not add any value to relationships- personal or professional.

When was the last time you heard- “I told you so…” ?

Images Source:

http://www.zdnet.com

http://www.myfacewhen.net/view/166-i-told-you-so

Presented a case study on "Rapid Globalization Testing approach" and an impromptu Panel talk

I got to speak at ISQT's "STEP-AUTO 2012 South" Software Testing Conclave conference on 9th-May-2012. The topic of the talk was- "Rapid Globalization Testing Approach". Of the talks that i have been involved in delivering in the recent past, this talk was a welcome change primarily for the reason that it was after a while that i was involved in presenting a case-study. Most of my other talks had majorly been new concepts or some technical areas related to testing but this talk was primarily involved around an approach that we came up to deal with some tough challenging project related situations that we were faced with. I will be talking about this approach a bit more in the upcoming blog posts.

I along with my colleague- Shivaraj Shet delivered this talk. We did experiment a bit on the narration of the whole topic with each of us asking each other questions and extracting information from each other.

Overall a good experience. The presentation can be found at- here . And watch this space for more details around this approach.

Towards the end of the presentation, i got an opportunity to  be a part of the Panel talk on the topic- "Nurturing the Software Testing talent". Since i was not aware of this session, it was a kind of extempore session which i got to prepare only 30 minutes prior to the session along with other panel members. Was a good experience overall and some of the key points that i could recollect was-
- Look for a ways to tap the Software testing talent in the colleges.
- Advising Software testers to look for more avenues of Horizontal growth and enhance learnability.
- Need of the hour for our profession is the Research. Need to find more avenues to research on Software testing related areas, Innovate more and build strong credentials.
- Software Test Architect is a role that people could pursue more with their interests and drive and willingness to do something differently with their careers.

Do share your thoughts and discussion items.

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

How well do you handle petty jobs at work ?

There is a certain fanciness about mentioning Innovation as one of the competencies that would take an organization to glorious heights in future. Innovation is always talked about at length by executives as one of the key things that would help an organization sustain and grow its momentum. It has been one of the areas that everyone wants to improve upon to drive their careers forward.

I think all this buzz around Innovation is largely justified given what the companies like Apple, Google and many others has done in the past. But sometimes this buzz overshadows the value of precise execution of the projects, which is sometimes even more important.

I talked about visionary organizations like Apple and Google but while these organizations were breaking paths on Innovation, China was silently gaining the mindshare of the people all around the world with its work primarily around manufacturing. Did they Innovate as well as the US companies ? Probably not but what they mastered was the art of executing well even if they were working on a product as general as a table cloth or a general decoration item or anything else (afterall, everything around looks to be "Made in China" ).
This example kind of gives me an idea that great careers could be build on the premise of Execution excellence even if the Innovation quotient of a person is somewhat reasonable (not great!). If Innovation is a sought-after skill in today's world, Execution excellence is a mandatory one.


Before i seem like making less sense, let me explain what i mean by Execution excellence. Simply put- Organizations make big plans promising bigger, grand results. The results remain just a promise on paper till someone goes in the field, makes his hands dirty and executes on the plan. Excellence in execution takes us closer to realizing those lavish plans. Though Execution of the projects is important, it increasingly amazes me to see that many people find the execution boring. Especially the part of execution where one has to go through those chores repeatedly, again and again in an almost monotonous manner. Let me give some examples here-
- One of the projects that i was involved in testing, at a crucial release stage, required a tester to do the Installation of the product almost countless times (more than 100) in different platform to debug an issue. To put it in other words, a tester needing to Setup OS (5-6 supported), Setup browser (again 5-6 versions), Install the Third party products, Install the Application under test and wait for the error. Though this was a routine job but was important to ensure a seamless customer experience.
- Another example, in an efficient functioning of any team, the regular housekeeping activities like managing of hardware, inventory, information etc. is important but at the same time routine and monotonous.
- Sending a weekly report when nothing significant has happened can be considered as boring and needless when it still serves important status needs of the recipients.
- For a manager, meeting his team regularly may be a routine affair and if not done may lead him to be quite out of sync.
- Again, a Tester going about executing the tests that have passed in the past just to ensure that nothing has regressed in the product (after all, not all testing can lead to bugs!).

This list can go on and on but the key questions are- Do we really give adequate importance to seemingly Petty jobs ? Can we do these jobs/tasks better than they are being currently done?

Further in this blog, i am sharing some of the thoughts/perspective around handling such tasks-

Understanding the role, bigger picture:

Harsha Bhogle in his book- "The Winning Way" talks about an interesting instance-

Unable to work out a way to get Tendulkar out, Naseer Hussain (in 2002 series), decided to frustrate him by bowling a largely negative outside the leg stump line. The man assigned to do the job was Ashley Giles, a workman like spinner who kept things tight. For the next 11 overs, he bowled the outside of leg stump to Tendulkar, a tactic that drew much criticism. But it did keep Tendulkar quiet and ended up frustrating him. "If you cant bowl him out, bore him out.", the critics said, but as Hussain suggested afterwards, it was a better option than Tendulkar getting a century! It was a boring job for Giles to do and the key lay in the Captain's communication of its importance. If a player knows his role and implements it well, a seemingly small role can become important.

It is thus important to understand the bigger picture the task is helping achieve. Every job on the earth has its own dull moments and more often the difference between "just" successful and "greatly" successful lies in how one handles those dull moments. It is also critical to understand one's role in handling petty tasks. As in this example, Giles knew the line he had to bowl and not try anything else. Role clarity comes with effective communication not only on Leader's part but also the follower's part. A follower can always ask right questions to understand/clarify what is expected of him.

Being a true team player:

Rahul Dravid in Harsha Bhogle's book- "The Winning Way" talks about his view-

I have noticed that good team players view success very differently from the rest. They are motivated without really worrying about the credit. That’s not always easy. Anyone who has fielded at Short leg, knows what a Thankless job it is, besides being risky. You put your body on the line, have to work damn hard and may have nothing to show for it. When given that position, there are those who are reluctant to put in the hard work, hoping that will be made to field in another position the next time around, and there are others who give it their best and actually become specialists.
Situations like diving or fielding, in which you put your body at risk, or where you are required to play a role outside your core-competence areas demand more work from a player and therefore require you to put the team before self. The funny thing is that you cannot hide your attitude from the team mates. If you're selfish, you will be found out in no time at all. But if you are a Team-player, the team will know and appreciate that as well.

True team player attitude calls for helping team deal with difficult (and also monotonous) tasks by setting an example. Handling petty tasks often require more patience and situational awareness than many of the other tasks. The way these tasks are handled often brings about the Leaders in people.

Having a Strong Professional value system:

Subroto Bagchi in his book- "The Professional" in one of the chapters makes a mention on how he had been able to do justice to his writing talents along with handling a high profile job. He has 3 books and multiple columns to his credit, he says-

...One point i want to make is importance of taking every assignment seriously. Whether i wrote a column or an invited occasional newspaper piece or for that matter a book, I gave it all i had. To me, my writing commitments were no different from a purely professional commitment at work. This called for many personal sacrifices because it was always like having two jobs.

Though his point is not exactly about handling monotonous task but many things that he talks about here are applicable to the context e.g. "Treating every assignment seriously", "I gave it all i had",
"Professional commitment, these are all valid metaphors for handling the dull, monotonous work. And if these are kept in mind, i believe every task will get the importance it deserves. So, having a strong Professional value system helps deal with any challenging or dull professional situation.

After all, no amount of Innovation can really help us completely get rid of seemingly boring jobs. So why not embrace it and give your best shot!

How do you handle petty jobs at work ?

Image Source:
http://shafiq-itzmine.blogspot.com
http://walkingsatellite.blogspot.com
http://www.jimguittard.com
http://www.ecb.co.uk
http://www.bernews.com
http://shopping.indiatimes.com