Harsha Bhogle in his book-"Out of the Box - Watching the Game We Love" has a mention-
Peter Reobuck once told me of the twin loves of his life: cricket and the English language. They work well together; certainly in our game which lends itself to fine writing.
The above lines have an unique reflection about people having Multiple passions and interests. People's talents are usually not limited to being good at just one thing for life (we usually refer to as Passion) and are helped immensely by parallel interests. In case of Peter Roebuck, its Cricket and Speaking, Writing in English language.
Jack Russell came into limelight when was a part of English cricket team in 1980s and 1990s. Though not being formally trained at art, he had a special interest in art and took up as a Full time artist after his Cricket career was over. Not only this, he also is a Football goalkeeping coach.
In Michael Phelps biography (Michael Phelps The Untold Story of a Champion) by Bob Schaller, there is a mention of fellow swimmer Natalie Coughlin . He says “A graduate of Cal-Berkely, Natalie Coughlin has interests outside of the pool that means as much to her as her life in water .She goes out of her way to keep balance in her life, and while swimmers everywhere do doubles and train hours every single day, Coughlin is just as prone to balance a single daily workout with Pilates, walking her dog or Spinning.”
Pradeep Soundararajan in his blog wrote this post giving some insights into how interests different than Software Testing help the craft. Looking at the Blogosphere, there are so many distinguished testing practitioners who not only are the experts at their craft but also find time to do write frequently in blogs, magazines, speak in conferences and other relevant forums. All this really gives a view that there are two types of people in the World- One who find time to just do what they are supposed to do and the other half being the people who not only do what the profession demands but also goes a few notches beyond that and manage multiple interests. Though there may be doubts about accepting such an extreme classification of the world, but one thing is for sure that there exists people who seemingly achieve more in a day thereby giving an impression to the external world that God probably was more kind to these guys and gave them more than 24 hours in a day. It is often intriguing to me to wonder why some people manage different passions so well while some people make an attempt at the same but with little success. My mind had been working overtime to demystify this fact and following in this post i would like to share some thoughts around it. The text that follows is mostly in the form of answers to some relevant questions involving handling of multiple passions-
Am I "Only Interested" or Am I "Fully Committed" ?
Ken Blanchard in his book "The Heart of a Leader" mentions-
I learned from author and consultant Art Turock that we need to make a distinction between being interested and being committed. When you are "interested" in doing something, you only do it when its convenient, but when you are "committed", you follow through no matter what, no excuse."
I think this is a very relevant observation. I think people who manage multiple passions are not only interested and deeply in love with their areas of interests but are also hugely committed towards the same. They operate in a mode as if it’s their responsibility to contribute towards their passion every day, every hour no matter what. Many people get inspired and interested in pursuing additional interests but fail to pursue it for a longer period of time because the convenience factor creeps in with the lack of commitment. If one is committed to the cause, it’s not impossible to cross any obstacle.
If you like to do something but haven’t been able to pursue, just ask- Do i really want it badly ? Am i really only interested or committed also ?
The sooner one sorts out the answers to these questions, it lends the desired clarity to live with one's passions.
Am I able to "prioritize" effectively ?
I was having a conversation with J.D.Meier about managing multiple priorities and why individuals even while having interests in multiple activities aren’t able to contribute enough or balance properly. Here is what he had to say-
Here's what I do:
Mapping Out What's Important:
- Identify the most important results in each area or hot spot in your life (just the top 3 result for each hot spot or interest)
Producing Results:
- On Mondays, I identify 3 results for the week
- Each day, I identify 3 results I want to accomplish (this drives my day)
- On Fridays, I reflect on my results. I identify 3 things going well, and 3 things to improve.
Monthly Themes
- Each month, I pick a theme for focus. This is how I can balance across my interests. It allows me to focus less on one thing, while I focus more on another.
This is a quick start guide that helps - http://sourcesofinsight.com/2008/12/10/the-zen-of-results-free-e-book/
I did try this suggestion and found it to be quite reasonably working. Of course, like with any other approach, this approach also requires one to be disciplined enough to follow it consistently. One thing that this suggestion helps achieve is the required focus on your interest at a given time. One of the challenges in managing multiple passions is effectively juggling between the different priorities while not losing the focus. Getting to work effectively towards three focused areas in a week helps one take baby steps towards an eventual achievement. The beauty of this approach is that it does not suggest you to take up huge tasks and then later struggle to complete them (that’s the reason i used the word "Baby step" in the previous sentence). Like with every endeavor- Patience and Perseverance is the key here too. This is because Baby steps taken in the right direction leads to Giant steps in a longer run.
The question may arise, whether an individual should talk about more than 3 priorities at a give time. Here's how J.D. Meier answered it, when i asked-
Why not finish the first 3, then bite off more?
The value of 3 is that you can remember it without writing it down. Test yourself. Today, I had 3 priorities - complete my draft vision, confirm the budget, and sync w/my partner group. Did I have lots more things to do? ... Sure, but those 3 were my best bets for the day. If I got through those 3, I could always bite off more. What I didn't want to do was have a long list of things I couldn't remember.
The rule of 3 was actually found to be the most effective number in the military for people to remember outcomes without writing things down. I didn't know this at the time. I'm just happy that the military came to the same conclusion. I lucked into it :)
Isn’t this Simplification at its best ? Clear mind does achieve more than a cluttered mind.
Am I able to "create" enough time ?
Of course, the common thought people who want to do more but aren’t able to do so is that they don’t have enough time. From my observations, the idea is to create time for self, for what you want to do.
There are infinite ways one can look at the day and build up time for something you really want to do. One of the ways, Subroto Bagchi mentions in his book- "The Professional" when he introduces the term- "White Space"-
I do not know how the term White Space originated. In telecommunication, it denotes frequency allocated to a channel but not used. Typically, broadcasters are provided additional frequency that is not meant to be populated so that the adjacent broadcast stations do not overlap. In print, the white space denotes emptiness so that we can read between the characters that form a word and a group of words that form a sentence.
In our professional lives, white space is a train or a bus ride to work, it is the time waiting outside the client's office, the time spent on long flights. We have all been given huge white spaces and we simply let their power go waste.
Look back at the day you spent, you will notice the white spaces and how you utilized them. If you wanted to read a book, could you have utilized the white space better. If you wanted to write something, could white space have been utilized in a better manner. I am not suggesting you to use all the available White spaces towards your interests, probably that’s not ideal. But what is more apt is that in order to create time for self, White space do offer the necessary time space for you.
By just having a look at how you utilize the time in the day, you would be able to figure out how to manufacture time. Believe me, it’s possible!
Am I able to "compartmentalize" life ?
"Our main business is not to see what lies dimly at a distance, but to do what lies clearly at hands" - Thomas Carlyle
Dale Carnegie too was a huge proponent of Living in a Day tight compartments. Over a period of time, i have begun to appreciate the essence of living in Day tight compartments. Much of our mental and emotional energies drains out worrying about what will happen tomorrow or also by replaying the mistakes that we did yesterday in our minds. Living in a day-tight compartment is a metaphor that symbolizes that we shut out thoughts that carry over from yesterday or thoughts that represents tomorrow's anxieties and live life as it happens today. The idea is not to let residue thoughts of yesterday and toxic worries of tomorrow bother you today.
I have found the application of this concept suitable even while managing multiple passions. I try and live a slightly modified version of this principle- "Live in a hour tight compartments" when you are dealing with multiple interests.
It often happens that disappointment resulting in failure or a mistake in one task during the start of the day often occupies your mind throughout the day and affects everything else you do throughout the day. Living the day in a hour tight compartment helps one shut out what happened in the earlier on and helps maintain the required focus in other interests.
Am I believing in myself more than i should ?
This may sound somewhat naive. I always thought that believing in oneself is one of the foremost things everyone should do, till i read Don't believe in yourself if you want to succeed! . In its heart this article talks about how believing in self always leaves us vulnerable to unknown situations. When faced with these situations, we often tend to think about our limitations.
If at all you think you cannot manage multiple interests, it might as well be the case of excessive belief in your own self. Try not believing the part of you that says "you cannot do it". It works! Every achievement starts with a thought in mind.
---------------------------------------------------------------------------------
Updated on 13th-March-2010
Martin Bailey --a man with multiple passions, quite beautifully balances his passion for photography with his work as a Software Management professional. For more on him, do visit- http://www.martinbaileyphotography.com/
Here is what he had to say upon reading this post-
I read your blog post with great interest. You write very well, and although I intended to scan over it, I ended up reading it fully.
I thought the part where you mentioned about being interested as opposed to committed is so very true. People often ask me how I find time to do my photography, including the weekly podcast and forum etc. while maintaining a busy full time day job. My answer is often that I don't find time, I make time. People will always make time to do something that they love and they really want to do. If you aren't able to do that, question your commitment to your passion, and not how others miraculously seem to have more time than yourself.
Prioritizing what you attack first is also very important. I've never locked into the number three, but when I have a long list of things to do, I prioritize how I spend my time. I often quote the 80:20 rule. You can say that 20% of what you do will be responsible for 80% of your success. If that's true, you can stop doing the other 80%, concentrate on doing your 20% really well, and excelling in those tasks, and your overall success will be enhanced even more. Of course, there are always going to be things in the 80% that you can't avoid doing, but you don't need to work on these as hard. I learned from an old boss, that sometimes good "enough", is good enough. You don't have to do everything to the best of your ability to succeed.
You also talk about creating time in your paragraph about White Space – I have no white space! There is no time such as on a bus or walking when I am not listening to a photography related interview, or an Audible book etc. Even when I'm sitting next to my wife after dinner, enjoying our time together before I go to my computer, if we are not talking about something, I'm running through ideas and planning my evening's activities or future plans. I do feel that I need to work harder on giving myself some white space to be honest. I am often so plugged in, that I can become over tired sometimes, to the point of making myself ill. Taking time off is important.
I like the idea of day tight or hour tight compartments. I generally learned a long time ago that I need to shut off one thought or problem to enable me to concentrate on the next. In my early twenties I would lose weekends worrying about something that happened on Friday, only to find that on Monday the problem had either disappeared, or was not such a problem after all. There are times though when I am not able to cut off feelings from previous incidents, and I'm not sure that we should. One of my bosses always praised me for being able to cut away from work easily though, and giving myself time for my photography, creating a nice balance in my life, so I'm probably doing an OK job of this.
The only thing in the article that I found a little difficult to read, or awkward was the double negative at the end. You say that we should not believe in ourselves, but then turn it into a positive, by saying that you should not believe in yourself when you think you can't achieve something. This last paragraph is funny, as I'm sure you meant it to be, but it boils down to the fact that you need to believe in yourself to give yourself the confidence to proceed, but not to be over-confident.
Personally, I have a very easy philosophy around this. I never question my ability to do something when trying to decide whether or not to take on a new task or project. The only question I ask myself is whether or not I want to do it. If I want to do something, I will make it happen, no matter how difficult the undertaking. Of course, I realize that although I'd love to be able to fly unaided or go to the moon, right now that's just not possible. You have to be realistic, although I do fully expect to go to the moon or into space at least once before I die.
Great article Anuj! Thanks very much for sharing.
Sunday, January 24, 2010
Thursday, January 14, 2010
2000-2009- a flourishing decade in the History of Software Testing
The year 2010 not only marked the start of a new year but also a new decade. With this, the world said Good bye to another significant decade in the world history. Virtually every news channel, new paper, websites ran special series on the important events, happenings and people of the decade gone by. All this got me wondering, Software Testing as a profession too completed a rather eventful and a positive decade. It made me look back on time gone by and caused me to grow in realization that most of the things about our profession have indeed changed and evolved for good.
The text that follows this paragraph is the experience nuggets as i have observed. These are no way the researched facts but just the way i have seen Software Testing evolve.
Scope of Testing:
Start of the decade: We will develop the product and the Testing team can test the UI.
Towards the end of the decade: I need separate testing teams for Security Testing, Functional Testing, Automation, Globalization Testing etc.
It was quite apparent in the early days of the decade that the Test team was usually associated with testing the Functionality or the UI part. Even for doing that part, there were enough doubters in the organizations. I remember an instance when Development team used to come and say- please log more logic related bugs. Well they were not all that wrong here; the focus indeed had been more on testing the UI. The bottom line then was that due to various factors, the test team was not trusted to test anything beyond what is visible to the user. Performance Testing, Security Testing etc. did not even feature in the overall scheme of things.
I was recently in a discussion with a professional who said that legacy code that’s written for some of the applications 10 years back, there was no special consideration given to the Security aspects. The situation now is very different and it has evolved in alignment with the customer's expectations. Apart from superior product functionally, today's customer demands the product to be secure and working with optimum performance. While several factors have led to the transformation of expectations but after-effect has been that this change has been positive for Software testing profession. Security Testing and Performance Testing has become buzzwords and the testing streams that are based on specialized skills.
Developer's attitude:
Start of the decade: I don’t have time now. Please come later for any clarifications.
Towards the end of the decade: Please do some unit testing on the private fix. I don’t want this bug to be rejected after I introduce this fix.
Just imagine the scene- A tester has been tasked to test a very complex product. But there was no documentation. Still the tester manages to test the product, finds a seemingly good bug and then rushes to the Developer to give the news. The Typical developer staring at a screen without a blink of eyelid, does not notice the tester, falls deaf ears to tester's enthusiasm and just says- "I don’t have time now. Please come later.....". I won’t say every Developer had such an attitude then but most of them did have and each generally had different ways to "Ignore" the testers. Some even referred Software QA Engineers as "Questions and Answer" Engineers (rather than Quality Assurance).
The situation that i witnessed towards the end of decade is a lot better. The Software testing job commands a certain respect and the developers community by far realizes that they would not want to release the product to market without having gone through the eyes of a skilled tester. One of the instances that confirms me this fact is that the Developers requested Testers to test the Private binaries to ensure that the bug is fixed and it wont cause the internal builds to fail. Now, thats what i call as "Paradigm Shift".
Tester's Involvement:
Start of the decade: Test team should only be involved after the product is developed fully.
Towards the end of the decade: Have you included the Product Requirements document to be signed off by the Software Testing team?
Testing is something that’s done towards the tail-end of the Software Development Life cycle- That is what one of the super bosses of the one of the earlier projects i was involved in said. Well, not really well said. Things actually worked on the assumption that Software testers would be involved in the Project Life cycle only after builds are integrated and ready to test. When i say "Involved" in the last sentence, i meant even the knowledge acquisition of new features, any preparatory activities would start after the build is ready to test. This may be hard to believe now but certainly was the case.
Now, the things are different for good. The projects do not ideally proceed unless Product requirements are formally signed-off by the Software Testing stakeholders. The V-model being followed in essence helps ensure that the test team gets ample space to plan and do what they do the best- Find bugs and provide quality related information.
Tester's attitude:
Start of the decade: We will do lots of adhoc testing on the Release candidate build. We have to stop this release by finding bugs.
Towards the end of the decade: I need to find bugs timely for the quality release. Finding late bugs won’t reflect well on me.
One of the early instances that i remember was testers saving their best for the last i.e. testing the product loosely in early phases and when the release approaches put all the "testing skills" to optimum use and find critical crashes and bugs that would eventually "Stop" the release. And what’s more there was a certain sense of pride when boasting to others as if Testing team had some God given Power to make or break the releases at will. Howsoever naive it might sound now; this was one of the situations in the early days.
Now, of course the tester's mission is more clear and defined, and finding late bugs are not a good reflection on test strategy. By late bugs i mean, the bugs that could have been found earlier. Of course, regressions can occur at anytime in the product life-cycle. But the whole fact of the matter is with some rightful advances in Software Testing Education, the overall expectations are better communicated and known.
Passion:
Start of the decade: Test only during weekdays.
Towards the end of the decade: Weekend testing. Are you game for it ?
Passion is key to success in Software Testing like in any human endeavor. Well, in early days of the decade too there were people with immense passion for the craft. Testers were willing to go that extra-mile to learn something and evolve in the profession.
All i can say is that during the later part of decade, this has only gone better. Training methods have evolved and there are many success stories that the testers of current genre can look upto. The recent initiative of Weekend Testing community only takes this passion to a higher levels.
Career Planning:
Start of the decade: Its good to try and be big fish in a small pond.
Towards the end of the decade: Well, now we are talking about a sea.
"Its good to try and be big fish in a small pond and be a small fish in the big pond" this is how one of the testers in the earlier days of the decade remarked when i was having a conversation about why he chose Software Testing as a field. Small pond as a metaphor for Software testing was indeed short-lived. Probably the reason it became a metaphor at all was because of lack of awareness of the depth this profession possess.
Now, the perception is changed to "Welcome to the sea, folks!". Its indeed a sea, how much ever you learn, there is always something more to learn, explore and eventually master.
Also, in the early part of the decade, the folks used to join Software testing only because they were not considered to be good in Software Development. There were numerous instances that i know of when an Engineer was moved from Development to Testing only because he/she was not good at Development, as it was taken for granted that such a person will be fit enough for testing. I don’t say that we are over this mentality altogether but for sure there has been positive change. People join Software Testing profession thinking of a long term career.
Books on Software Testing:
Start of the decade: Few books on Software Testing.
Towards the end of the decade: Dedicated Shelves of books on Software Testing.
Looking back, the book stores hardly used to have the specialized books on Software Testing at the start of the decade. The literature definitely existed but the information was not as readily available as it is now. Most referred to a book by Roger S Pressman to read about Software Testing, Testing types etc. Also, not to forget the first Software Testing book that i ever held- Software Testing Techniques by Boris Beizer.
Moving on, things are much much better now. I was recently at a book shop and seeing a separate Shelf on Software Testing books, it made me feel good about the visibility this profession has gained over the years. A little glance into the future, i can only foresee this aspect getting better.
Organization's attitude:
Start of the decade: The work that develop does is more significant and hence should be paid more.
Towards the end of the decade: Testing is equally important to the project, there is no reason why Software Test engineers should not be paid equally.
Pay and Salaries are always a sensitive issues. In the early days of the decade, Software Testing was treated as a poor cousin of Software Development by many holding the plum positions in the organizations. And this led to being given the special treatment to Software Development team not only in terms of pay but also in terms of rewards and recognition. I remember once, in one of the projects that i was involved- there was a discussion on whether Testers name should be included in product's Easter Egg or not as if Testers did not have any meaningful contribution to the projects.
The better sense has prevailed in the recent times. A lot of organizations believe in equality in terms of rewards and recognition and the bridge that existed earlier between Software Development and Software Testing in these terms has been narrowed and vanished altogether in many cases. I see less and less of this sort of preferential treatment.
Globalization Testing:
Start of the decade: We sell our Software only in US. There is no reason to testing multiple languages.
Towards the end of the decade: For our business to survive, we need to go Global. Please equip yourselves to test in various languages.
I would perceive the advent of Globalization testing also an important event in this decade. Earlier on the focus was majorly on the single language speaking markets. But declining profit margins and market share has prompted Software organizations to look into diverse geographical markets and this has led to Software Globalization Engineering taking the center stage. The more Globalization specific changes are introduced, the more it has become mandatory to test them and this has resulted in evolution of Globalization testing as a specialized form.
Do you have anymore experiences to share ? Please share it across.
As a closing note, it makes me wonder why our profession does not have “Software Tester of the decade” recognition. Any ideas?
The text that follows this paragraph is the experience nuggets as i have observed. These are no way the researched facts but just the way i have seen Software Testing evolve.
Scope of Testing:
Start of the decade: We will develop the product and the Testing team can test the UI.
Towards the end of the decade: I need separate testing teams for Security Testing, Functional Testing, Automation, Globalization Testing etc.
It was quite apparent in the early days of the decade that the Test team was usually associated with testing the Functionality or the UI part. Even for doing that part, there were enough doubters in the organizations. I remember an instance when Development team used to come and say- please log more logic related bugs. Well they were not all that wrong here; the focus indeed had been more on testing the UI. The bottom line then was that due to various factors, the test team was not trusted to test anything beyond what is visible to the user. Performance Testing, Security Testing etc. did not even feature in the overall scheme of things.
I was recently in a discussion with a professional who said that legacy code that’s written for some of the applications 10 years back, there was no special consideration given to the Security aspects. The situation now is very different and it has evolved in alignment with the customer's expectations. Apart from superior product functionally, today's customer demands the product to be secure and working with optimum performance. While several factors have led to the transformation of expectations but after-effect has been that this change has been positive for Software testing profession. Security Testing and Performance Testing has become buzzwords and the testing streams that are based on specialized skills.
Developer's attitude:
Start of the decade: I don’t have time now. Please come later for any clarifications.
Towards the end of the decade: Please do some unit testing on the private fix. I don’t want this bug to be rejected after I introduce this fix.
Just imagine the scene- A tester has been tasked to test a very complex product. But there was no documentation. Still the tester manages to test the product, finds a seemingly good bug and then rushes to the Developer to give the news. The Typical developer staring at a screen without a blink of eyelid, does not notice the tester, falls deaf ears to tester's enthusiasm and just says- "I don’t have time now. Please come later.....". I won’t say every Developer had such an attitude then but most of them did have and each generally had different ways to "Ignore" the testers. Some even referred Software QA Engineers as "Questions and Answer" Engineers (rather than Quality Assurance).
The situation that i witnessed towards the end of decade is a lot better. The Software testing job commands a certain respect and the developers community by far realizes that they would not want to release the product to market without having gone through the eyes of a skilled tester. One of the instances that confirms me this fact is that the Developers requested Testers to test the Private binaries to ensure that the bug is fixed and it wont cause the internal builds to fail. Now, thats what i call as "Paradigm Shift".
Tester's Involvement:
Start of the decade: Test team should only be involved after the product is developed fully.
Towards the end of the decade: Have you included the Product Requirements document to be signed off by the Software Testing team?
Testing is something that’s done towards the tail-end of the Software Development Life cycle- That is what one of the super bosses of the one of the earlier projects i was involved in said. Well, not really well said. Things actually worked on the assumption that Software testers would be involved in the Project Life cycle only after builds are integrated and ready to test. When i say "Involved" in the last sentence, i meant even the knowledge acquisition of new features, any preparatory activities would start after the build is ready to test. This may be hard to believe now but certainly was the case.
Now, the things are different for good. The projects do not ideally proceed unless Product requirements are formally signed-off by the Software Testing stakeholders. The V-model being followed in essence helps ensure that the test team gets ample space to plan and do what they do the best- Find bugs and provide quality related information.
Tester's attitude:
Start of the decade: We will do lots of adhoc testing on the Release candidate build. We have to stop this release by finding bugs.
Towards the end of the decade: I need to find bugs timely for the quality release. Finding late bugs won’t reflect well on me.
One of the early instances that i remember was testers saving their best for the last i.e. testing the product loosely in early phases and when the release approaches put all the "testing skills" to optimum use and find critical crashes and bugs that would eventually "Stop" the release. And what’s more there was a certain sense of pride when boasting to others as if Testing team had some God given Power to make or break the releases at will. Howsoever naive it might sound now; this was one of the situations in the early days.
Now, of course the tester's mission is more clear and defined, and finding late bugs are not a good reflection on test strategy. By late bugs i mean, the bugs that could have been found earlier. Of course, regressions can occur at anytime in the product life-cycle. But the whole fact of the matter is with some rightful advances in Software Testing Education, the overall expectations are better communicated and known.
Passion:
Start of the decade: Test only during weekdays.
Towards the end of the decade: Weekend testing. Are you game for it ?
Passion is key to success in Software Testing like in any human endeavor. Well, in early days of the decade too there were people with immense passion for the craft. Testers were willing to go that extra-mile to learn something and evolve in the profession.
All i can say is that during the later part of decade, this has only gone better. Training methods have evolved and there are many success stories that the testers of current genre can look upto. The recent initiative of Weekend Testing community only takes this passion to a higher levels.
Career Planning:
Start of the decade: Its good to try and be big fish in a small pond.
Towards the end of the decade: Well, now we are talking about a sea.
"Its good to try and be big fish in a small pond and be a small fish in the big pond" this is how one of the testers in the earlier days of the decade remarked when i was having a conversation about why he chose Software Testing as a field. Small pond as a metaphor for Software testing was indeed short-lived. Probably the reason it became a metaphor at all was because of lack of awareness of the depth this profession possess.
Now, the perception is changed to "Welcome to the sea, folks!". Its indeed a sea, how much ever you learn, there is always something more to learn, explore and eventually master.
Also, in the early part of the decade, the folks used to join Software testing only because they were not considered to be good in Software Development. There were numerous instances that i know of when an Engineer was moved from Development to Testing only because he/she was not good at Development, as it was taken for granted that such a person will be fit enough for testing. I don’t say that we are over this mentality altogether but for sure there has been positive change. People join Software Testing profession thinking of a long term career.
Books on Software Testing:
Start of the decade: Few books on Software Testing.
Towards the end of the decade: Dedicated Shelves of books on Software Testing.
Looking back, the book stores hardly used to have the specialized books on Software Testing at the start of the decade. The literature definitely existed but the information was not as readily available as it is now. Most referred to a book by Roger S Pressman to read about Software Testing, Testing types etc. Also, not to forget the first Software Testing book that i ever held- Software Testing Techniques by Boris Beizer.
Moving on, things are much much better now. I was recently at a book shop and seeing a separate Shelf on Software Testing books, it made me feel good about the visibility this profession has gained over the years. A little glance into the future, i can only foresee this aspect getting better.
Organization's attitude:
Start of the decade: The work that develop does is more significant and hence should be paid more.
Towards the end of the decade: Testing is equally important to the project, there is no reason why Software Test engineers should not be paid equally.
Pay and Salaries are always a sensitive issues. In the early days of the decade, Software Testing was treated as a poor cousin of Software Development by many holding the plum positions in the organizations. And this led to being given the special treatment to Software Development team not only in terms of pay but also in terms of rewards and recognition. I remember once, in one of the projects that i was involved- there was a discussion on whether Testers name should be included in product's Easter Egg or not as if Testers did not have any meaningful contribution to the projects.
The better sense has prevailed in the recent times. A lot of organizations believe in equality in terms of rewards and recognition and the bridge that existed earlier between Software Development and Software Testing in these terms has been narrowed and vanished altogether in many cases. I see less and less of this sort of preferential treatment.
Globalization Testing:
Start of the decade: We sell our Software only in US. There is no reason to testing multiple languages.
Towards the end of the decade: For our business to survive, we need to go Global. Please equip yourselves to test in various languages.
I would perceive the advent of Globalization testing also an important event in this decade. Earlier on the focus was majorly on the single language speaking markets. But declining profit margins and market share has prompted Software organizations to look into diverse geographical markets and this has led to Software Globalization Engineering taking the center stage. The more Globalization specific changes are introduced, the more it has become mandatory to test them and this has resulted in evolution of Globalization testing as a specialized form.
Do you have anymore experiences to share ? Please share it across.
As a closing note, it makes me wonder why our profession does not have “Software Tester of the decade” recognition. Any ideas?
Monday, January 4, 2010
What is your "Touch-Time" as a Software Tester ?
What is a Touch-Time ?
In a Lean Production system the Touch-Time is the time that the product is actually being worked on, and value is being added. In the manufacturing Lingo, the time that practitioner spends with the machine shaping the product- is the most crucial time in the production. Everything else the practitioner does while at work does not amount to the value that gets added when he or she works on the product. Though not exactly from the manufacturing world, there is a good reference for the term "Patient Touch-Time" in this article . This article beautifully defines the strategies to make best use of Touch time with patients.
In his book The Professional , Subroto Bagchi has a following mention about the Touch-Time:
While learning about Total Quality Management (TQM) in 1990s, I understood the concept of Touch-Time from manufacturing world. In a factory amidst the activities that keep a manufacturing person busy, all that truly matters is when the raw material physically touches the machinery. It is only at that stage that there is value addition as the raw material converts itself into the next higher stage in production. While a factory head may feel proud of the state-of-the-art machinery in his factory, what truly matters is not its capacity but the Touch-Time the factory is able to achieve. Quite similarly, every professional must know the equivalent of Touch-Time in his field."
What is Software Test Engineer's Touch-Time ?
As rightly pointed out by Subroto Bagchi, Every professional must know the equivalent of Touch-Time in his field. For an example- a Sales person may be involved in myriad of activities like new product training, understanding pricing and features of product, travelling but all that actually matters for Sales person is the Touch-Time with Existing or prospective customers. Without this time, there won’t be any Sales and henceforth the profits.
A similar example for the trainer. A trainer may be spending time in many activities such as training content preparation, preparing course material etc. but all that really matter for training profession is the contact time spent with the trainees.
Like in many fields, I feel the Touch-Time is hugely important in the Software Testing also. What constitutes a Touch-Time for a Software Test Engineer ? In the simplest terms, it is the time a Software Test engineer actually spend for Testing the Product. Is there anything more important to the Software Testing group than this core activity of Test engineer spending time to actually "test" the product ? I think the answer is No. It is often said that Tester's role is to provide quality-related information to the company management to help them take better-informed decisions about their products. Which activity primarily leads to gathering this information ? It is the Touch-Time. No matter how much time one spends in planning, as long as actual Test execution is not optimal, the end information gathered would be flawed.
What activities actually do not form the Software Tester's Touch-Time ?
I would say any the time spent by Software Test engineer in any activities other than actual Testing wouldn’t constitute the Software Tester's Touch-Time. This may include Test Planning, Test case creation, Test setup, Meetings etc.
Does this mean that all the non Touch-Time activities aren’t important ?
Well, to me the answer to this is a "No" and a "Yes".
"No" because one cannot obviously perform testing without the supporting activities like immaculate planning, appropriate test setup etc. I would rather call these as "supporting" activities which though are not directly productive but are essential.
"Yes" because there has to be an appropriate balance between Software Testing and non Touch-Time related activities. A good chunk of non Touch-Time activities also include "Time wasters" like unnecessary breaks while at work, giving leisure more importance, spending too much time on personal emails, Social networking etc. I am not saying that one should do away with these activities but the point i am trying to make is to understand the importance of Touch-Time and be more Self aware of how time gets spent and what chunk of time gets devoted to Touch-Time activity of testing.
Is there a way to create more Touch-Time for myself ?
At the grassroots level, whenever i felt deprived of Touch-Time one of the first things to do is to understand where the time is going. For this, i have found the use of Activity Logs quite helpful. Knowing at a granular level which activity takes more time is a good starting point to improve and create more opportunity to spend time in things that matters the most.
One another idea for creating more Touch-Time is to Invest time in Exploratory Testing.
Any ideas, thoughts, comments ? Please do share it across.
In a Lean Production system the Touch-Time is the time that the product is actually being worked on, and value is being added. In the manufacturing Lingo, the time that practitioner spends with the machine shaping the product- is the most crucial time in the production. Everything else the practitioner does while at work does not amount to the value that gets added when he or she works on the product. Though not exactly from the manufacturing world, there is a good reference for the term "Patient Touch-Time" in this article . This article beautifully defines the strategies to make best use of Touch time with patients.
In his book The Professional , Subroto Bagchi has a following mention about the Touch-Time:
While learning about Total Quality Management (TQM) in 1990s, I understood the concept of Touch-Time from manufacturing world. In a factory amidst the activities that keep a manufacturing person busy, all that truly matters is when the raw material physically touches the machinery. It is only at that stage that there is value addition as the raw material converts itself into the next higher stage in production. While a factory head may feel proud of the state-of-the-art machinery in his factory, what truly matters is not its capacity but the Touch-Time the factory is able to achieve. Quite similarly, every professional must know the equivalent of Touch-Time in his field."
What is Software Test Engineer's Touch-Time ?
As rightly pointed out by Subroto Bagchi, Every professional must know the equivalent of Touch-Time in his field. For an example- a Sales person may be involved in myriad of activities like new product training, understanding pricing and features of product, travelling but all that actually matters for Sales person is the Touch-Time with Existing or prospective customers. Without this time, there won’t be any Sales and henceforth the profits.
A similar example for the trainer. A trainer may be spending time in many activities such as training content preparation, preparing course material etc. but all that really matter for training profession is the contact time spent with the trainees.
Like in many fields, I feel the Touch-Time is hugely important in the Software Testing also. What constitutes a Touch-Time for a Software Test Engineer ? In the simplest terms, it is the time a Software Test engineer actually spend for Testing the Product. Is there anything more important to the Software Testing group than this core activity of Test engineer spending time to actually "test" the product ? I think the answer is No. It is often said that Tester's role is to provide quality-related information to the company management to help them take better-informed decisions about their products. Which activity primarily leads to gathering this information ? It is the Touch-Time. No matter how much time one spends in planning, as long as actual Test execution is not optimal, the end information gathered would be flawed.
What activities actually do not form the Software Tester's Touch-Time ?
I would say any the time spent by Software Test engineer in any activities other than actual Testing wouldn’t constitute the Software Tester's Touch-Time. This may include Test Planning, Test case creation, Test setup, Meetings etc.
Does this mean that all the non Touch-Time activities aren’t important ?
Well, to me the answer to this is a "No" and a "Yes".
"No" because one cannot obviously perform testing without the supporting activities like immaculate planning, appropriate test setup etc. I would rather call these as "supporting" activities which though are not directly productive but are essential.
"Yes" because there has to be an appropriate balance between Software Testing and non Touch-Time related activities. A good chunk of non Touch-Time activities also include "Time wasters" like unnecessary breaks while at work, giving leisure more importance, spending too much time on personal emails, Social networking etc. I am not saying that one should do away with these activities but the point i am trying to make is to understand the importance of Touch-Time and be more Self aware of how time gets spent and what chunk of time gets devoted to Touch-Time activity of testing.
Is there a way to create more Touch-Time for myself ?
At the grassroots level, whenever i felt deprived of Touch-Time one of the first things to do is to understand where the time is going. For this, i have found the use of Activity Logs quite helpful. Knowing at a granular level which activity takes more time is a good starting point to improve and create more opportunity to spend time in things that matters the most.
One another idea for creating more Touch-Time is to Invest time in Exploratory Testing.
Any ideas, thoughts, comments ? Please do share it across.
Saturday, January 2, 2010
Software Testing- A Job of Infinite Possibilities
Here is an Excerpt from the book- "How we test Software at Microsoft ?"
How do you Test Hundreds of Modems ?
We needed to test model dial-up server scalability in Microsoft Windows NT Remote Access Server (RAS) with limited hardware resources. We had the money and lab infrastructure only for tens of modems, but we had a testability issue in that we needed to test with hundreds of modems to simulate real customer deployments accurately. The team came up with the idea to simulate a real modem in software and have it connect over Ethernet; we called in RASETHER. This test tool turned out to be a great idea because it was the first time anyone had created a private network with a network. Today, this technology is known as Virtual Private Network (VPN). What started as a scalability test tool for the Windows NT modem server became a huge commercial success and something we use every time we "tunnel" into the corporate network. - David Catlett, Test Architect
In my opinion, the above anecdote is really an inspiring one for Software testers. Here we are talking about the birth of a blockbuster technology that makes life easier for so many employees world wide (enabling them to work efficiently out of the office premises with same ease). And this technology- VPN was born as a result of an innovation done by a bunch of Software testers who were out there to solve a testability issue they faced because of crunch of resources.
A few learnings here-
The recent few years has been turbulent from economic stand point and virtually every organization were faced with cost cuts and Software testing industry is no different in this regard. The times when "Do more with less" is more a rule than norm, the above excerpt is quite inspirational. As a test engineer, even before asking for "more resources" to do your job, always ask yourself and explore all the possible sources till you get an answer to this question- "Is there a better way of doing things ?", "I believe there should be a cost effective way, i must find one.". Who knows, as you get an answer to these questions- more brighter are the chances that you will come up with better ways, almost always. Adversity does breed innovation!
I wish that more such possibilities are explored in 2010. Wish you a happy new year!
How do you Test Hundreds of Modems ?
We needed to test model dial-up server scalability in Microsoft Windows NT Remote Access Server (RAS) with limited hardware resources. We had the money and lab infrastructure only for tens of modems, but we had a testability issue in that we needed to test with hundreds of modems to simulate real customer deployments accurately. The team came up with the idea to simulate a real modem in software and have it connect over Ethernet; we called in RASETHER. This test tool turned out to be a great idea because it was the first time anyone had created a private network with a network. Today, this technology is known as Virtual Private Network (VPN). What started as a scalability test tool for the Windows NT modem server became a huge commercial success and something we use every time we "tunnel" into the corporate network. - David Catlett, Test Architect
In my opinion, the above anecdote is really an inspiring one for Software testers. Here we are talking about the birth of a blockbuster technology that makes life easier for so many employees world wide (enabling them to work efficiently out of the office premises with same ease). And this technology- VPN was born as a result of an innovation done by a bunch of Software testers who were out there to solve a testability issue they faced because of crunch of resources.
A few learnings here-
The recent few years has been turbulent from economic stand point and virtually every organization were faced with cost cuts and Software testing industry is no different in this regard. The times when "Do more with less" is more a rule than norm, the above excerpt is quite inspirational. As a test engineer, even before asking for "more resources" to do your job, always ask yourself and explore all the possible sources till you get an answer to this question- "Is there a better way of doing things ?", "I believe there should be a cost effective way, i must find one.". Who knows, as you get an answer to these questions- more brighter are the chances that you will come up with better ways, almost always. Adversity does breed innovation!
I wish that more such possibilities are explored in 2010. Wish you a happy new year!
Subscribe to:
Posts (Atom)
